What code is in the LoRa-E5 modules that you sell?
Yesterday I received some Grove-LoR-E5 modules, which respond to AT commands through the serial port at 9600 baud, as documented. I also received some LoRa-E5 modules. I have soldered one to my own PCBs. I expected the same behaviour. Instead, I get no reponse at 9600 baud. As I cycle through baud rates what I do see is the letter “C” being transmitted every 1s, at 115200 baud.I don’t know whether this is expected behaviour, or some artifact of (say) a watchdog timer reset every second, or…(what?)
Unfortunately I don’t have an oscilloscope to watch the waveforms.
What I would like to know is: is the code in the modules the same as on the Grove boards?
I have no GROVE board, only modules - and am struggling with a similar situation.
As you, I have the module soldered on my own PCB. I have a logic analyzer connected to the Rx and Tx lines and get nothing on the Tx.
I cannot reproduce it now but remember initially seeing capital C’s on the serial monitor, it was probably set at 115200. I’m afraid I might have bricked it now after having done many attempts to make it respond.
It is a challenge that the datasheet is unclear on several points:
RST (pin 17): Is it active high or active low?
PB13 (pin 24): Datasheet indicates “active low”. Could the module be bricked if this is accidentally held low?
I would appreciate if we could establish direct contact to share notes and experiences, as I really need to get this module up and running.
Further to my earlier note about the “C” characters at 115200 baud: I find that if I reset the LoRa-E5 with the serial port connected I see “UART-BL v1.0.0” followed by a newline followed by the “C” characters. Connecting the PB13 (“BOOT”) pin to GND makes no difference. So AFAIK the LoRa-E5 modules behave differently than the Grove-LoRa-E5 boards, and I guess must contain different firmware?
However I have not been able to connect to the module to attempt programming it: The STM32CubeProgrammer software says “Timeout error occurred while waiting for acknowledgement” and ST’s Flash Loader Demonstrator program says “Unrecognised device… Please, reset your device then try again” - it looks like there could be a missing STM32WL file in the Map directory.
Can someone who has programmed this device please post instructions?
Correction.
On closer inspection I found that I was accidentally pulling down PB13. When I removed that, the LoRa-E5 responds to AT commands (at 9600 baud). So now, AFAIK, to Lora-E5 modules and the Grive-Lora-E5 boards contain the SAME software. (I guess we learn from our mistakes…)
My other request remains: Can someone who has programmed this device please post instructions?
I have now managed to program my own code into the LoRa-E5 (I will post separately on this). That seems to relove the previous bootloader function. I am guessing it was invoked by the AT application code that is now replaced.
According to AN2606 “STM32 microcontroller system memory boot mode” section 66, the STM32WLE5xx does have a bootloader (always) but it is available on different UART pins, and is invoked by a different boot pin not availale on the LoRa-E5 (search the datasheet for “BOOT0”).
Hi Mark
I have designed my own PCB and soldered the LoRa-E5 to it. Then I program it with code generated by the ST32CubeIDE. I happen to be using a NUCLEO board as the programmer.
I have written up what I did here: How to program a LoRa-E5
Hi all. My PCB is not available at the moment. I will share a few pointers if you are making your own:
The AT software uses PB6 & PB7 for the UART, but ST’s LoRaWan code uses PA2 & PA3, and it is non-trivial to change that. So if you plan to use their code, then track PA2&PA3 to your UART connector.
AFAIK the “BOOT” button on PA13 is only used by Seeed’s AT software. You will need to pull it low to program your own code, but won’t need it after that.
I could not get interrupts working on pins > 4 (e.g. PA13). It must be possible, but use port pins 0, 1, 2, 3, 4 if you want interrupts.
ST’s code uses active high LEDs, so copy that if you want to avoid changing their code.
Check out Texas Instruments DN024 for a simple PCB antenna. Don’t make your PCB too small as you need a reasonable sized GND plane for the antenna to work against.
Be careful with your FTDI cables: Mine have 3.3V signals, but VCC is 5V.
This is exactly why I asked for schematics here, they claim we can use with our custom firmware but without schematics of the hardware it’s not really easy.
So you mean with “boot” button we can’t use it as IRQ to wake the device because it’s on PA13, correct?
AFAIK, the so-called boot pin on PA13 is defined only by the AT software that is programmed by default into the LoRa-E5. There is no fundamental hardware reason that it is different from any other GPIO pin.
The STM32WL chips have a complex interrupt routing scheme. You can only have one of PA0, PB0, PC0 etc generate an interrupt (via “EXTI0”). Same with PA1, PB1, PC1 etc. This applies up to 4 - there are 5 dedicated interrupt vectors. When it comes to PA5-15, PB5-15 etc, it looks like pins have to share two interrupt vectors: EXTI9_5_IRQHandler and EXTI15_10_IRQHandler. Check out the vector table in startup_stm32wle5xx.s
When I tried to get interrupts working on PB15, as an example, I failed. I modified the GPIO_EXTI example and got interrupts on all pins I tried up to and including 4 (e.g. PA4) but none on any pin beyond 4. It should be possible, but I failed.
There is some configuration that eludes me. In my own work I have re-arranged pins so all interrupts are on port pins 0,1,2,3,4 so I don’t have to solve this problem.
PS If you use PA0 for an interrupt you can’t also use PB0 or PC0, etc.
thank you very much, I re arranged my board as your suggestion, now:
FTDI use USART2
Both Led active High
Boot button renamed to “user” and wired to PA0 to allow wake by IRQ (I will manually tie PB13 to GND on 1st FW flash)
You can take a look on TTN new generic node using STM32WL also, worth having a kind of same wiring to be able to use different firmware. All is open source, schematics and FW are available but still on R&D.
I’m designing a PCB interfacing E-5 to ATMEGA328. But I’m confused with the connections. I plan to use AT mode.
I have 2 doubts:
The documentation says that PB13 must be HIGH for using AT mode. Should the sequence be PB13 HIGH -> Reset HIGH, release -> Enters AT Mode ?
After entering all the TTN details, should we again follow the above sequence to send data (AT+MSG=“Data to send”) when the entire device is powered up?
Sorry, almost as quickly as I could I abandoned the AT mode (which the devices are shipped with) and started putting my own code into the chip. So my experience with AT mode is brief and some time ago.
My reading of the data sheet is that you won’t need to touch PB13 if you want to continue to use AT mode.
My advice is (a) get an existing board such as the Grove-E5 so you can play with the AT commands using a laptop and a serial terminal, to establish the command sequence your microcontroller will need to implement, and (b) make sure your PCB has flexibility to connect to other pins if you should need to (e.g. to add reset and users switches and LEDs, an extra serial port, add peripherals using QWIIK connector etc).
I have the same problem with LoRa-E5 modules that I got from DigiKey. My connections are :-
Vcc → 3.3V
All GND pins → GND
RST → pulled up with 10K ohms. Also tried floating
PB13 → pulled up with 10K ohms. Also tried floating
PB7 → FTDI TX ( operating at 3.3V)
PB6 → FTDI RX ( operating at 3.3V)
The module does not respond at all to AT commands. I noticed that the pins RX and TX are low; they measure ~0.8V. I doubt they have the AT commands firmware.
This behavior is not like what I expected. I tried the Seeed Grove LoRa-E5 module and it works well.
