Why does the built-in SPI-bootloader in STM32F446 fails to write to flash address 0x0802ADF8, when all the previous addresses were written to just fine?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2019-01-23 3:11 AM
I have an STM32F446 that has its firmware upgraded by another microcontroller through SPI-bus (please see AN4286, "SPI protocol used in the STM32 bootloader"). My application code starts at sector 4 (address 0x08010000) and I am able to successfully program the flash for a good while, until I hit address 0x0802ADF8 (this is roughly 44 kByte into sector 5) when I get a NACK right after sending the Start of Frame command and byte 1 and byte 2 (0x5A, 0x31, 0xCE). The microcontroller performing the upgrade sequence automatically retries once in the event of an error, but when retrying it just gets another NACK in the same place. If I read address 0x0802ADF8 and beyond it's full of 0xFF:s and if I recycle power then I am able to write to 0x0802ADF8 and beyond through some special test code. Does anybody know why the bootloader would behave in this way? What can I do to debug this?
- Labels:
-
Bootloader
-
SPI
-
STM32F4 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2019-01-23 3:32 AM
Try writing using different sized blocks to see if the address of failure moves
Skip the immediately prior write.
Instrument the process heavily.
Dissemble and debug ROM code.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2019-02-14 1:35 AM
In various places throughout the code a function called SPIreceive was called and this function was calling HAL_SPI_Receive_DMA. This was a problem because the transmitted data (MOSI) is undefined when calling HAL_SPI_Receive_DMA. By instead calling HAL_SPI_TransmitReceive_DMA and ensuring that the transmitted data was all zero the problem went away.
