Skip to main content
T
TomKing
Associate
November 24, 2023
Solved

Verify in bootloader USART protocol fails

  • November 24, 2023
  • 7 replies
  • 4191 views

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 ?

 

 

Best answer by 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 !

 

7 replies

F
FBL
Technical Moderator
November 28, 2023

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.

 

 

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.Best regards,FBL
T
TomKingAuthor
Associate
November 29, 2023

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.

T
TomKingAuthor
Associate
December 13, 2023

Has nobody an answer to this ??

F
FBL
Technical Moderator
December 13, 2023

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.

 

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.Best regards,FBL
T
TomKingAuthor
Associate
December 14, 2023

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

 

F
FBL
Technical Moderator
December 14, 2023

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)", 

FBelaid_0-1702553048632.png

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

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.Best regards,FBL
T
TomKingAuthor
Associate
December 14, 2023

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

F
FBL
Technical Moderator
December 22, 2023

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.

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.Best regards,FBL
T
TomKingAuthor
Associate
December 22, 2023

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.

F
FBL
Technical Moderator
December 22, 2023

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.

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.Best regards,FBL
Pavel A.
Pavel A.
Super User
January 3, 2024

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

Not safe. Read back & compare.

 

F
FBL
Technical Moderator
January 3, 2024

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.

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.Best regards,FBL
    T
    TomKingAuthorAnswer
    Associate
    January 11, 2024

    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 !

     

    Terms & ConditionsAccessibility statement