2021-01-21 03:48 AM
TouchGFX 4.16.0 generated code can/will crash in HardFault if D-Cache is not enabled.
This happens at least in those CPUs where there is data cache (STM32F7...).
This behaviour is something new that was introduced in 4.16.0 version.
This change is undocumented and not mentioned in changelog.txt for 4.16.0.
When updating a working design from 4.15.0 to 4.16.0, made the system fail (crash in HardFault).
The problem was resolved by enabling data cache in CubeMX (enable CPU DCache).
The problem is in TouchGFXGeneratedHAL::flushFrameBuffer() invalidating D-Cache even when not used.
There is nothing in STM32CubeMX or TouchGFX designer that would warn about this.
I suppose this change was done to achieve some increased performance and cache coherency.
What about systems that don't use or need data cache, will they still crash?
Maybe this behaviour (data cache flush/invalidate) should be optional?
2021-01-23 04:33 AM
I got the same issue as KPort with a H743 and TouchGFX 4.16.0.
Took me some time to find the problem since TouchGFX Board Bring Up documentation recommends disabling D-Cache for testing.
If the D-Caching MUST be enabled, it would be nice to have STMCube display a warning in the TouchGFX software pack section.
2021-01-23 06:00 AM
I don't know if this is related but SCB_InvalidateDCache (void) has some VERY nasty side effect, it can destroy pending stack writes, and as the call stack unwinds Hard Faults...
The use of SCB_InvalidateDCache_by_Addr (uint32_t *addr, int32_t dsize) is strongly recommended in ALL cases, but one also needs to be conscious of the 32-byte alignment of address and length
2021-02-07 07:44 PM
Ok, on another unrelated project (USART DMA) we discovered that SCB_CleanDCache_by_Addr() hard faults if we don't enable the caches (CPU_CACHE_Enable() not called), routines calling this should sanity check the caching state.
2021-02-07 11:17 PM
I remember the same thing happening in my project some year or two ago. The interesting thing is that I cannot repeat it anymore. Now I can switch D-Cache on/off at runtime and SCB_CleanDCache_by_Addr()/SCB_InvalidateDCache_by_Addr() just works (with cache off it does nothing). Something (a lot) has changed, but I cannot figure out what exactly is related to this particular issue. Just for information - currently that project uses the latest CMSIS v5.7.0 and FreeRTOS v10.4.3 code.