application running and hit hard hault

Hi, I have stucked with this system hault for days, and I have no advanced debug method so far. scenario: application running for hours and it hits hard hault. I dump the exception frame and register as below: map: 00051114 00000092 portasm.obj (.text) 000511a6 00000002 –HOLE– [fill = 0] … 0005b154 00000040 port.obj (.text:xPortStartScheduler)
0005b194 00000040 timers.obj (.text:xTimerGenericCommand) … 2003ba94 __stack
2003ea94 __STACKEND 2003ea94 __STACKTOP [Exception Frame]
2003EA94 00F00000 00000001 00000000 2003B880 0005B189 00051194 41000200 [ACTLR] 00000000
[INTCTRL] 0043B803
[SYSCTRL] 00000000
[CFGCTRL] 00000200
[SYSPRI1] 00000000
[SYSPRI2] 00000000
[SYSPRI3] E0E00000
[SYSHNDCTRL] 00000000 [FAULTSTAT] 00000001 [HFAULTSTAT] 40000000 [MMADDR] E000ED34
[FAULTADDR] E000ED38 I did some survey for this issue, and the generic solution is increasing stack size. I try to increase task stack size and system stack size, but it can’t solve this issue. I have some questions about this fault: 1. why xPortStartScheduler() stored in exception frame? 2. I try to make a crash in timer callback and I can get the same exception frame. In my understanding, xPortStartScheduler executed at system init once. Does anyone has some debug suggestion for me? thanks Gavin

application running and hit hard hault

BTW, I use FreeRTOS V7.1.1 and TM4C129

application running and hit hard hault

  1. why xPortStartScheduler() stored in exception frame?
Probably because interrupts and exceptions use the same stack as main(), and the last thing main() did was call xPortStartScheduler().

application running and hit hard hault

That is VERY old and you may have saved yourself all the time you refer to if you were using a later version as later versions have many more configASSERT() points to help you diagnose issues, plus additional things like improved stack overflow checking, malloc failed hooks, etc. I would recommend taking the head revision out of SVN.