Blankcheck fails after successful FLASH_Erase_Sector (HAL_FLASHEx_Erase) in STM32H743

[GS1]

I have a strange behaviour on a new project with a STM32H743 processor and I am currently stuck.

After a successful (HAL returns HAL_OK) erase operation of a flash sector (e.g Sector 4) the blankcheck routine - which worked on all of my other H743 projects - tells that still data is in that Flash memory.

But when I reboot the system, the flash actually was deleted and the dump now shows 0xFFFF values.

What could block reading back data from the Flash?

Why do I read back previously programmed data?

How can I ensure that data is actually read and not presented from a previous read operation or a buffer?

This is my blankcheck routine:

int FlashBlankCheck(DWORD FlashStartAddr,DWORD FlashEndAddr)

{

   volatile uint64_t data64 = 0;

   volatile uint32_t Adr;

   Adr = (uint32_t)FlashStartAddr;           /* set pointer to start address */

   while (FlashStartAddr < FlashEndAddr)      // Start z.B: 80000 End z.B. 0x9FFFF

   {

      data64 = *(uint64_t*)Adr;

      __DSB();   // Data Synchronization Barrier (Daten-Blocken)

               // It completes when all explicit memory accesses before this instruction complete.

               // aus: Example fürs Flashen kopiert

      if (data64 == 0xFFFFFFFFFFFFFFFF)      // 64 Bit auf einmal lesen

      {

         Adr += 8;                // increment Flash pointer

         FlashStartAddr += 8;    // increment Start address

      }

      else

         return 0;               // Flash not Blank

   }

   return 1;                       // Flash Blank

}

Any comments are very much appreciated!

[Tesla DeLorean]

Do you need to invalidate the cache, by address, of the region you've changed?

[GS1]

Hi Clive,

thank you for this hint.

In fact after inserting

   SCB_CleanInvalidateDCache_by_Addr((uint32_t*)Adr, (int32_t)(FlashEndAddr-FlashStartAddr));

before reading from the flash solved the issue.

But I am still wondering:

• My blank check routine in the other bootloaders do not need this Cache CleanInvalidate call.
• How can I determine, when I have to use this call? (I know I should learn more on these Cache techniques)

Thank you for the help!

[Tesla DeLorean]

ARM designs are simple, they don't spend millions of transistors to snoop the buses for activity that will impact cache coherency.

The CM7 is a particular issue because the caches are architected into the design, but it has no understanding of what you do to downstream memory that would change the content from that which it is holding. ie you DMA into it, it is a non-memory register/FIFO, or you erase the content. You must manage this manually, either by cleaning/invalidating (the former where you flush back to memory) the cache, or configuring the memory types/interactions in the MPU.

The CM4 is less of an issue, I suspect you'd want to do stuff with the ART disabled, I tend to have my loaders work in the immediate post reset state before the flash unit and PLLs are configured. But yes, you'd generally what to be aware of coherency issues in the system, and the behaviour of write-buffers, etc.

Some degree of situational awareness about how the processor functions and interacts with subsystems would be helpful to have.