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.
