Verify in bootloader USART protocol fails

[TomKing]

Hello Community,
Using the USART commands in boot mode on a STM32H723 CPU, I faced following issues:
Extended erase (0x44) and writing memory(0x31) to the flash works fine, if I write ALL bytes in blocks of 256 bytes.
But if I do a read memory(0x11) after writing one block for verify purposes, I get FFs on the first bytes instead the correctly written data. This happens exactly after the second read block always, even if I write 4 blocks and do the readback then.
The STM32 CubeProgrammer also only supports verification AFTER writing all data to the flash, not block by block.
Is this a generic limitation in the boot loader ?

 

 

[FBL]

Hello @TomKing , 

Could you check the start address to read the memory. It's possible that you are reading from the wrong address, which is why you are getting FFs instead of the correct data.

 

 

[TomKing]

Hello F.Belaid,

the verify start address is correct. The problem arises exactly in the first 32 bytes of the second block. See the attached text file which shows the communication.

[TomKing]

Has nobody an answer to this ??

[FBL]

Hello @TomKing 

It would be helpful to add more details to reproduce the issue, the bootloader version. In the meantime, I have communicated your request internally to dedicated team to investigate further.

 

[TomKing]

Hello F.Belaid,

Thank you for your support. The Chip is a STM32H723 VGH6. For the boot protocol infos see following infos from the cube programmer:

08:28:00 : STM32CubeProgrammer API v2.10.0 | Windows-64Bits
08:28:46 : RTS low
08:28:46 : DTR low
08:28:46 : Serial Port COM5 is successfully opened.
08:28:46 : Port configuration: parity = even, baudrate = 38400, data-bit = 8, stop-bit = 1.0, flow-control = off
08:28:46 : Activating device: OK
08:28:46 : Board : --
08:28:46 : Chip ID: 0x483
08:28:46 : BootLoader protocol version: 3.1
08:28:48 : UPLOADING OPTION BYTES DATA ...
08:28:48 : Bank : 0x00
08:28:48 : Address : 0x5200201c
08:28:48 : Size : 92 Bytes
08:28:49 : UPLOADING ...
08:28:49 : Size : 1024 Bytes
08:28:49 : Address : 0x8000000
08:28:49 : Read progress:
08:28:50 : Data read successfully
08:28:50 : Time elapsed during the read operation is: 00:00:01.339

 

[FBL]

Hello again @TomKing 

Waiting for a response from the team Internal ticket number: 168821 (This is an internal tracking number and is not accessible or usable by customers)", 

However, I noted here while writing instead of 10 this should be 20. I guess this should not affect the overall behavior.

[TomKing]

No, the data is not important, just to find the point when no 'FF' is read out. Value 20 comes later (after 2F).

[FBL]

Hello @TomKing 

We can confirm we have reproduced the issue. We have two workarounds available for the moment:

1. Write all the needed data at once (no read every 256 bytes) then check all the data.
   But before sending any new write command after the read command used to check the data, we must write dummy 32 bytes in FLASH before writing the needed data.
2. Or add an extra dummy write of 32 bytes after each read operation:

Write 256 bytes @ 0x08000000
Read 256 bytes @ 0x08000000

Write dummy 32 bytes @ 0x08000100

Write 256 bytes @ 0x08000100
Read 256 bytes @ 0x08000100

Write dummy 32 bytes @ 0x08000200

Write 256 bytes @ 0x08000200
Read 256 bytes @ 0x08000200
...
...

till the end of data.

[TomKing]

Hello STM Team

Thank you for the support and the possible workaround. I will check this in january.
I think the dummy write value shall be 32 FF's ?

Happy Christmas and new year to you and all the team.

[FBL]

Hi @TomKing 

You can simply write the same 32 bytes instead of dummy bytes. These workarounds will be documented in the AN2606. 

You are welcome and happy Holidays.

[Pavel A.]

> How safe is it to rely on the WriteMemory return value ?

Not safe. Read back & compare.

 

[FBL]

Hello @TomKing 

According to USART protocol in AN3155, figure 13, the ACK byte sent by the bootloader after a successful write operation indicates that the data has been written correctly not being read. 

So, you need to read it back.

[TomKing]

Hello All,
I've implemented the verify with the described workaround in our company tool. Works as expected now. Thanks to everyone who helped to solve this !