STM32F405 SPI fails after programming ınternal flash by software

[hasanisci]

Posted on September 30, 2016 at 16:30

Hello,

I have an EEPROM emulation in my software which is described in STM's application notes. But, I'm having a problem communicating with SPI2 after I write variables in EEPROM (or internal flash). SPI messages seems wrong after the programming. Communication still appears but received data is different. Details about my application are located below. My application is bigger than 32Kbytes In EEPROM emulation, there are 255 different 16bits variables and I'm writing all of them into the EEPROM in one command. (command means that user request in here) I'm using sectors below for my application sector 0 - 0x0800 0000 - 16Kbytes sector 4 - 0x0801 0000 - 64Kbytes also I'm using following sectors for EEPROM emulation sector 2 - 0x0800 8000 - 16Kbytes sector 3 - 0x0800 C000 - 16Kbytes Problem is not occur in every command. But after a while (keep writing variables into the EEPROM) problem appears and communication in SPI fails. I realized that, if I erase the whole flash and re-load my application again problem is solved. However, again if I send commands to application to write variables into the eeprom, I see that problem appears. Sounds like a weird problem and I haven't solved it yet. I thought that EEPROM emulation writes into the SPI2s memory location but I guess it is impossible since I checked the memory location and SPI2 is located around 0x4000.. Do you have any idea what could be the problem? Thank You #spi-stm32-flash-eeprom

[Tesla DeLorean]

Posted on September 30, 2016 at 17:45

The emulation uses internal FLASH causing it to pretend to act like EEPROM. There can be a lot of stalling of the process caused by the Write or Erase. This can cause timing issues if you use SPI via interrupt.

You should look at what is actually happening on the SPI bus wires in the failing condition, perhaps use a Logic Analyzer, or instrument your code so you get a better grasp of what exactly is going wrong. Can't tell from your description. Consider presenting the failure case with minimal code to demonstrate it.