PRD_getticks() misbehaves on C6416T?

Nguyen,

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar and interesting topics.

Which version of BIOS are you using? (for information only, not a suspected problem area)

 You definitely should not be seeing this type of behavior based on the description you have given. I notice two interesting things from your five FS_ISR lines:

1. The sum of "delta" on lines 81 and 83 = 35 which is what you would have expected if the glitch had not occurred.

2. On line 83, the HW=0424 does not match the difference between CNT2 on line 82 minus CNT2 on line 81. It is as if you were subtracting CNT2 of line 83 from CNT2 of line 80. Is that the case?

It is very odd that you get a short count in the accumulation counter of PRD_getticks and a long count from CNT2.

Does the PRD_getticks always stay in sync when you combine the glitch count and the next count? If so, this implies that there is noise on your INT4 line. But the extra long CNT2 seems to counter that thought.

Can you eliminate all other code besides these functions. Have the DSP just executing IDLE except when timer ticks occur and when the INT4 occurs. We need to eliminate any side-effects from your other code.

Regards,
RandyP

Hello Randy,

Thanks for getting back.  Here is more information and explanations.

I have no idea what BIOS version we have, but we used CCS 3.1.

1. I had a filter to "filter out" small glitch.  When there is a glitch, I just report the glitch, but do not update the timestamp.  The intention was if I can't chase to the root cause, I can still filter out the unwanted interrupt (it it is truly noise).

2. The same thing was also applied to HW(delta).  When glitch happens, I just report the glitch, and the next calculation based on the previous timestamp/counter.

The PRD_getticks seems to stay in-sync with the clock when you combine the glitch with the next count.   Is it possible that the HWI dispatcher (written in C) can be invoked a few times within the same ISR?

I really like to believe that there is noise on the INT4 line, but the CNT2 points to something else.   With noise, I can debounce and filter it.  If the PRD_getTicks() is not reliable, then I can't really filter out the signal.

My code was pretty much just INT4_ISR().  I will retry the experiment and see if there is anything new. 

If you have new ideas, please let me know.

Thanks,

Nguyen

Nguyen,

Nguyen Nguyen said:

Is it possible that the HWI dispatcher (written in C) can be invoked a few times within the same ISR?

Yes and no. You can make your ISRs re-entrant if you wish, but by default all interrupts are prevented or masked until you have finished the execution of the current ISR. Check your HWI Dispatcher configuration for the FS interrupt and the CNT2 interrupt.

Regards,
RandyP

We don't do anything special to the HWI dispatcher for frame sync.  So, it's unlikely that the framesync ISR gets called multiple times from the same interrupt.

Where do you check for CNT2 interrupt?   Is it under Clock Manager/PRD_clock?   How can I attach the CDB file?  The server does not allow me to upload a cdb file.

Thanks,

Nguyen

Nguyen,

The "delta" issue is something I would approach as a problem with noise on the input line. This is something you should debug first at the electrical level on your board, and only as a last resort as a software glitch filter, in my opinion.

The CNT2 discrepancy is something else entirely and also needs some detailed debug on your code to figure out if there is something that can be done to fix it. Your entire system, especially when reduced to only these components, must be tested and instrumented heavily enough to figure out what is going wrong.

CNT2 seems to be just a timer that is counting up from 0 to 0xFD51DA80. There should be nothing affecting it, but there seems to be something affecting it. Look for something in your code that mistakenly writes to the CNT2 register.

There is likely no need to even try to upload your cdb file. You should know if there is an interrupt associated with CNT2, and it would not be asserted anyway until CNT2 reaches the PRD2 value. Looking at code or cdb files will not be a way that we can help, again in my opinion.

Regards,
RandyP

Thanks RandyP.  We now have a counter on the generator side of the frame synch and can compare it with the DSP interrupt count.  At lower frame rate (10 FPS or under), the two counters match.  But at higher frame rates (20 FPS), the DSP interrupt count is actually less than the generator count after running for a about 30 mintues.  We have a scope probe tapped right into INT4 to monitor glitches on INT 4, it appeared to be normal. 

At this point, we can move forward with the lower frame rate.  Will have to re-investigate this later.

Thanks,

Nguyen