Using STM32L552 Bootloader to flash new firmware via CAN-FD port only the first 512 bytes are changed

KBorc.1 · ‎2022-01-25

Using STM32L552 Bootloader to flash new firmware via CAN-FD port only the first 512 bytes are changed starting from address 0x8000000 even though Write Unprotect (0x73) and Readout Unprotect (0x92) has been sent according to AN5405. Erase Memory (0x44) is working by setting all memory to 0xFF.

What needs to be done to flash new firmware beyond the first 512 bytes?

Amel NASRI · ‎2022-01-31

Hi @KBorc.1 ,

Thanks for your answer.

Command 0x31 (flash data) with 4 blocks of 64 bytes of data

==> do you mean that you execute write command 4 times?

==> is what you get a different behaviour than initially described issue (only the first 512 bytes are changed)?

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

KBorc.1 · ‎2022-01-31

Hello Amel,

I mean sending "0x31 {address} 0xff" which requires to send 4 blocks of 64 byte of data according to AN5405.

There is no different behaviour than initially described. I only provided these details so you can check it and see if there is anything to correct.

kind regards

Karl

Amel NASRI · ‎2022-01-31

Hi @KBorc.1 ,

Please note that the maximum length of the block to be written is 256 bytes via FDCAN interface, in one single Write Command. (This is documented in AN5405, page 14).

In order to write 512 bytes, you will have to send 2 Write Commands with 256 bytes each time.

Also, please make sure to set writing addresses properly:

First 256 bytes are written starting from: 0x08000000
Second 256 bytes are written starting from: 0x08000100

Do you confirm that this is what you are doing?

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

KBorc.1 · ‎2022-01-31

Hi Amel,

the hexfile I am flashing requires to send

256 bytes to write starting at 0x08000000
244 bytes to write starting at 0x08000100
256 bytes to write starting at 0x080001F4
256 bytes to write starting at 0x080002F4
...

kind regards

Karl

KBorc.1 · ‎2022-01-31

Hi Amel,

after sending my last answer I got the idea to reorganize my hex-reading so as to write 256 bytes each from 0x08000000, 0x08000100, 0x08000200, 0x08000300 ... and it work!!

So I am wondering what is the reason my original flashing did not work?

is there an address rule that prohibits an address like 0x080001F4?
has it to do with writing 244 bytes and filling up with 0xFFs to define 256 bytes to be flashed from 0x08000100 and directly afterwards writing from 0x080001F4 thus trying to redefine the 0xFF-area from the previous command with new data?

Thank you very much for bearing with me.

kind regard

Karl

Amel NASRI · ‎2022-02-01

Hi @KBorc.1 ,

It is required to have double-word aligned address. This is described in RM0438 page 187.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

PLawr.2 · ‎2023-03-17

Finally got my STM32 Nucleo L073RZ bootloader Write working. It's been a real puzzle for me for a few weeks....

The trick was to apply the Read Protect first, then apply the Read Unprotect. It is only then that the RDP gets disabled. Then apply the Write unprotect. Hey presto, the Writes then work.