STM32L476RG perform a DFU via UART from another board

[devtty]

 Hello all, I'm pretty stuck and could use a pointer in the right direction. I have a nucleo communicating with another board via UART. I would like to be able to update the application on the nucleo board via UART from the other board. Is there any example somewhere on kicking off the bootloader (buttonless)/ nor moving any jumpers. I have read some docs on the USART bootloader sequence but it looks like that requires a strange pattern of moving jumpers around (see attached image). I cant find much more than that.perhaps I need to start looking at some template bootloader code and toying with writing my own?

Thanks and sorry for the n00bness

[TDK]

You can jump to the bootloader in firmware (This is H7, but L4 is similar):

https://community.st.com/s/article/STM32H7-bootloader-jump-from-application

But if you don't have firmware that already does this, no, there's no way to get into the bootloader other than BOOT pins (or a debugger).

The patterns are not that complicated. Under typical circumstances, hold BOOT0 high during reset and it will start the bootloader. Option bytes can change this as detailed in AN2606.

[devtty]

Thanks that works. Managed to communicate with the bootloader as well using the commands in AN3155.

As a follow up, I am not finding much on how to update the firmware/application via UART. Mainly, I am not sure on how a firmware update should be packaged to send via UART. Is it possible to send the contents of a .bin file to the stm32 via UART store it and write it to flash then jump to the bootloader to run it? Is this process on the right track? Is there some other way this is normally done? I have read some docs on IAP with stm32 but they all just use Tera Term on a PC which doesn't really help me understand how the binary file is being sent.

Sorry for the barrage of questions!

Thank you.

[TDK]

Stm32cubeprogrammer can connect over uart and do all of the normal things.

[Tesla DeLorean]

Over the UART you typically send a straight binary image, usually with and 0x08000000 basis for the Flash memory.

The UART protocol passes information about the address, and a small block of bytes. It's an ST specific protocol.

As I recall STM32 Cube Programmer can take .BIN, .HEX and .ELF type files. And .DFU files in the USB context for sure.

The IAP stuff is done with your own loader code running, typically using X-MODEM or Y-MODEM that your classic terminal software can support to push in a binary or packaged form of firmware. On my L432 implementation I use X-MODEM-1K for field updates

[devtty]

I guess I should have given a bit of background on what I am trying to do instead of just saying UART, thats my bad :grinning_face_with_sweat:. I would like to do the update from another board connected to the STM32 (probably just an arduino to get started after I get it working via terminal). So cubeprogrammer isnt really what I am looking for. However, I am not even using another board yet! Just using RealTerm to send hex commands.

To get me started, I was following AN3155 ( https://www.st.com/resource/en/application_note/cd00264342-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf ) to communicate with the bootloader. As you mentioned the basis for my flash is 0x08000000. The size of the binary I am trying to write is 20KB (just trying to flash a blinky program for now). But i just realized the maximum number of bytes to send per the documentation is 256 so i split my binary into multiple .bin files of 239 bytes however trying to write that to flash just results in a bunch of NACK responses. Below is the flow chart I am following. Failure seems to happen at the last "Checksum OK?"

Again, Im not sure if I am going about this the right way so let me know if I've got it wrong:face_without_mouth: .

Thanks!

[TDK]

That's the right thing to do. Probably your checksum or number of bytes is wrong. Try writing 4 bytes instead until you get it working.

0x31 0xCE

ACK

0x08 0x00 0x00 0x00 0x08

ACK

0x03 0x00 0x00 0x00 0x00 0x03

ACK

[Tesla DeLorean]

Perhaps look at this as an example, it is used on the ATMEL part on the MKR 1300 LoRa board to reprogram the STM32L072CZ in the Murata LoRa Module. Basically holding BOOT0 HIGH, resetting, and implementing the update process using the aforementioned algorithm.

https://github.com/arduino-libraries/MKRWAN/tree/master/examples/MKRWANFWUpdate_standalone

[devtty]

The 4 bytes was successful. So I revisited what I was doing and I get a NACK when i send my checksum value.

The process:

0x31 0xCE

ACK

0x08 0x00 0x00 0x00 0x08

ACK

0xEF (bin data with size of 239 bytes) 0x00 0xEF

NACK

If I am doing the checksum correctly my best guess is that the program I am using (RealTerm) is not sending the .bin how I would expect since my only option is to "Dump file to port"...

[devtty]

Thanks that is helpful especially seeing how the FW is stored in a header file:

I think converting my .bin or .hex file to an array of hex values like the one above may help quite a bit. I feel like I'd have some serious problems trying to send an Intel .hex or .bin file from another board through UART. It looks like there is a tool to just do that:

https://developer.arm.com/documentation/ka004285/latest

Will give it a shot sometime today!