EmWi crashing in EwEndUpdate() with modified STM32F769 Platform Package

Question

Hello,

We have successfully developed a GUI on an STM32F746-Discovery board, using 480x272xRGB565 resolution.
It runs fine there without the slightest issue, and it is not particularly complex.

We are now in the process of porting the GUI to our target system with STM32F769 CPU and RGB display interface. The combination of F769 and RGB interface has been successfully implemented before (with even higher display resolution), so we believe we have a rather error-free platform package available.

We have adapted this modified platform package to the new display resolution and timing.

Alas, at the very first display update, our application ends up in a HardFault in EwEndUpdate(), after triggering the DMA2D interrupt handler once or twice. We cannot look deeper into EwEndUpdate() though, as we are using a Small Business License.

We have verified nearly every facet of the Platform Package, the code tree, CPU configuration, toolchain and its parameters. We have tested the hardware, particularly the display itself, the LTDC and SDRAM with its frame buffers, but we cannot find what causes the application to crash.

May we ask you for a hint please?

Thanks,
Steffen

Answer 1

Hello,

thanks for providing this detailed description.

Let me suggest to check the following points:

1.) SDRAM - Let me recommend to check the SDRAM as mentioned here. This is essential before trying any GUI application.

2.) MPU settings. Please ensure that the MPU settings are adapted properly to the new memory layout.

3.) Hardfault Investigations. What it is the reason for the hardfault (see here)?

Best regards,

Manfred.

Comments

Hello Manfred,

Thanks for pointing us to potential causes of the HF.

About SDRAM:

There have been extensive memory tests in place prior to filing this support request.
Nevertheless, we have implemented your suggested SDRAM test – It runs fine.

Also worth knowing that an identical CPU circuit – processor, memory, even PCB layout  – is being used for our different projects 2 times, both running EmWi applications just fine. So it is rather unlikely that there is a hardware design bug.

About HF analysis:

There has been HF analysis code in place from the beginning. Decoding CFSR reveals that it is an unaligned memory access that causes the HF.
Frame buffer and double buffer are aligned at 8-byte boundaries though.
Could it be that the dimensions of the frame buffer (480x272xRGB565) resulted in some object or update area inside being misaligned?
An issue like the one described in STM AN4861 section 5.5.2?

Looking further into the HF, HFSR reveals that the FORCED bit is set, probably due to another fault occurring earlier being escalated to a HF.

Does this help?

---

Hello,

thanks for the additional information. Due to the fact that you are using RGB565 color format, there must be no additional alignment, because every display line is 480x2 byte, which is a multiple of 64 bytes.

Please check also the MPU settings, regarding the default setting for the whole memory space (4GB).
On different cortex-m7 platforms we noticed system hang-ups in conjunction with speculative memory accesses into undefined address areas. There was a recommendation from ST to define such default MPU setting with MPU_REGION_NO_ACCESS for the whole memory space.

Another recommendation was to disable FMC bank1 (0x6000 0000 - 0x6FFF FFFF), if it is not used.

Best regards,

Manfred.

---

Hello Manfred,

Thanks for pointing me to MPU configuration.

In our application, we adhere to the MPU_Config() implementation in ew_bsp_system.c of the STM32F769 Platform package.
I have meticulously checked MPU configuration and haven't found any flaws.
As per your recommendation, I added a definition of MPU_REGION_NO_ACCESS over the whole memory space, using the lowest region number  0, to no avail.
FMC bank 1 is disabled.

There also is a support case at Arm/Keil (https://www.keil.com/support/docs/3777%20%20.htm) addressing the same issue (We are using the Keil toolchain).

According to this case, it is the attribute of "Device Memory" pertaining to SDRAM default address space (0xC0000000 and up) that causes misalignment to trigger a HF. Do you agree on this hypothesis? 

Am I correct to assume that EmWi libraries (and particularly the code around EwEndUpdate() ) do not enforce alignment as explained in the support case above?
What else could we do?

EDIT:
As mentioned above, HFSR value (with its FORCED bit set) suggests that another lower-priority fault was escalated to a HF. Latest analysis shows it was a UsageFault due to unaligned access.

Thanks,
Steffen

---

Hello Steffen,

I don't think that the linked support case is applicable, because we are using MPU settings which do not handle the SDRAM area as Device Memory Type. This would be contra-productive, because then caching is disabled. Instead, the MPU settings are declaring the SDRAM as Normal Memory Type with write-through cache strategy. This is our default setting:

  /* Configure the MPU attributes for SDRAM 16MB to normal memory Cacheable */
  MPU_InitStruct.Enable           = MPU_REGION_ENABLE;
  MPU_InitStruct.Number           = MPU_REGION_NUMBER4;
  MPU_InitStruct.BaseAddress      = 0xC0000000;
  MPU_InitStruct.Size             = MPU_REGION_SIZE_16MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
  MPU_InitStruct.DisableExec      = MPU_INSTRUCTION_ACCESS_ENABLE;
  MPU_InitStruct.IsBufferable     = MPU_ACCESS_NOT_BUFFERABLE;
  MPU_InitStruct.IsCacheable      = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsShareable      = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.TypeExtField     = MPU_TEX_LEVEL0;
  HAL_MPU_ConfigRegion(&MPU_InitStruct);

 I assume you still have similar settings.

We do not use the compiler option --no_unaligned_access for building the libraries for the same reasons as mentioned in the support article.

Just to be sure: The MPU is still enabled?

Best regards,

Manfred.

 

---

Hello Manfred,

Thanks for communicating default MPU settings.

You were right, there was an error in our MPU configuration indeed.
It turned out there was a typo in the SDRAM base address of our settings used, writing 0xC000000 instead of 0xC0000000. This resulted in physical SDRAM address space still being configured as default Device Memory, with unaligned access throwing a fault.

Configuring SDRAM as Normal Memory now allows unaligned access at some speed penalty.
Am I correct to assume that unaligned access, despite its speed penalty by hardware, is still faster than compiling the code with forced alignment?

Thanks for your support,

Steffen

---

Hello Steffen,

great to hear that the issue is solved now!

Am I correct to assume that unaligned access, despite its speed penalty by hardware, is still faster than compiling the code with forced alignment?

Yes, I assume that hardware-handled unaligned access on the Cortex-M7 (when SDRAM is configured as Normal Memory via MPU) is typically faster than code compiled with --no_unaligned_access.

Hardware unaligned access (MPU solution):

• The Cortex-M7 handles unaligned access in hardware with minimal overhead
• Only adds a few extra clock cycles per unaligned access
• The processor can often optimize these accesses internally
• Code remains compact and efficient for aligned accesses

Forced alignment compilation (--no_unaligned_access):

• Compiler generates additional instructions to ensure all accesses are naturally aligned
• This includes extra padding, data reorganization, and potentially multiple smaller accesses
• Code becomes larger and less efficient overall
• Performance penalty affects all memory accesses, not just the occasional unaligned ones

The mentioned support article confirms this perspective when it states that Keil intentionally avoids using --no_unaligned_access for their middleware libraries "to provide best performance and code density."

Best regards,

Manfred.