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

[KBorc.1]

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]

Hi @KBorc.1​ ,

I'm checking this issue with our experts.

I'll keep you informed once I get an answer.

Internal ticket number: 121655 (PS: This is an internal tracking number and is not accessible or usable by customers).

-Amel

[Amel NASRI]

Hi @KBorc.1​ ,

To go ahead with problem analysis, it is required to let us know the following:

1. What is the Bootloader version on your device? You can get it when reading the content of the address 0x0BF97FFE (more details in AN2606).
2. What host are you using?

Thanks,

-Amel

[KBorc.1]

Hello Amel,

1. Trying to read from 0x0BF97FFE by bootloader command 0x11 (AN.5405) delivers only 0x79 (ACK) but no other information. Using bootloader command 0x01 (GetVersion) delivers ACK 0x10 0x00 0x00 ACK
2. I am using the CAN-Suite from EMS Wünsche running on Windows 10 working on a CPC_USB/FD CAN-converter to send commands and reading answers from the STM32L552 controller

kind regards

Karl

[Amel NASRI]

Hi @KBorc.1​ ,

Thanks for your answer.

To make sure to get correct bootloader version, is it possible for you to read the cotent of the address 0x0BF97FFE using STM32CbeProgrammer?

-Amel

[KBorc.1]

Hi Amel,

I only have a ST-Link V2 adapter which shows this information trying to read address 0x0BF97FFE:

[cid:

image001.png@01D81451.77676180

]

So as I mentioned before there remains only the version information from the bootloader command 0x01: ACK 0x10 0x00 0x00 ACK.

Kind regards

Karl

******Moderator action: Customer details removed******

[TOlli]

Hi Karl,

I don't have the same processor (I'm using H7 series) and there we noticed the same issue with FDCAN, the bootloader is able to flash only 63 bytes and the rest of the operations just hang.

This is noted in AN2606 table 104 for the STM32H7 (the document is the same for all STM32 models).

I spoke with support rep and apparently they are fully aware of this limitation, but at least for H74xx/H75xx series, they are not planning on fixing it.

Maybe you're experiencing the same issue, but it is just not listed for your device? It seems to me that ST reuses the bootloader for variety of products with small variations for pins and clocks.

Best regards,

Tero

[KBorc.1]

Hi Tero,

we have invested quite something in building our product in such a way as to use the STM32L552 bootloader for updating firmware via CAN_FD. You are seriously telling me flashing via CAN_FD does not work beyond the first 512 Bytes???? AN5405 mentions “Special (0x50)�? and “Extended Special 0x51�? commands without providing any details. Could you please investigate if theses commands might be used to flash at least the first bank or if there is another way to accomplish our task?

Kind regards

Karl

******Moderator action: Customer details removed******

[Amel NASRI]

Hi @KBorc.1​ ,

Please note that our expert made a test and confirmed that it is working properly on his side: he was able to write & read kbytes of data. using FDCAN bootloader.

Bootloader version of the device used for test is V9.2 (which is the last version for STM32L5).

That is why we would like to know the exact bootloader version on your device (read 1byte @0x0BF97FFE).

You & @TOlli​ are using different products, we cannot conclude that it is the same issue already recognized for STM32H74x/STM32H75x.

-Amel

[KBorc.1]

Hi Amel,

reading only 1 byte at 0x0BF97FFE did the trick: 0x92 is finally shown.

For your reference I explain exactly how I try writing;

• Command 0x44 (bank erase) with data 0xff 0xfe
• Command 0x73 (unprotect flash)
• Command 0x92 (unprotect readout)
• Command 0x31 (flash data) with 4 blocks of 64 bytes of data

When I read back blocks of 256 bytes for checking I find that beginning at 0x080001F4 only 0xFF is reported. Actually 0xFF is found a few byte previous to this address.

Hopefully you can provide a way I can flash firmware using the CAN-FD port with my present hardware.

kind regards

Karl

[Amel NASRI]

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

[KBorc.1]

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]

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

[KBorc.1]

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]

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?

1. is there an address rule that prohibits an address like 0x080001F4?
2. 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]

Hi @KBorc.1​ ,

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

-Amel

[PLawr.2]

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.