The application crashes after 40days

[kumarjosh]

We are facing a problem with our application which crashes after 40days.
The log indicates the following trap is occurred.
-------------------Trap information-----------------------------
Exception Frame/A7 =021A8AC4
Trap Vector =Access Error (2)
Format =03
Status register SR =2504
Fault Status =0C
Faulted PC =020ED4B4

-------------------Register information-------------------------
A0=1E920449 A1=000000A1 A2=000000A2 A3=000000A3
A4=000000A4 A5=000000A5 A6=021A8AE0 A7=021A8AC4
D0=00000000 D1=0036DB20 D2=00000014 D3=00000013
D4=000000D4 D5=000000D5 D6=000000D6 D7=000000D7
SR=2504 PC=020ED4B4
-------------------RTOS information-----------------------------
SR indicates trap from within ISR or CRITICAL RTOS section
OSIntNesting indicates trap from within ISR OSIntNesting=01
The OSTCBCur current task control block = 021A8B40
This looks like a valid TCB
The current running task is: Idle,#3F
-------------------Task information-----------------------------
Task | State |Wait| Call Stack
Idle,#3F|Running | |020ED4B4,020EC934,0
User,#0A|Timer |0058|020ED42E,020CF4FC,0204F64A,0204F93A,02009CDA,
TCP ,#28|Semaphore |0001|020EDAA2,020047E6,0
IP ,#03|Fifo |0004|020EE862,020089C2,0
Esnd,#02|Fifo |0028|020EE862,020066CC,0
User,#08|Semaphore |0000|020EDAA2,020F372C,020054A6,020055C4,020EFAF8,
User,#07|Semaphore |0000|020EDAA2,02001BAC,0200B21C,0
User,#06|Timer |0008|020ED42E,0200AF5E,0
User,#38|Semaphore |007D|020EDAA2,020CF6CE,0211EEA2,020D8562,020D8DA4,
User,#10|Semaphore |0000|020EDAA2,020CF6CE,020436E8,0
User,#0D|Semaphore |0000|020EDAA2,020CF6CE,020437E6,0
HTTP,#2D|Semaphore |0000|020EDAA2,02001BAC,020F20B4,0
User,#17|Semaphore |0001|020EDAA2,020CF6CE,02014404,020CF39A,0
User,#13|Fifo |FFFF|020EE862,02008C74,020CD5E4,020C117A,020BABA8,
User,#11|Fifo |0000|020EE862,02008C74,0202B416,0202A0D0,020CF39A,
User,#05|Fifo |03A5|020EE862,02008C74,020CD5E4,020793F6,02063708,
-------------------TCB information-----------------------------
uc/OS Stacks
Name Prio SPtr SBottom Free Minimum

Idle,#3F|0000003F|021A8AEC|021A4B3C|00003FB0|00003E68
User,#0A|0000000A|021A3C40|0219FDE4|00003E5C|000023F0
TCP ,#28|00000028|0250EAF0|0250ABA0|00003F50|00003EA8
IP ,#03|00000003|025187F4|025148A8|00003F4C|00003D80
Esnd,#02|00000002|02514408|025104B8|00003F50|00003E1C
User,#08|00000008|0254D364|0254BB80|000017E4|00000EC0
User,#07|00000007|0254E8E8|0254DAE0|00000E08|00000E08
User,#06|00000006|0254F660|0254EAF0|00000B70|00000AE4
User,#38|00000038|02552268|0254FED0|00002398|000011DC
User,#10|00000010|02554B08|02552BD0|00001F38|00001B30
User,#0D|0000000D|02556B38|02554BE0|00001F58|00001D40
HTTP,#2D|0000002D|02533A98|0252FBA8|00003EF0|000035F0
User,#17|00000017|02559628|02556FE0|00002648|000005E4
User,#13|00000013|025640A0|0255F870|00004830|000026C0
User,#11|00000011|0256A258|02565610|00004C48|00003DB4
User,#05|00000005|0257D794|025773F0|000063A4|00005B40

-------------------End of Trap------------------------------------------------

1.he PC (program counter) in trap points in OSTimeTick () function and it does not given any clue to fine cause of trap.

2.The “RTOS information” indicates that trap is with ISR.
Please let me know, is the there any information in this trap, indicate which ISR routine caused problem?
4.What “Status register SR =2504“indicates to us?

I would like to know how many interrupts are supports by module5272.
Any sort of directions or suggestions are welcome to resolve this issue.
Thanks
Kumar V

[Ridgeglider]

Sounds like one of your task stacks is overfowing eventually. If you allot more stack space to the tasks, does your app run longer? To figure out which task might be the problem try uncommenting the line:
#define UCOS_STACKCHECK (1) in predef.h.
Add the line:
#include <taskmon.h>
Recompile everything. Then either enable taskscan or periodically call OSDumpTCBStacks().
Both are described in C:\Nburn\docs\NetBurnerRuntimeLibrary\uCOSLibrary.pdf
Both show current and max task stack usage. If a stack is leaking, you can often see it creeping up towards the allotted limit with these tools. Won't ID the source of the leak though.

[khoney]

Hmm... I threw some status info to MTTY and it appears when the lockup occurs I'm calling OSTimeDly and never returning. This is for the lockup case.

[khoney]

Same thing when a trap occurs. I make the same OsTimeDly call and then the trap occurs.

[khoney]

OOPS! - Sorry, above 2 posts made to wrong thread by accident.

[rnixon]

This is a really wild guess: When you call OSTimeDly(), it is a blocking function, so the scheduler will be called. So if any of your tasks have a memory corruption problem (which is my guess), whether it be a stack overflow, array out of bounds or a bad pointer, it could happen at that point because that is when the task swap takes place. As someone else suggested, a task stack overflow would be the first thing I would look at.

[kumarjosh]

Hi rnixon & khoney
I think you are not answering to my question.

Thanks
kumar V

[kumarjosh]

Hi Ridgeglider,
Thanks for analyses and sugggestions.
I will look into this direction however the trap has “OSDumpTCBStacks” details.
The detail does not indicate a stack overflow.

Did you have any idea how get the list interrupts support by Net Burner?
Thanks
kumar V

[greengene]

<I would like to know how many interrupts are supports by module5272.>
you might call StdioCheckIntc() to see what interrupts are currently being used.

[pbreed]

rnixon's comment is right on.
If you crash after any blocking OS call then its most likely that its stack or memory corruption of some kind.