STM32U5 Flash Write Fails
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-11 1:47 PM
Hi ,
I am writing multiple chunk of each 48 bytes to Flash by following flash programming sequence mentioned in STM32 U5 Reference manual. However some chunks are written properly where some chunks are still remains 0xFF. Please let me know if anybody encountered similar kind problem.
Flash programming
The Flash memory programming sequence is as follows:
1.Check that no Flash main memory operation is ongoing by checking the BSY bit in the FLASH non-secure status register (FLASH_NSSR) or FLASH secure status register (FLASH_SECSR).
2. Check that the write buffer is empty by checking the WDW bit in the FLASH non-secure status register (FLASH_NSSR) or FLASH secure status register (FLASH_SECSR).
3. Check and clear all error programming flags due to a previous programming. If not, PGSERR is set.
Set the PG bit in the FLASH non-secure control register (FLASH_NSCR) or FLASH secure control register (FLASH_SECCR).
5. Perform the data write operation at the desired Flash memory address, or in the OTP area. Only a quad-word can be programmed and OTP can be only programmed in non-secure access:
– Write a first word in an address aligned on a quad-word address. The WDW bits in
the FLASH non-secure status register (FLASH_NSSR) and FLASH secure status
register (FLASH_SECSR) are set to indicate that more data can be written in the
write buffer.
– Write the second, third and fourth word in the same quad-word.
6. The BSY bit gets set. WDW is reset automatically.
7. Wait until the BSY bit is cleared in the FLASH non-secure status register (FLASH_NSSR) or FLASH secure status register (FLASH_SECSR). The software must make sure that BSY is set or WDW is cleared before waiting for BSY to get cleared.
8. If the EOP flag is set in the FLASH non-secure status register (FLASH_NSSR) or FLASH secure status register (FLASH_SECSR) (meaning that the programming operation has succeeded and the EOPIE bit is set), it must be cleared by software.
9. Clear the PG bit in the FLASH non-secure control register (FLASH_NSCR) or FLASH secure control register (FLASH_SECCR) if there is no more programming request.
Regards,
Hareesha
- Labels:
-
STM32U5 series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-11 2:58 PM
One more thing I observed is that ,
BSY flag never sets when WDW bit is cleared to initiate the programming process. But still sometimes data is written to flash. Please clarify.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-11 3:14 PM
Are you writing to flash word-aligned areas?
Show your code and show the results of it in flash. Likely some clues can be obtained by what portions are written vs which ones are still at 0xFF. Note that you can only write to a flash word once before it must be erased.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-12 8:52 AM
Hi,
Flash word is written to aligned address and flash page is erased before it is written. I may not be able to share code. I have attached is the flow chart of the flash driver implemented.
Regards,
Hareesha
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-12 8:58 AM
Flow chart doesn't make a ton of sense.
If write buffer is empty to start, it's stuck in an infinite loop. Why is EOPIE enabled at all? Handling the IRQ doesn't seem to be a part of the process. If buffer doesn't have an integer number of flash words, it's unclear what happens. Maybe "write buffer" is shorthand for something other than bytes left to write to flash.
Ultimately, you'll have to do some debugging on your particular code if you can't show it here. You can also use HAL code that achieves the same goal. It's unlikely that the process outlined in the RM has issues and there isn't much more to go on here.
