STR736FV2 getting reset (STACK overflow, watchdog, ....?)

[kalpesh]

Posted on July 08, 2011 at 12:26

Hi All,

We are using STR736FV2 in one of our products. The complaint which is being reported from field is system restarts randomly. What are the different reasons why it should get restart? Can we dignose it by any status register in the controller? Can we log stack overflow event??? In the map file we observed CSTACK and IRQ stack are being used more than other stacks. It is revers stack as per our observations. If it gets overflowed will the RAM be intact on software reset? Is there any mechanism which sets all variables to default at startup before main()???? Any help regarding reset, Stack, Watchdog, Diagnosis is really helpful. It is very URGENT and CRITICAL Please reply -KP

[Tesla DeLorean]

Posted on July 27, 2011 at 21:57

What's the hazard pay like for URGENT and CRITICAL type work?

The reset type is going to be reflected in RCCU_CFR (Clock Flag Register) The SRAM at the point of the reset will contain whatever was there prior to the reset. Prior to running main() your startup code and C Run Time (CRT) code will likely copy static data from FLASH into SRAM, and clear some of you initialized variables. Variables you don't explicitly clear, or the the CRT doesn't clear, will have whatever random data happens to be in RAM. Suggest you take a snap-shot of memory at reset. Place some guard regions under your stacks, fill them with identifiable patterns, and periodically examine them, add some stack checking in your code. Park a memory view window over them with your debugger/JTAG tool. Examine the call tree for your code, and see if your tool chain provides an estimation of stack usage. If not figure it out manually. Look for stupidly large local variable allocations. Check for things like printf/scanf, insufficient stacks will often cause the heap or static memory to get corrupted.