How to program a LoRa-E5

Seeed provides no documentation on this, and it took me a long time to figure it out.
This is what I did to program my own code into a Grove-LoRa-E5.

First, I prepared an image to program. I used the ST32CubeIDE with the STM32CubeWL Firmware Package installed. I opened the GPIO_IOToggle example and checked that it would build (its target hardware is the NUCLEO-WL55JC board
and I don’t have this, so I could not run it).

I created a new project from the existing GPIO_IOToggle.ioc configuration file. I opened the new .ioc file. In the Pinout & Configuration section, I added two pins:
PA0 as a GPIO output, labelled LED1: this the active low LED on the Grove-LoRa-E5.
PB14 as a GPIO output, labelled LED2: this is n/c on the Grove-LoRa-E5 and is an active high LED on my own PCB.

I did File > Save > Generate code, then in main.c I found MX_GPIO_Init() which contains code that initialises both pins as GPIO outputs. Comparing the new project with the GPIO_IOToggle project I see that the GPIO_IOToggle makes use of
existing BSP files, but the structure is similar. I copied across the LED toggling code from the while loop and made the necessary renames so it would build (e.g. LED1_PIN to LED1_Pin).

Second, I prepared a NUCLEO board that I already had to act as the ST Link programmer. (I had purchased a Seeed STLink V2 programmer but when I connected it to STM32CubeProgrammer I get “Error: OLD STLink firmware. Please upgrade it before trying to connect”. I have not worked out how to do this.)

I followed instructions here: UM2179 “STM32 Nucleo-144 boards” section 5.4.4 “Using ST-LINK/V2-1 to program and debug an external STM32 application.” (This video provides useful background:
I wired from the NUCLEO board to the SWD pads on the bottom of the Grove-LoRa-E5 board, using the NUCLEO board as the 3.3V power source. It appears that BOOT (PB13) must be pulled low when the board is powered on or it will not be
detected by the STM32CubeProgrammer software. This step was not necessary after I programmed my own code.

Third, I downloaded and installed the STM32CubeProgrammer software. With the NUCLEO board connected to the Grove-LoRa-E and to my laptop, I selected ST-Link (top RHS) and clicked Connect. This connects to the STM23WL processor, but initially it failed reading from address 0x8000000 with “Error: data read failed”.

Clicking the Option Bytes icon and looking at the RDP value showed it was set to BB which means the flash cannot be read. I changed this from BB to AA and clicked Apply, then clicked Disconnect and (re-)Connect. This time I get “Data read successfully”. Note that changing the RDP value erases the previous AT Command software. (It would be good if Seeed could provide a file so it could be restored).

Finally, I clicked the Erasing and Programming icon and browsed to find the .elf file generated from my new project. I checked the “Verify Programming” and “Run After Programming” checkboxes, and clicked “Start Programming”.

I got success messages and the LED started blinking!


Hi, LoRa-E5 Module, Grove - LoRa-E5, LoRa-E5 mini, and LoRa-E5 Dev Board are programmed with the same AT Firmware and bootloader. If you find ‘C’ character comes out from serial at baud rate 115200, that means your module is running in the bootloader.
We use PB13 to control the module to stay in bootloader(for DFU) or jump to the AT application. When PB13 is HIGH, the module will jump to AT application after reset.
What is more, the Factory AT Firmware is programmed with RDP Level 1. If you want to develop your own application, please remove RDP first with STM32Cube Programmer. Note that regression RDP to level 0 will cause a flash memory mass erase. That means the Factory AT Firmware can not restore.
Thanks for your interest and support. We will provide more instructions of LoRa-E5. Thanks again!

1 Like

I also discovered a nice to do on how to program custom firmware on documentation of the LoRa-E5 wiki devkit version containing a LoRa-E5.

Would have been nice to have this link also on LoRa-E5 product.


Thank you for sharing~

Hi, @acutetech we have post a guide of How To Develop with STM32Cube MCU Package, please check here: and the source code of the example is in our github:


Thanks Jerry. I have found the radio_board_if.c & .h files. I think there might be an error relating to selecting the chip’s two RF output pins.

In the .c file the RBI_ConfigRFSwitch() code has code for 4 cases, including different settings for RBI_SWITCH_RFO_LP and RBI_SWITCH_RFO_HP - which suggests to me that the hardware can switch either the RFO_LP or the RFO_HP pins on the chip.

However the .h file has this (two defines for the same thing):

I think the second of these should be deleted. Otherwise the value RBI_CONF_RFO_HP tells radio_driver.c that only the RFO_HP pin is available, whereas radio_board_if.c says that both pins are available. Also, you get a compiler warning “warning: “RBI_CONF_RFO” redefined”

Please check this and tell me what I should change.

Can you supply the circuit diagram, so I and others can see for ourselves?

I’m running STM32 CubeProgrammer, but I cannot connect successfully to the LoRa-E5 Dev Board (nor the LoRa-E5 mini) to reprogram it.

I’m running on Mac OS (Big Sur), and have the board in DFU mode (it sends a byte sequence every second to the serial port), but it errors out.

19:50:46:249 : Timeout error occured while waiting for acknowledgement.
19:50:46:250 : No response from target received
19:50:46:250 : byte 0x7F sent successfully to target
19:50:46:343 : Wait ends after 1 loop, dataready = 0, delay = 105
19:50:46:343 : Timeout error occured while waiting for acknowledgement.
19:50:46:343 : No response from target received
19:50:46:343 : Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again…

Is there a particular timing trick to this?

Also, I recognize that doing this will purge the existing firmware and AT command functionality. I am somewhat disappointed in this as there seems to be nothing really equivalent to replace it with if one was to want similar functionality in the future.

Did you see this, which I posted above? [quote=“acutetech, post:1, topic:257491”]
It appears that BOOT (PB13) must be pulled low when the board is powered on or it will not be
detected by the STM32CubeProgrammer software.
As far as the AT program is concerned, it would be good if Seeed made the source code available, so you could restore it. That said, ST provides the source of an AT program as part of the STM23WL support package. It runs on their Nucleo board so you will have to make changes for the LoRa-E5.

Yes, I was able to get the device into DFU mode, what I can’t do is get it to properly communicate. I suspect their is a problem with initializing the serial port on Mac OS.
I’m not convinced the port is initialized correctly. (I tried the command line tool as well).

I was able to connect to the device on the Mac and communicate with AT commands, that worked without issue.

I may have to jump through some serious hoops to get this working, all my machines are Macs, unless the toolset can run on the Rpi. (Maybe just to load the replacement firmware).

I had issues getting the STM32 tools installed as well, but I worked past those issues and the tools seemed fine once running.

Not inherently seeeds problem.

Not sure I understand your problem: whether it is a problem while programming the LoRa-E5, or whether it is with serial comms after it has been programmed. In case it the the latter problem: ST’s sample LoRaWAN code uses USART2 on PA2 and PA3, whereas Seeed’s AT program uses USART1 on PB6 and PB7. Unless Seeed have changed this in their LoRaWAN node port then I advise you to use PA2, PA3, as it will be non-trivial to change to USART1.

Simply put I can’t reprogram the device.

I get the device itself into the proper mode, and the STM32 Programmer software attempts to communicate and then it fails to work.

I’ve even tried the command line version of the tool.

If I get a chance tonight I’ll be trying a couple different computers to do it.

I’ve posted on the community forums at ST. I’ve received no response.

I’ve tried each of the serial ports on the LoRa-E5 development board, and the best I was able to do was get the same serial uart results as I get over USB.

I’ve installed/updated the drivers for the USB to serial/CP2104 and that got me to the same place.

The connectivity seems to work, but it won’t actually program the device.

Unfortunately unless there’s a new development I’m going to have to switch my project to better supported hardware.

Things I need:

Useable point to point. The current AT command set is all in on LoRaWAN, but that excludes the possibility of handling a point to point which I need (or my costs skyrocket) until the project justifies multiple gateways. The TEST mode point to point is a kludge.

Ability to restore AT command set. I bought the loRa-e5 development board to do development on the board, I didn’t realize doing so would cause me to lose functionality. It’s a one-way process. (I would be fine with having to restore a binary blob to gain that functionality again.)

Basically, if I build a proof of concept that utilizes the LoRA-E5 Dev board and we don’t proceed with a custom build I can’t just switch it back to the AT command set and use it, I’ll end up tossing it in the junk drawer and having to use another device for development. This is particularly disappointing with this board, as it has the connectors broken out to be used, but the only way to use them is to drop the AT command set.

I have one last attempt at using the systems I have to update the firmware on the board, I’ll be trying to get Linux running and use that version of the STM32 Programmer to update the board, unfortunately I don’t hold out much hope for that on the systems I have. (2 intel Macs, and the rest of my systems are ARM based).

Seeed isn’t responsible for the lack of support on Mac (and I’ll even concede Apples made it a little difficult in the last couple years for tools like this anyway), but I don’t have a budget to burn and need to work with what I’ve got.

Seeed should work out the licensing issue with the AT command set (if that’s what it is), to at least allow restoring the firmware.

I’d recommend updating it to have a supported point to point mode built in as well.

(I fundamentally disagree with the general community being completely antagonistic to point-to-point. I can turn around and buy devices for the same frequency band that cause worse interference than a few point to point LoRa links ever will and still be 100% compliant).

By my estimates there’s 5 gateways on public networks in my city, 4 of which are all within 500 meters of each other, and absolutely none in locations which benefit me. I can’t justify buying a gateway for a one-off device that’s outside of a pre-existing gateway area. While I have a gateway on order for my specific location, I expect to have a half dozen devices in use here.

(I intend to have a weather station installed at a location that is well outside of range of any pre-existing gateway. I can locate a second LoRa node device there as a point to point receiver, but a Gateway is simply overkill).

Instead I’ll have to reevaluate if I should be using some other base hardware.

I have determined experimentally that the second of the two defines is correct. Otherwise the uplink RSSI is very poor. I have filed a bug report here:

As I have noted before, it would be much better if Seeed would trust its users and publish circuit diagrams, which would allow such confusion to be cleared up quickly.

Im also struggling with this one. Ive managed to program the LoRa-E5 mini dev board using an ST-Link via SWD and have loaded on the given Seeed modified example code: LoRaWAN_End_Node. This firmware works and is able to send uplinks no problem. This was thanks to @acutetech whose post was my savior.

However, Im now not able to get the STM32CUBEProgrammer to connect to the device. I see:

Error: Problem occured while trying to connect

I suspect that without the Seeed provided bootloader Im now not able to get it into DFU mode.

From what Ive read it seems that the Lora E5 module doesnt have a pinout for the STM32s BOOT0 so Im wondering how I might get it into system boot mode?

Does this mean I might have bricked this poor little dev board?

Any insight would be much appreciated

Solved it after some trial and error.

Turns out the third party ST Link V2 I have, has to be unplugged and replugged into the USB which presumably puts it into the correct mode. Then, holding down the RST button on the Lora E5 Mini dev board, clicking Connect on the STM32CUBEProgrammer software and releasing the RST button, allows the board to be detected and programmed every time.

This is on a macbook pro running Big Sur (11.2.3) using a Yootech USB-C to USB adaptor. The Lora E5 Mini is also connected via USB with an Arduino Serial Monitor open to view its output. The dev board is wired up according these instructions:

Now to actually write some code for it!

Hi @cmydlarz
Which third party ST Link V2 you are using?
Can you suggest any which is compatible with LoRa-E5?

I use this one: Aideepen ST-Link V2 Programming…

Which as mentioned is a bit finicky but can program the Lora E5 mini dev board. I’ve not tried any other programmers so my experience is limited.

I am having issue in getting the ST-Link/V2 programmer to connect to the LoRa-E5-Mini. I am using Windows PC, STM32 Cube Programmer and IDE.

I am using ST-Link/V2 to program LoRa-E5 mini. I connected the ST-Link/V2 programmer as follows, using the 20 pin connector of the programmer, pin 9 (SDIO) to LoRa-E5 SDIO, Pin 7 (SWCLK) to LoRa-E5 SWCLK. Pin 6 (GND) to LoRA-E5 GND. I am using the USB port connected to my Windows PC to power the LoRA-E5 mini module.

It would be great if there were a concise step by step to make this work.
From what I see in the posts, I should do the following:

  1. Before applying power to Lora-E5 module, Connect PB13 to GND
  2. Connect STLink/V2 to PC USB port
  3. Start STCubeProgrammer
  4. Connect Lor-E5-Mini to PC USB port (For power)
  5. Press and hold the LoRa-E5-Mini RESET Button.
  6. Click ‘Connect’ on STCube Programmer
  7. Release LoRA-E5-Min Reset button.

I tried the above repetitively and virtually all combinations, and yet cannot get connection - log below. Clearly I am doing something wrong, and is likely obvious. Help please. A nice step by step guide would be great, thank you!

09:24:22 : ST-LINK SN : 37FF6F064243393027222057
09:24:22 : ST-LINK FW : V2J37S7
09:24:22 : Board : –
09:24:22 : Voltage : 1.56V
09:24:23 : Error: ST-LINK error (DEV_TARGET_CMD_ERR)
09:24:28 : ST-LINK SN : 37FF6F064243393027222057
09:24:28 : ST-LINK FW : V2J37S7
09:24:28 : Board : –
09:24:28 : Voltage : 0.53V
09:24:28 : Error: No STM32 target found!
09:24:33 : ST-LINK SN : 37FF6F064243393027222057
09:24:33 : ST-LINK FW : V2J37S7
09:24:33 : Board : –
09:24:33 : Voltage : 1.56V
09:24:35 : Error: ST-LINK error (DEV_TARGET_CMD_ERR)

I should also add the the AT application is still working fine, so the hardware appears to be good.

Problem solved:

  • Connect ST-Link/V2 programmer as follows:
    • CN3 Pin 1 to Lora-E5 3V3
    • CN3 Pin 7 to Lora-E5 SWDIO
    • CN3 Pin 9 to Lora-E5 SWCLK
    • CN3 Pin 19 to Lora-E5 SCK
    • CN3 Pin 8 to Lra-E5 GND
  • Connect ST-Link/V2 programmer to USB port
  • Connect Lora-E5 to USB port
  • Press and hold the RST button on the Lora-E5 module
  • Click on the ‘Connect’ button on the ST-Cube Programmer
  • Release the RST button on the Lora-E5 module. ST-Cube Program should now indicate ‘connected’.
  • In St-Cube Programmer, select the ‘OB’ menu.
  • Change Read Out Protection from BB to AA and apply it.