cancel
Showing results for 
Search instead for 
Did you mean: 

Why D-cache invalidation hangs?

ktrofimo
Senior III

Just noticed that my application TouchGXF task hanged. Other FreeRTOS tasks are continue to work.

Debugger shows that problem is within core_cm7 SCB_CleanInvalidateDCache():

/* clean & invalidate D-Cache */
    sets = (uint32_t)(CCSIDR_SETS(ccsidr));
    do {
      ways = (uint32_t)(CCSIDR_WAYS(ccsidr));
      do {
        SCB->DCCISW = (((sets << SCB_DCCISW_SET_Pos) & SCB_DCCISW_SET_Msk) |
                       ((ways << SCB_DCCISW_WAY_Pos) & SCB_DCCISW_WAY_Msk)  );
        #if defined ( __CC_ARM )
          __schedule_barrier();
        #endif
      } while (ways-- != 0U);
    } while(sets-- != 0U);

sets = 69

ways = 3682273424 and counting down

I think it will stop counting eventually, but it takes time...

During regular run initial values are: sets = 127, ways = 3, ant it has sense because ARM documentation says CCSIDR sets bits are [27:13] and ways bits are [12:3] (in Cortex M7allowed values are 0x01 for instruction caches and 0x03 for data caches)

STM32CubeIDE Version: 1.7.0

ARM CMSIS 5.7.0

Cube IDE STM32H7 MCU package 1.9.1

TouchGFX 4.17.0

Is it a bug? Is there a way to fix this?

4 REPLIES 4
ktrofimo
Senior III

Task stack:0693W00000JMnbQQAT.png

Romain DIELEMAN
ST Employee

Hi,

I remember an implementation error we did with the F7/H7 families where in TouchGFXGeneratedHAL.cpp,  the implementation of TouchGFXGeneratedHAL::InvalidateCache() should be a call to SCB_InvalidateDCache() and not SCB_CleanInvalidateDCache() (the latter performs an additional cache flush / writes to memory prior to cache entries invalidation). Is it the case in your project ? If not overwrite the function by calling it in TouchGFXHAL.cpp and call SCB_InvalidateDCache() .

/Romain

ktrofimo
Senior III

Hardcode (well, I know it is bad style, but I know exact figures for this particular MCU) sets=127 and ways=3 did not help. Now it hanged again with sets=122 and ways = 3690305115.

Will try to call SCB_InvalidateDCache() and see will it happen again.

1) call SCB_InvalidateDCache() from TouchGFXGeneratedHAL::flushFrameBuffer() - this is an original functions where I did catch this bug - gives screen artifacts and hungs in the middle of nowhere.

2) call SCB_InvalidateDCache() from TouchGFXGeneratedHAL::InvalidateCache() leads to MemFault right before first screen should be painted.