Lora-E5 bootloader specfication

Products & Technology LoRa
#1

I want to use the factory bootloader on the Lora-E5 module to replace the factory firmware. I have devices out in the field that I do not want to attach to an STLink or other programming interface, I want to program over UART.

Anyone have the specification for the bootloader? It’s spits out a “C” character every second, as others have noted, but there is no further information on it. Any pointers are appreciated.

Regards,

Stephan.

#2

Hi there,

and Welcome here…

So I’m pretty sure it’s not OPEN Source info, but you may find additional info on the Semitech site/forum… I have NOT seen anyone doing this, I believe the factory firmware is non restorable as well, YMMV.

Seeed engineering or Another user with more hands on may comment, What is the goal of this OP?

HTH
GL :slight_smile: PJ :v:

#3

Thanks for your comments. Semtech provides the die for the SX1262 that’s integrated into the stm32wle5jc microcontroller used in the Lora-E5, there is no user programmable flash in the SX1262, so the bootloader is Seeed’s addition. The factory firmware delivered with the Lora-E5 is painfully slow.

For example, when sending a 32-byte packet using SF10, CR 4/5 and 500KHz bandwidth, it takes more than 300ms for the device to report back that the packet has been sent. The time-on-air for such a transmission should be around 120ms (according to Semtech’s Lora Calculator), so for 180ms the Lora-E5 is twiddling its thumb. If I were to guess, the firmware is periodically polling the SX1262 with a delay and therefore does not see that the SX1262 reported that it is done sending earlier.

The worst part of this is that while the Lora-E5 is “busy” it cannot receive any packets either. It appears that the SX1262 has not been configured to default back to receive mode after a transmission, meaning that the user has to explicitly tell the Lora-E5 to switch back to receive mode.

I’ve used the Microchip RN2903 previously and it has far less “overhead” for the same transmit parameters and reports back within about 150ms that it was successful in sending.

Fast forward, I’ve recreated the factory firmware with a subset of the AT command set using the STM32 “Radio” library and use an interrupt from the SX1262 to notify the user that sending of a packet is complete. It does this at around 140ms when using 230400 bps UART interface.

It has also been configured to immediately switch back to receive mode after a successful packet transmission, eleviating the need to do this explicitly and reducing the radio “dead” time to a minimum. I also plan on implementing “Carrier Activity Detection” into my firmware so that it will not try to transmit if the channel is not free.

I want to replace the firmware that I have on my devices in the field with my own firmware and would like to use the bootloader that already exists in the Lora-E5. I need the interface specification to utilize this. What I don’t know is if their bootloader requires signed firmware images. If it does, then I don’t have an option but to flash using the STLink hardware interface.

Let me know if anyone has any info on the bootloader specifications.

#4

Hi there,

Well , Excellent Run down I think you spent a lot of time on this forsure. I see the same issue’s however often here and on other forums about the devices slow to return info issue, I think you nailed it. The interrupt thing wouldn’t be the first time they overlooked it. :face_with_peeking_eye:
I would think a Carrier detect or Collision detection would improve it even more(works for ethernet). Seems basic they didn’t benchmark or test it though ?

Also you follow a few with STM dev stuff dropping it for something better or more capable.
Seems the LORA stuff is quite powerful & capable but the Closed DEV info is a real PITA for everyone.

Hopefully a SEEED engineer can jump in and clear up the smoke. If they would make it work properly (no delays) folks wouldn’t have to go RAW-dog on this thing and make it work ! would b a good start. IMO!

HTH
GL :slight_smile: PJ :v:

“OPEN Source” it really needs to be more open and available, I’m certain this is why it’s adoption is SOoooo Slow. I see weekly the “AT firmware” question again and again…:+1:

#5

I have no problem that the factory firmware is closed source. I think they’re trying to limit copy-cat competition, which is fair and reasonable. The other issue is that the certification that the module comes with is only valid with the supplied firmware. Providing the source code may suggest to end-users that making modifications to the source and flashing it on the device would not invalidate this certification (spoiler: it does).

I have not done enough research, but it is possible that Seeed based their bootloader on the ST OpenBootLoader code (see https://github.com/STMicroelectronics/stm32-mw-openbl). I need to dig into this more to see if that is the case.

#6

Hi there,
Ah’ very good… I would bet on it. (that it’s possible it’s based on the open boot loader from ST)
While I don’t disagree about the copy cats, Seeed folks know it’s MAKERS so you should open the comona for such things…as a Flash to restore the factory stuff which as you know once it’s wiped it’s over. The “AT” coms’ is easy and user friendly.
So keep us posted what you find, I’m certain it would benefit everyone.

GL :slight_smile: PJ :v:

#7

Some more discovery on this. It appears the factory bootloader on the Lora-E5 does NOT use the STM OpenBootLoader. It does not respond to 0x00 and 0x02 in a way that I expect, but it did trigger a 0x15 (NAK), which hinted at an old-style file transfer protocol.

As I started looking closer at this, it appears that the bootloader is implemented using YMODEM-1K, as the characteristic ‘C’ character is used in both YMODEM and XMODEM transfer protocols. I installed “Tera Term” and sent it my replacement binary ELF file using YMODEM-1K and to my surprise, it was acknowledging each block until 100% of the file was sent.

It did not install my firmware after a reset, but the bootloader is now permanently enabled suggesting that it did in fact blow away the factory firmware (sans bootloader). I believe the format of the binary file that I sent it is probably not an ELF file, but Intel Hex or Motorola S-record format. Stay tuned…

1 Like
#8

I tried sending my firmware using XMODEM-CRC and YMODEM-1K using binary format, Motorola S-Record and Intel HEX format, but it is not booting into my application. I suspect that I’m missing two key pieces:

  1. The start of user flash - I assume that the bootloader occupies 0x08000000 - 0x08003FFF (16K). This may be incorrect and the bootloader is writing my firmware at a different address, messing up the vector tables.

  2. The bootloader may set a flag that the user firmware is expected to clear to indicate that the bootloader is no longer needed. This would bypass the bootloader until it is explicitly triggered through the BOOT (PB13) pin.

Anyone have any insights on either or the Lora-E5 bootloader in general, please let me know.

#9

I don’t have any answer, but I will soon also need a fw programming solution over uart. The way I read the sparse information, it should indeed be compatible with DFU.
Unfortunately, I don’t have any unprogrammed units to test with anymore. Have you tried using something like dfu-buddy?

#10

I tried both DFU Buddy and DFU-UTIL, but it’s not enumerated by either tool.

#11

Tried w600Tool as well. It looked promising, but alas.

Screen Shot 2025-01-10 at 10.40.48 PM
Screen Shot 2025-01-10 at 10.40.48 PM872×181 6.04 KB

#12

There’s a very good chance that Seeed used the STM32 Secure Patching Bootloader (https://github.com/firmwaremodules/stm32-secure-patching-bootloader).

If that’s the case, the image is signed and there is no way to update the firmware using the factory bootloader. I’m going to reach out to the maintainers to find out if they are aware of Seeed’s use of their work.

#13

Hi there,

I have seen this b4, It’s open source, someone uses it in their product or sells a off shoot MUST provide the resulting Configuration, Parameters , additions or edit to the original source MUST be published… Yea!

Ah’ NO ONE does though or listens or follows the laws…

The way I understood it was this:
if someone copies an open-source product and incorporates it into their catalog, their obligations depend on the specific open-source license under which the original product is distributed. Here’s a general breakdown:

1. GPL (GNU General Public License):

  • Obligation: The GPL is a copyleft license, meaning that if you distribute a modified version of GPL-licensed software, you must make the source code for your modified version available to users.
  • Disclosure: You must disclose the modifications you made, along with the original source code, and distribute the product under the same GPL license.

2. MIT, Apache, BSD Licenses:

  • Obligation: These are permissive licenses, so you’re generally allowed to modify and distribute the product without having to disclose your changes.
  • Disclosure: However, you must still retain the original copyright and license notice in the distributed code. You are not obligated to disclose changes unless specified by additional terms.

3. Creative Commons Licenses:

  • Some Creative Commons licenses, like CC-BY-SA (ShareAlike), require you to share derivative works under the same terms as the original and attribute the creator.
  • Disclosure: You must disclose the original source and any modifications, depending on the license terms.

4. Other Copyleft Licenses (e.g., AGPL):

  • With more restrictive licenses like AGPL, you must not only disclose changes when distributing but also ensure that network users (in the case of AGPL) can access the source code.

When Disclosure is Required:

  • Redistribution: If you are redistributing the software or hardware designs (like firmware, PCB layouts, etc.), you are likely required to provide access to the source files.
  • Modifications: If you’ve modified the product, copyleft licenses typically require you to document the changes and make them available under the same license.

When Disclosure is Not Required:

  • Internal Use: If you’re only using the product internally and not redistributing it, most open-source licenses don’t require you to disclose changes.
  • Permissive Licenses: If the license doesn’t demand disclosure (e.g., MIT or Apache), you may not have to reveal modifications, but you still need to honor the original license terms.

Hardware Open-Source Licenses:

For open-source hardware, such as products covered by licenses like CERN Open Hardware License or TAPR Open Hardware License:

  • You may be required to share schematics, PCB designs, and documentation of modifications when distributing derivatives.

In Summary:

Open-source licensing promotes transparency and sharing but has different requirements based on the license. Before using or distributing an open-source product, it’s crucial to read and understand the specific terms of its license to ensure compliance. Failure to do so can lead to legal and ethical issues.

Let’s hope they play by the rules… :v:

HTH
GL :slight_smile: PJ :v:

p.s. My pops was a Lawyer and Later a Judge…So :+1:

#14

I have filed a support ticket with seeed, normally they answer.

#15

I haven’t tried uploading the programme via Bootloader, but I find an answer to this somewhere in my head.

It tell me “Try to upload firmware using YMODEM protocol.”

I can’t remember where I got this info, but it might just work. :no_mouth:

#16

Got answer from Seeed support, “Unfortunately we don’t support programming the module with serial interface.”
What a bummer, this was one of the reasons for me to use the E5 module in the first place. Strange that they mention DFU in their docs…

I will probably use the E5 only for prototypes going forward, and put the stm32wle directly on my PCB for volume production, unless I find a better module by then.

1 Like
#17

There’s a strong indication that the bootloader requires signed images. Yes, it does appear to support XMODEM-1K/YMODEM protocol, but the image does not appear to get installed. The flash memory for the application is erased, so after you do the upload, you end up permanently in the bootloader without a way to restore the factory firmware.

#18

Final thoughts on this is that it is not possible to use the factory bootloader, at least, not without support from Seeed. For those interested, I recommend using the excellent open source work by Firmware Modules Inc. & Evans, et al. (https://github.com/firmwaremodules/stm32-secure-patching-bootloader) and then build your own application using the Radio library from ST.

1 Like
#19

So I check the AT Command Specification document of Wio-E5, at Section 4.22 it wrote that the make sure the uploaded firmware is supplied by Seeed.

It looks like there are some setting differences between Seeed’s firmware and non-Seeed’s firmware, and the E5’s factory bootloader distinguishes whether this firmware is official Seeed firmware or not by some feature code or something. If it’s not official, it will prevent it from being burned.

#20

In other words, the firmware is cryptographically signed. Case closed.

1 Like