• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 1358 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.

RM48L950: SCI negatively impacting my RTI timers

Jamie Wardlaw
Expert 1895 points

Part Number: RM48L950

I have noticed that a series of SCI transmits are negatively impacting my RTI timers.

My application has RTI counter zero to configured generate an interrupt on 4 periods delivering 1ms, 10ms, 100ms and 1000ms callbacks. In the callback functions I process a series of timers which are configured for 1ms, 10ms, 100ms, 1000ms resolution respectively. The resolution of the timers has, to date, never been a concern of mine.

However, I recently loaded up my 1000ms callback with a debug output on the SCI channel. The debug output is quite weighty and would appear to be a source for the 1ms tick starting to lag behind the 1 sec ticks.

For example, after 845 1second ticks I have only seen 755106 1ms ticks. This never used to be the case, previously the 1sec tick would rollover exactly as you would expect at the 1000th increment of a 1ms tick.

The only difference between the two builds is that I have this call to SCI communications debug output every 1 second. In total SCI is outputting approx. 50 bytes at 9600baud. So by my calculations that should take 0.04s; which is of course longer than 1ms and also 10ms. So there is every reason to expect the SCI driver routine to be interrupted by both my 1ms tick and 10ms tick.

Question I have is why does the RTI interrupt not get priority over the SCI driver. I have set the SCI driver to low level in HALcogen. I cannot find where else I can increase the RTI priority but I assume, for now, that it should be possible to have my 1ms ticks take priority?

Thanks in advance for any info in optimizing the RTI setup.

Jamie

  • 0
    Expert 1895 points

    As an addition to this, why would I use the notification routines in place of the compare interrupt routines to handle my callback?

    void rtiCompare3Interrupt(void)
{
/* USER CODE BEGIN (83) */
/* USER CODE END */

    rtiREG1->INTFLAG = 8U;
    rtiNotification(rtiNOTIFICATION_COMPARE3);

/* USER CODE BEGIN (84) */

    UNI_TIM_timers_1sec_cbk();

/* USER CODE END */
}

    This is what I have just now, i've never seen any reason to move the callback function to the notification routine.

  • 0 in reply to Jamie Wardlaw
    TI__Guru 59540 points
    Hi Jamie,

    First I apologize for the delay in responding to your questions.

    In regard to your question, when you adjust the SCI interrupt priority, does this resolve the latency issues with the RTI interrupt? It is also possible to designate the RTI interrupt as an FIQ vs the IRQ for the SCI interrupt. The FIQ interrupt will take priority over the IRQ.

    In regard to where you put your callback functions, I think this is up to you. So whatever you system level needs require and shows to work is fine. There are no hard requirements to keep the call back functions in the notification functions themselves.
  • 0 in reply to Chuck Davenport
    Expert 1895 points

    Changing the priority of the SCI interrupt did not make any apparent difference. What I did do was restructure my debug output to minimize the number of bytes transmitted and also moved them to the 1sec callback. This improved what I was seeing in ms versus second drift but did not remove the problem completely.

    I will the RTI as FIQ and see if that helps. It still surprises me that the the changed in interrupt priority (level) did not fix it.

  • 0 in reply to Jamie Wardlaw
    TI__Guru 59540 points
    Hi Jamie,

    Sorry for the late follow up but did the change to FIQ show any improvements? I am also surprised that the change in priorities did not show improvements. Do you allow nested interrupts in your application?
  • 0 in reply to Chuck Davenport
    Expert 1895 points

    Hello Chuck,

    I looked in to the FIQ and read that the use of these interrupts is recommended to use assembler for implementation, I also think that the logic I have in the interrupt routine is perhaps something I could optimize further before trying this. So, in short, no I did not try the FIQ as I don't think it would be a permanent fix for me just now.

    The priority change no helping did confuse me, I really need to throw a logic analyzer on this to get a clear picture of the delays we are seeing. Right now i'm not able to devote the time to it.

    Can you comment on the allowance of nested interrupts - is this something I should be setting up specifically or are you referring to the possible side affects of data in one lower priority interrupt being modified in a higher priority one - and the negative affects that can have depending on the application.

    thanks

    Jamie

  • 0 in reply to Jamie Wardlaw
    TI__Guru 59540 points
    Jamie,

    My question about nested interrupts was more related to if you are not using them. i.e., if the SCI interrupt is consuming all of the avaialble CPU resources, the RTI interrupt may only get service periodically which would impact its effectiveness even if the SCI is a lower priority.
    We have an application note on nested interrupt usage with Hercules at this link in case you are interested: www.ti.com/.../spna219.pdf