Confusioion about actual available ADC channels

According to the LoRa-E5 datasheet V1.0 on pg 6/18, there are several pins labeled as “MCU GPIO” which implies that these are the actual pins from the ARM uC. According to the STM32WLE5JC datasheet (ST DS1305 rev 4, ppg 48-52), several pins (up to 14) can be configured as inputs to the ADC.

The table in LoRa-E5 datasheet V1.0 on pg 8/18 the LoRa-E5 datsheet table contains: “ADC 1 ADC Input, include 1pins,12-bit 1Msps” which implies only one input can be used.

Which of these is correct and if there really only is 1 ADC pin available… Which one is it?


Ok… I guess this isn’t the most responsive forum in the world… Do you guys (Seeed) want to sell these modules?

1 Like

Sorry, we were on the Spring Festival holiday a few days ago. The provided pin parameters are subject to the content of seeed official documents.

Ah, no problem. What then, is the answer to my original question? What Seeed-official documents are you referring to?

This one?: STM32WLE5JC on Seeed website

If not can you please direct me to the document that contains this info?


Sorry for my unclear description, this document shall prevail.

Ok. So please verify my own answer to my original question.

Based on “LoRa-E5 datasheet v1.0”, PB13(24) and PB14(26) are pinned-out from the silicon. I should be able to configure PB13 as ADC_IN0 and PB14 as ADC_IN1.

I have erased the part and do NOT wish to use the Seeed “AT command” firmware and do not care that PB13 was used as a bootloader request by the AT firmware.

Can you please verify? I have a PCB ready for manufacture and need to know this before proceeding.

Sent a message to the engineer, waiting for him to confirm a reply

Thanks, Citric. I think I’ve answered my own question by reading some voltage from pins pb13 and pb14 by modifying the Lora-e5-end-node example with success. Thanks for passing this on as well!

Just curious, did you end up modifying the IOC file or did you simply read from ADC channels 0 and 1 by modifying the code?

Hi. Both actually. The .ioc drives which initialization and instance management functions get generated, though I had to play with it a bit to get the proper initialization modes ie, interrupts, dma etc., for my application. I used ADC 1&2 as the COMP 1&2 “-“ pins are shared with ADC 1&2 which allows my app to use a comparator to wake from sleep mode, then use the adc to measure the input. The Seeeq data sheet is not great but basically any pins from the st arm that are pinned out to the seeeq package can be used however you like, using whatever functionality you programmatically select or change via the .ioc.