• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 306 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

unsteady timer isr

WillCode4Beer
Prodigy 145 points

Using the 28335EZdsp (150MHz) with the onboard USB emulator, I configured timer0 to interrupt every 1uS.  The Timer ISR does nothing more than increment a variable and acknowledge the interrupt.  To verify, I temporarily used the GPATOGGLE register  in the ISR and an oscope and I was able to see that the ISR kept up and maintained 1 uS intervals quite well. 

Now I am no longer using the onboard USB emulator.  I'm using an XDS510 emulator, putting the code into flash, and copying portions of code to RAM, including the PieVectTable and the secureRamFuncs, which includes the Timer0 ISR.  However, the oscope no longer shows a steady 1uS interval.

It had worked when everything operated out of RAM.  I believe I've copied the necessary code to RAM for zero wait state operation.  So why does it no longer keep accurate time?  Did I miss something or am I asking too much of the processor to keep up?

  • 0
    TI__Guru* 93800 points

    WillCode4Beer said:
    code into flash, and copying portions of code to RAM, including the PieVectTable and the secureRamFuncs, which includes the Timer0 ISR.  However, the oscope no longer shows a steady 1uS interval.

    How much does it differ by?

    I would start by asking what the CPU is doing when it is interrupted.  If it is executing code then it is possible the code is holding off the interrupt.  For example, say an interrupt comes in during a RPT || instruction (single instruction repeated).  This can not be interrupted, so the CPU will have to wait.   Another example is a multiple-cycle instruction such as a BANZ - This instruction is multiple (4) cycles and will not be interrupted while in the pipeline.  In this case if the CPU is in an idle "do nothing" loop, the interrupt might be held off differently depending if the BANZ is being executed or not.  This is just an example - BANZ may not account for the delta in cycles.   Since you've moved code to flash - the wait states will come into play. 

    One way to prove this out is to put the CPU into idle using the IDLE instruction so it doesn't continue to execute "some code" which could change the interrupt response time. 

    for(;;)

    {

          <some code>

          asm("      IDLE");

    }

    Edit: removed reference to '30' cycles - cut and paste from another instance of a similar question. :)

  • 0 in reply to Lori Heustess
    Prodigy 145 points

    Turns out that when I moved to flash I neglected to initialize the Flash Control Registers per spra958k.  Added that code and the frequency returned to the "happy zone".  So, yes, the wait states were in play.

    Thanks for your input!