Skip to main content
BParh.1
BParh.1
Senior III
May 4, 2021
Solved

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

  • May 4, 2021
  • 8 replies
  • 7765 views

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?

This topic has been closed for replies.
Best answer by BParh.1

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.

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

8 replies

BParh.1
BParh.1Author
Senior III
May 4, 2021

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.

0693W00000ANEESQA5.png

Tesla DeLorean
Tesla DeLorean
Guru
May 4, 2021

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

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
BParh.1
BParh.1Author
Senior III
May 4, 2021

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

Tesla DeLorean
Tesla DeLorean
Guru
May 4, 2021

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
BParh.1
BParh.1Author
Senior III
May 4, 2021

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?

BParh.1
BParh.1AuthorBest answer
Senior III
May 4, 2021

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.

0693W00000ANEVYQA5.pngIf 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
hs2
Visitor II
May 4, 2021

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
BParh.1Author
Senior III
May 4, 2021

Thank you @hs2, very handy tips :thumbs_up:

Terms & ConditionsAccessibility statement