STM32 L471 Flash Cache Error

[damh]

Posted on November 14, 2016 at 14:10

I have found an error in flash cache perhaps.

I write to the same flash bank as the code is run from (with cube flash code). From time to time some 64bit areas in flash are filled with random nonsense (in the area the code is run from). Setting Flash->ACR with ICRST and DCRST does NOT help, disabling all interrupts does NOT help. If i make a hard reset and dump the complete flash again, the random filled 64bit areas are filled with the correct values again. => Thats why i think, that it is a cache and not a flash problem. The affected areas are far away from the written areas. Does anyone have an idea how to solve the problem? DBGMCU->IDCODE == 0x10076415 SCB->CPUID == 0x410FC241 => STM32L471RE rev 0

[damh]

Posted on November 14, 2016 at 15:44

investigation:

the problematic asm command is i.e.: ldr r4, [pc, #134] with Flash->ACR.DCEN == 1 => r4 is read as 0xFFFFFFFF with Flash->ACR.DCEN == 0 => r4 is read as 0x2000297C i can repetative enable and disable the Flash->ACR.DCEN Bit and the command behaves in the same way - not only once! DCRST does NOT help - only Soft/Hard-Reset or disabling Data-Cache. [EDIT: DCRST needs DCEN to be 0, then it works] This problem is very annoying because the next load like ldr r2, [r4, #00] causes a hardfault. If someone has a workaround without disabling data cache, please give a hint ;) How do i get wrong data in the data cache? EDIT2: It seems to be the same problem as in Erratasheet of STM32F427/437 - 2.1.11 Data cache might be corrupted during Flash read-while-write operation

[Tesla DeLorean]

Posted on November 14, 2016 at 17:14

Understand that the cache is not architectural, and has no coherency logic, and the ART is bolted onto the side of the core to hide the wide/slow flash lines, and provide a rapid prefetch of instructions. The fill of the cache lines is going to be on the alignment boundaries of the flash, likely 128 or 64-bit, haven't reviewed the L4 design.

If you are changing the memory content behind the cache, you'll have to flush it in some fashion. A reset of the cache should fix it, not something I've validated. Reading back what you have written immediately is also probably not advisable, and the minimum granularity you should attempt that would be the flash line width, and not 32-bit reads interspersed with writing, which is clearly prone to be a hazard.