UCOS_ENTER_CRITICAL()

[chan_24]

Upon trying to execute UCOS_ENTER_CRITICAL() the hardware reboots with the following trap information.

------Trap information-----------------------------
Exception Frame/A7 =021A8AC4
Trap Vector =Access Error (2)
Format =03
Status register SR =2504
Fault Status =0C
Faulted PC =020ED4B4
--------------------------

Does anyone know the reason for this?

[v8dave]

Can you show the code that you are using to make the calls?

Are you previously calling OSCritInit to initialise it?

[pbreed]

The USER_ENTER_CRITICAL forces all delayed cache writes to happen.
My guess is that its something earlier that is the problem.

Type putting in an

asm(" nop");

As this also forces delayed cache writes to happen.
When you get a trap the real source of the trap is often a few instructions earlier.


Paul

[chan_24]

The system reboots when UCOS_ENTER_CRITICAL section is called by OSTimeTick() function, which is periodically called by BIOS.

Paul,
As mentioned above, the hardware reboots and according to the Trap information, the last successful instruction executed is UCOS_ENTER_CRITICAL() [OSTimeTick].
Also the running task is shown as 'Idle'.

Further information:
-------------------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,


Paul,
Please correct me if I have understood it wrong. Above you have mentioned that even asm("nop") allows delayed casche writes, so could there be any issues if asm("nop") is called before UCOS_ENTER_CRITICAL()?

[pbreed]

The nop flushes all pending cache operations.

[pbreed]

It looks like its happening in an interrupt.
Do you have any user written interrupt routines?

Paul

[chan_24]

No there are no user written interrupts.

This issue happens if the hardware is running continuously for around 40 days. Hence to check this out, initialized the TimeTick value to 39 days and after 14 hours the same issue happened.

But initializing the TimeTick to 39 days, 14 Hours did not cause the issue as suspected.

,
Chandan

[tod]

What's the history? Is this a new app and it just hit its first 40 days and crashed. Is it an existing app that just started showing this behavior? If so did you make any changes recently? Are you using printf/sprintf or cout/ostringstream? In my experience, most traps trace back to a memory management error of some sort, two of the easiest are using sprintf on a buffer that is too small or using printf (or one of its variants) with a format specifier for the wrong type of variable. Did you use WinAddr2Line on the hex addresses? Did you lint your code?

Tod

[pbreed]

Did you change the default Ticks per second?

Do you have any user written interrupts that are watching timers?

Some thing in your code overflowing at 2560000 seconds?

[chan_24]

What's the history? Is this a new app and it just hit its first 40 days and crashed. Is it an existing app that just started showing this behavior? If so did you make any changes recently? Are you using printf/sprintf or cout/ostringstream? In my experience, most traps trace back to a memory management error of some sort, two of the easiest are using sprintf on a buffer that is too small or using printf (or one of its variants) with a format specifier for the wrong type of variable. Did you use WinAddr2Line on the hex addresses? Did you lint your code?

Tod

Hi Tod,
This is not a new app and the product is in the field since many years. But the issue was reported in the latest release we made. Yes we use iprintf, I will check and let you know if there are any mismatch in the type specifier.
Yes I checked on the faulted PC value. With the previous binary it pointed to UCOS_ENTER_CRITICAL() in function OSTimeTick (file name ucos.c).
With the latest binary it pointed to the line while ( ptcb->OSTCBPrio != OS_LO_PRIO ).

The function is as given below:
void OSTimeTick( void )
{
BYTE p;
OS_TCB *ptcb = NULL;
TimeTick++;
if ( ( TimeTick % TICKS_PER_SECOND ) == 0 )
{
Secs++;
}

ptcb = OSTCBList;

if(ptcb == NULL)
{
iprintf("OSTimeTick: the Task TCB is null \r\n" );
return;
}

while ( ptcb->OSTCBPrio != OS_LO_PRIO )
{
UCOS_ENTER_CRITICAL();

if ( ptcb->OSTCBDly != 0 )
{
if ( --ptcb->OSTCBDly == 0 )
{
p = ptcb->OSTCBPrio;
OSRdyGrp |= OSMapTbl[p >> 3];
OSRdyTbl[p >> 3] |= OSMapTbl[p & 0x07];
}
}
UCOS_EXIT_CRITICAL();
ptcb = ptcb->OSTCBNext;
}
}