HardFault on Cold Boot Only - STM32H7S78 with External XSPI Flash + TouchGFX

[nico23]

I'm experiencing a HardFault that occurs always on cold boot (after the board sits unpowered for ~1 hour). It also occurs sometimes when flashing and immediately running from the debugger.

I'm using FreeRTOS, and I've noticed that commenting a task, flashing the new firmware, no hard faults. De-commenting the same code, flashing again, problem solved (with debugger on).

I exit the debugger and try to power cycle the device, all works.

After the board sits unpowered for a certain time and I try to turn it on, Hard Fault again.

The issue is always the same CFSR.IMPRECISERR (imprecise data access error)

I managed to have a call stack and the assembly code

CFSR.IMPRECISERR (imprecise data access error)
PC = 0x70017DD2
Stack trace:
HardFault_Handler
<Exception frame>
touchgfx::LCDGPU2D_AXI::blitCopyCompressedRGB565_16BPP() + 0x69d

0x7001'7dca: LDRGT R2, [SP, #0x1c] ; Load scratchBuffer address
0x7001'7dcc: STRHGT.W R10, [R2, R5, LSL #1] ; Store halfword
0x7001'7dd0: ADDGT R5, R5, #1
0x7001'7dd2: SUBGT R7, R7, #1 ; <-- Fault occurs here

MPU configuration is

// Region 1: XSPI2 Flash (code execution)
MPU_InitStruct.BaseAddress = 0x70000000;
MPU_InitStruct.Size = MPU_REGION_SIZE_128MB;
MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

// Region 3: External RAM (framebuffer)
MPU_InitStruct.BaseAddress = 0x90000000;
MPU_InitStruct.Size = MPU_REGION_SIZE_32MB;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

// Region 6: RAM_CMD (uncached GPU buffers)
MPU_InitStruct.BaseAddress = 0x24068000;
MPU_InitStruct.Size = MPU_REGION_SIZE_32KB;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

I'm monitoring the stack usage of the various tasks and the free heap, and all are below <50% of usage.

Attached the .icf file.

I've really no idea how to debug it; it happens sometimes, and it is not perfectly reproducible.

[nico23]

After some testing, it seems there's an issue on the first boot, mostly with memory corruption or wrong memory read/write, but I can't understand what's actually firing it.

I've found out that, every time I try to attach to the running target and reset the chip to the main() in the application, 99% of the time it starts executing properly, without HardFault.

After attaching to the target, I'm seeing a BusFault is triggered

A precise data access error has occurred (CFSR.PRECISERR, BFAR)
At data address 0xfc7ff7c0.

Exception occurred at PC = 0xcdcdcdcd, LR = 0xcdcdcdcd

I think the 0xcdcdcdcd is a magic number indicating a memory access error or something, is that right?

For istance, in another istance, same code, I'm seeing always a BusFault

An imprecise data access error has occurred (CFSR.IMPRECISERR, BFAR).
Exception occurred at PC = 0x70017c1c, LR = 0xe

with stack

BusFault_Handler
<Exception frame>
[_ZN8touchgfx12LCDGPU2D_AXI30blitCopyCompressedRGB565_16BPPEPKhRKNS_4RectES5_h + 0x4e7]
[_ZN8touchgfx12LCDGPU2D_AXI21blitCopyCompressedRGBEPKhNS_6Bitmap12BitmapFormatERKNS_4RectES7_h + 0x1d]
[_ZN8touchgfx12LCDGPU2D_AXI17drawPartialBitmapERKNS_6BitmapEssRKNS_4RectEhb + 0xb9]
[_ZNK8touchgfx5Image4drawERKNS_4RectE + 0x8d]
[??JSMOC_3 + 0x5b]
[??JSMOC_4 + 0x2d]
[??JSMOC_9 + 0x5]
[??JSMOC_4 + 0x2d]
[??JSMOC_4 + 0x2d]
[_ZN8touchgfx6Screen9startSMOCERKNS_4RectE + 0x4f]
[_ZN8touchgfx6Screen4drawERNS_4RectE + 0x31]
[_ZN8touchgfx11Application4drawERNS_4RectE + 0x29]
[??drawCachedAreas_72 + 0x2b]
[??tick_6 + 0x13]
touchgfx::HAL::backPorchExited()
[??taskEntry_0 + 0x13]
touchgfx_taskEntry()
TouchGFX_Task
prvTaskExitError

and disassembly

 0x7001'7bee: 0x4588 CMP R8, R1
 0x7001'7bf0: 0xd3fb BCC.N 0x7001'7bea
 0x7001'7bf2: 0x930a STR R3, [SP, #0x28]
 0x7001'7bf4: 0x920c STR R2, [SP, #0x30]
 0x7001'7bf6: 0x2500 MOVS R5, #0
 0x7001'7bf8: 0xf89d 0x6070 LDRB.W R6, [SP, #0x70]
 0x7001'7bfc: 0x900b STR R0, [SP, #0x2c]
 0x7001'7bfe: 0xf8dd 0xb01c LDR.W R11, [SP, #0x1c]
 0x7001'7c02: 0x9c06 LDR R4, [SP, #0x18]
 0x7001'7c04: 0xe009 B.N 0x7001'7c1a
 0x7001'7c06: 0x9805 LDR R0, [SP, #0x14]
 0x7001'7c08: 0xf001 0x013f AND.W R1, R1, #63 ; 0x3f
 0x7001'7c0c: 0x2eff CMP R6, #255 ; 0xff
 0x7001'7c0e: 0xf830 0xa011 LDRH.W R10, [R0, R1, LSL #1]
 0x7001'7c12: 0xd145 BNE.N 0x7001'7ca0
 0x7001'7c14: 0xf828 0xab02 STRH.W R10, [R8], #0x2
 0x7001'7c18: 0x1e64 SUBS R4, R4, #1
 0x7001'7c1a: 0x2c00 CMP R4, #0
 0x7001'7c1c: 0xf340 0x80dc BLE.W 0x7001'7dd8
 0x7001'7c20: 0xf819 0x1b01 LDRB.W R1, [R9], #0x1
 0x7001'7c24: 0x0988 LSRS R0, R1, #6
 0x7001'7c26: 0xd0ee BEQ.N 0x7001'7c06
 0x7001'7c28: 0x2801 CMP R0, #1
 0x7001'7c2a: 0xd13b BNE.N 0x7001'7ca4
 0x7001'7c2c: 0xf64f 0x70e0 MOVW R0, #65504 ; 0xffe0
 0x7001'7c30: 0xea00 0x000a AND.W R0, R0, R10
 0x7001'7c34: 0xf001 0x0203 AND.W R2, R1, #3
 0x7001'7c38: 0x4492 ADD R10, R10, R2
 0x7001'7c3a: 0xf1aa 0x0302 SUB.W R3, R10, #2
 0x7001'7c3e: 0xf3c1 0x0281 UBFX R2, R1, #2, #2
 0x7001'7c42: 0xf003 0x031f AND.W R3, R3, #31 ; 0x1f
 0x7001'7c46: 0x4318 ORRS R0, R0, R3
 0x7001'7c48: 0xeb02 0x1250 ADD.W R2, R2, R0, LSR #5
 0x7001'7c4c: 0xf64f 0x0a1f MOVW R10, #63519 ; 0xf81f
 0x7001'7c50: 0xea0a 0x0a00 AND.W R10, R10, R0
 0x7001'7c54: 0x1e90 SUBS R0, R2, #2
 0x7001'7c56: 0x0140 LSLS R0, R0, #5

I'm noticing that, most of the time, the hard fault happens because the instruction [_ZN8touchgfx12LCDGPU2D_AXI30blitCopyCompressedRGB565_16BPPEPKhRKNS_4RectES5_h + 0x4e7]

The issue seems to occur only on a cold boot, so debugging it is even harder.

[mathiasmarkussen]

Can you check in your map file what is at address 0xfc7ff7c0?

Also check the address of the two scratch buffers - they should be 16-byte aligned.

[nico23]

There's nothing at 0xfc7ff7c0; it is not a valid address

---

@mathiasmarkussen wrote:

Also check the address of the two scratch buffers - they should be 16-byte aligned.

---

Where can I see it?

[nico23]

Update

Commenting out the task running TouchGFX, the issue no longer appears so I'm guessing there's something in TouchGFX that, loading the first view or even initializing itself create some memory issue

 

[Hamady]

@nico23 I also got pretty similar scenario where the board doesn't always work at first boot i have to rely on the WWDG or press reset to make things work. 

And it is hard to debug because it doesn't appear if i use debbuger software.

[nico23]

Hi @Hamady , 

The strange thing is that from the call stack and errors, it seems an issue inside the TouchGFX library, as, during the initialization process, everything returns HAL_OK and starts correctly (I2C, external flash, DMA2D, etc), but when it comes to load and decompress images, it crash.

The flash seems ok as the J-Link can easily erase, read, and write the whole flash with no issue.

Do you have a custom-made board?

[Hamady]

Hi @nico23 

I have a custom made board that share the same PSRAM and FLASH as the DK board + SMPS supply for H7.

In terms of hardware nothing seems to fail.

Thanks