SOMRT1061 system crashes
Posted: Mon Jun 15, 2026 1:08 pm
I've made a break out board for the SOMRT1061 so that I can use it as a drop in replacement for systems using the MOD5441X board.
I'm using the same code base to compile for the MOD5441X board under the 2.9.7 kernel and compiling for the SOMRT1061 under the 3.5.7 kernel.
Both system run, but the code base on the SOMRT1061 would hit a trap at random intervals, sometimes within a few minutes, and sometimes it would take an hour or more.
More often than not, I get a trap very similar to this:
Always a trap with PriMask 1.
The Ethernet Task is typically the one where the trap occurs. Looking at the memory map, the Ethernet send stack ENDS at 200C0C8.
Since the stack here appears full, I figured compiling with NBRTOS_STACKCHECK, NBRTOS_STACKOVERFLOW, and NBRTOS_STACKUNDERFLOW would immediately throw exceptions, but it makes no difference.
As a last ditch, I doubled the Ethernet stack size, and now the crashes have stopped (at least for the last 4 hours which is longer than I've ever had it go)
I don't have any of my Tasks or variables running in fast memory. Everything is statically allocated, but pointers are used.
I do have an ISR (running at a priority of 2) which posts to a mailbox, and I'm using one of the Timers, which also only posts to a Mailbox, I don't think these are the culprits.
Just looking for some thoughts on where else I should be looking -- the MOD5441X has no crash/reboot issues, I've had this code running out in the field for years...
Thanks!
I'm using the same code base to compile for the MOD5441X board under the 2.9.7 kernel and compiling for the SOMRT1061 under the 3.5.7 kernel.
Both system run, but the code base on the SOMRT1061 would hit a trap at random intervals, sometimes within a few minutes, and sometimes it would take an hour or more.
More often than not, I get a trap very similar to this:
Code: Select all
-------------------Trap information-----------------------------
Trap Vector = (04)
MMFSR = 82
MMFAR = A9000008
FPCAR = 602BEF80
xPSR = 60000004
PriMask = 01
FaultMask = 00
BasePri = 00
Faulted PC = 00009082
-------------------Register information-------------------------
R0 =A9000000 R1 =20001CEC R2 =00000000 R3 =00000001
R4 =00000009 R5 =20001CEC R6 =20001D0C R7 =20001D2C
R8 =60340BEC R9 =00000004 R10 =20001E80 R11 =202018C4
IP[R12]=00000000 SP[R13]=2000BFD0 LR[R14]=6006684B PC[R15]=00009082
XPSR =81000200
-------------------RTOS information-----------------------------
Priority masking indicates trap from within ISR or CRITICAL RTOS section
Current task prio = 00000026
Current task TCB = 20002050
This looks like a valid TCB
The current running task is: Enet#26
-------------------Task information-----------------------------
Task | State |Wait| Call Stack
SPI#21|Mailbox |0001|00008CF6,000095BE,000090D8,6002A7A8,000112BC
FIFO#22|Mailbox |0008|00008CF6,000095BE,000090D8,600115CA,000112BC
TIMER#24|Mailbox |0014|00008CF6,000095BE,000090D8,6005A4B6,000112BC
Enet#26|Running | |00009082,00000000,2000FF40
HTTP#27|Semaphore |0014|00008CF6,000095BE,00009010,60066B80,60066C14,60066C44,600657FA,000112BC
Config Server#28|Semaphore |0077|00008CF6,000095BE,00009010,60066B80,60066BDC,6006DBA2,60060F22,000112BC
MODB#2C|Timer |0001|00008CF6,000095BE,00008D68,6004A918,000112BC
LCD#31|Mailbox |0001|00008CF6,000095BE,000090D8,60012534,000112BC
Main#32|Mailbox |04AA|00008CF6,000095BE,000090D8,60008DC0,6004A5B2,000112BC
SSDP#3D|Fifo |000E|00008CF6,000095BE,0000930C,0000BCA0,6004C2C8,000112BC
BKG#3E|Queue |000E|00008CF6,000095BE,000091E4,6000B74C,000112BC
Idle#3F|Ready | |6007A142,000112BC
-------------------Process Stack Dump----------------------------
2000BFB0: A9000000 20001CEC 00000000 00000001 00000000 6006684B 00009082 81000200
2000BFD0: 6032C698 00000001 6006684B 2000FF40 00000000 2000C048 00000083 202B8036
2000BFF0: 6034078C 6006687B 00000000 000040FF 20003B74 20002050 6034078C 00009601
2000C010: 6034078C 0000953B 2000C048 000020A5 00000001 202B7FC0 00000036 202B8000
2000C030: 00000014 202029A8 20001E84 00000000 202018C4 00004899 202B7FC0 202B8022
2000C050: 202B800E 202B7F00 202B8036 202B0000 202B7FC0 0000B081 20200C40 00000001
2000C070: 202018B0 20001E80 202029A8 00007273 00000000 00000000 00000E7D 00000E7E
2000C090: 00000000 00000004 00000005 00000006 00000007 00000008 00000009 0000000A
2000C0B0: 0000000B 000112BD 60365941 00000000 00000000 00000000 00000000 00000000
2000C0D0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C0F0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C110: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C130: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C150: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C170: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C190: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C1B0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C1D0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C1F0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000C210: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
-------------------Stack dump------------------------------------
20001CA0: 00000003 00000000 00000003 00000000 00000003 00000000 60360B00 0000000F
20001CC0: 0000000F 0000000F 00000000 00000000 00000000 00000000 00000000 00000000
20001CE0: 00000000 00000000 2000FF40 00000009 00000000 00000000 00000000 00000088
20001D00: 00000000 00000000 00000000 00000008 00000000 00000000 00000000 00000080
The Ethernet Task is typically the one where the trap occurs. Looking at the memory map, the Ethernet send stack ENDS at 200C0C8.
Since the stack here appears full, I figured compiling with NBRTOS_STACKCHECK, NBRTOS_STACKOVERFLOW, and NBRTOS_STACKUNDERFLOW would immediately throw exceptions, but it makes no difference.
As a last ditch, I doubled the Ethernet stack size, and now the crashes have stopped (at least for the last 4 hours which is longer than I've ever had it go)
I don't have any of my Tasks or variables running in fast memory. Everything is statically allocated, but pointers are used.
I do have an ISR (running at a priority of 2) which posts to a mailbox, and I'm using one of the Timers, which also only posts to a Mailbox, I don't think these are the culprits.
Just looking for some thoughts on where else I should be looking -- the MOD5441X has no crash/reboot issues, I've had this code running out in the field for years...
Thanks!