HardFault_Handler() error: Why the generated code try to read address beyond valid memory range on 0xfffffffd?

[BParh.1]

So I tried to implement USB Host via USB_OTG_HS peripheral. I enable all the interrupts under NVIC setting (as I don't understand which one to choose).

When I attach my USB stick, it is able to detect the USB, the user callback USBH_UserProcess() is triggered with id HOST_USER_CONNECTION. However, when I release the breakpoint from there, software went to Hard Fault, call stack is below:

Thread #1 [main] 1 [core: 0] (Suspended : Breakpoint)	
	HardFault_Handler() at stm32f7xx_it.c:102 0x80032de	
	<signal handler called>() at 0xfffffffd	
	prvPortStartFirstTask() at port.c:261 0x800bdd8	
	xPortStartScheduler() at port.c:367 0x800c068	
 

I noticed just prior to the hard fault, it tried to access memory 0xfffffffd which I dont recall any of my data or code reside there. The code is so far one generated by the STM32CubeMX tool. Following is the disassembly when that 'suspicious' memory access done:

fffffffd:   Failed to execute MI command:
          -data-disassemble -s 4294967293 -e 4294967392 -- 3
          Error message from debugger back end:
          Cannot access memory at address 0xfffffffc

So why would the code try to access this memory, what it tries to do?

[BParh.1]

As additional point, I take a look the MCU Reference, on the memory map, address 0xfffffffd belongs to 'Reserved' area, so why would the code try to access it? This far, I have not event put any of my code, still generated code.

[Tesla DeLorean]

Seems more like a double fault

The 0xFFFFFFFD is a magic LR value to unwind an interrupt/exception, think of it as a call-gate which pops the MCU context from the appropriate stack.

A disassembly isn't going to work, you'd do better inspecting the stack in the Hard Fault Handler.

Look at what prvPortStartFinishTask() is doing at line 261 in port.c

[BParh.1]

Thanks @Community member​ , does STM32CubeIDE happen to have feature to view the stack? How usually you do it?

[BParh.1]

If I suspect it might be related to stack overflow, is there any quick way to see the indicator of it? Any register set? or the IDE can help in someway?

[Tesla DeLorean]

I expect you can memory dump via the stack pointer (SP)

I typically have a Hard Fault Handler that dumps the internal state and optionally dump some of the stack frame. Posted several examples to the forum.

[BParh.1 · Accepted solution]

So it seems the hard fault was due to stack overflow, I increase the default stack size for the USB task from default 128 to 1024. But this is found by hunch only, I could not relate systematically from the the failure to stack overflow.

If this is the case, I wonder why STM32CubeMX set default USB Middleware task size as 128? Anyway I can ping the person in charge?

[hs2]

The stack size was by far too small (seems just the configMINIMAL_STACK_SIZE was used, which covers the bare minimum FreeRTOS itself requires).

However, when using FreeRTOS I’d also strongly recommend to define configASSERT and also enable stack overflow checking  for development/debugging. There is also a good FAQ and worth reading along with a dedicated doc regarding hardfaults.

[BParh.1]

Thank you @hs2, very handy tips 👍