cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 Bootloader firmware write over uart

jbreaper
Associate II

Hi everybody,

I'm working on a project where I have a pi cm4 connected to a STM32 (during testing we're using a STM32G07 dev board, but production will be using an STM32G03 chip). I've been asked to write a program to allow the cm4 to update the firmware via the uart. I've managed to get the program to reliably access the bootloader and run get, getv, getid, and readmem (for the flash memory). However when I try to run the write memory command it appears to run successfully, but when I read the memory address I just wrote to it returns the original value. I'm fairly certain that the write protection has already been disabled (checked using STM32CubeProgrammer), but I decided to try and run the write unprotect command just encase, but the chip seem to just hang after running the command.

I'm a recent graduate, and this is my first job, so I'm fairly uncertain as to what I'm doing, so it's very possible I'm missing something important. Thanks for any assistance and patients.

1 ACCEPTED SOLUTION

Accepted Solutions
jbreaper
Associate II

I've managed to solve me issue, it was two things;

  1. I was neglecting to erase the areas of memory I was going to write too (I had tested this at one point but that leads into point 2).
  2. I had been using the "erase" command (0x43), when in I should of been using the "Extended Erase" command (0x44).

Thanks @TDK and @Tesla DeLorean,

I'm going to throw myself into the ocean now

View solution in original post

9 REPLIES 9
TDK
Guru

Flash needs to be erased before being written. Are you doing that? It should be all 0xFF before writing.

If you feel a post has answered your question, please click "Accept as Solution".

I tried to run a global erase and it gave me a NACK back. I'm away from the test rig for the rest of today but I'll try and get full interaction tomorrow if it's needed.

(knew I would forget to put something in the post)

Not really a hospital..

Can't say I've tried the G0. Tried others with AN3155 described protocol, and L0 with the MRK WAN1300 board in more recent times.

I guess you could tap the RX/TX and watch the interaction as performed by STM32 Cube Programmer.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Are you writing the entire flash word (64 bits, aligned)? Less will not work.

It might be helpful to post a log of bytes sent and bytes received in the following transactions:

  • read an address
  • write to that address
  • read that address again
If you feel a post has answered your question, please click "Accept as Solution".

Here's what my program says is happening (log), I've confirmed that the cm4 is sending the bytes it says it is.

The bytes being sent from the cm4The bytes being sent from the cm4

I have also tested the erase again, and it's returning a NACK after the first command, suggesting that protection is enabled. Checking using Cube it looks like it's not enabled though.

Write protection according to Cube (connected via ST-LINK)Write protection according to Cube (connected via ST-LINK)

 

I wasn't properly aware that Cube had this option. This help me tremendously, turned out I was using the wrong erase function, I've got everything working now.

jbreaper
Associate II

I've managed to solve me issue, it was two things;

  1. I was neglecting to erase the areas of memory I was going to write too (I had tested this at one point but that leads into point 2).
  2. I had been using the "erase" command (0x43), when in I should of been using the "Extended Erase" command (0x44).

Thanks @TDK and @Tesla DeLorean,

I'm going to throw myself into the ocean now

Clearly there appears to be a write protection issue. I would expect the write memory command would be NACKed in that case, but that isn't happening.

Can you full erase in STM32CubeProgrammer? Can you write to flash there? If it behaves the same (can't erase, can't write), look for more relevant option bytes.

It's unclear how the chip handles the case where start < end. Perhaps put the WRPx values back to their defaults (0xFF for both start and end) and try again.

If you feel a post has answered your question, please click "Accept as Solution".

Managed to solve it, was more a case of user error (while I did RTFM, I seem to of missed a few important bits).
Thanks again for your help