I am using an OMPA3530 on a Beagle Board using SYS/BIOS 6.33. I seem to have found an issue when calling the SYS/BIOS TimestampProvider_get32 function. I posted on this board however (instead of the SYS/BIOS board) because I tracked down the issue to what seems to be the actual ARM performance counter operation itself rather than SYS/BIOS code.
My simplified stressing test case is a tight infinite loop that simply calls TimestampProvider_get32 and compares the returned count value to the previous read one. If they match, I indicate the problem has occurred.
for (;;){ static unsigned int LoopCount = 0; static unsigned int PreviousTimerCount = 0; const unsigned int TimerCount = TimestampProvider_get32(); if (TimerCount == PreviousTimerCount) { DebugMessage("(%9u): Test condition found.\n", LoopCount); } PreviousTimerCount = TimerCount;
LoopCount += 1;}
It sometimes takes a while (last test took 1,847,524,956 times through the loop) but eventually the error condition is seen. Whenever it does occur, the count value is *always* struck at 1. Using an emulator (XDS510) to single step through the assembly code reveals that the TimestampProvider_get32 call ultimately executes the following assembly instruction:
MRC P15, #0, R0, C9, C13, #0
to read the 32 bit portion of the performance counter and this assembly instruction always writes a value of 1 to register R0 once this error occurs.
So it looks to me that there is a condition that can cause the ARM performance counter to get “stuck”. Has anyone seen this before? Are there any errata on this problem? Is there any way to prevent this from happening? Is there any way to clear this condition (short of a processor reset) once the condition occurs? Although my stressing case is not realistic for a real-world application, my concern is that there may be a small, but non-zero, probability of this error occurring during long periods of software operation.
Thanks for any help.
Whoops! I meant to post this on the OMAP35x Processors Forum. My apologies.