Verify in bootloader USART protocol fails
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-24 5:07 AM
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 ?
Solved! Go to Solution.
- Labels:
-
STM32H7 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-01-10 11:10 PM
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 !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-28 8:26 AM - edited ‎2023-11-28 8:27 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-29 2:56 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-12 11:40 PM
Has nobody an answer to this ??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-13 5:54 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-13 11:34 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-14 5:48 AM
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-14 5:55 AM
No, the data is not important, just to find the point when no 'FF' is read out. Value 20 comes later (after 2F).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-22 3:03 AM
Hello @TomKing
We can confirm we have reproduced the issue. We have two workarounds available for the moment:
- 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. - 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-22 3:14 AM
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.
