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.

TMS320F28069: IER configuration for nested Interrupts

Part Number: TMS320F28069


Hello Champs,

If two interrupts have been enabled (in different PIE group), when configuring nested interrupt (higher priority interrupt ISR can be served first):

if use AND instruction to enable the higher-priority interrupt in lower-priority interrupt ISR, it will not always be served first,

if directly set IER corresponding bit, it can successfully be served first.

Would you please kindly help why the higher-priority interrupt IER bit has not been set? Thanks!

Best Regards,

Linda

  • Hi Linda,

    Can you provide the snapshot of both the codes, working and non-working.

    Regards,

    Vivek Singh

  • Linda,

                Your question is not clear. Could you restate your question with specific interrupts, as an example? Also, the instances in time when the interrupts are asserted? Have you carefully read section 1.7 in SPRUH18G? It has good information on the conditions to be satisfied for an interrupt to be taken.

  • Hi Linda,

    Were you able fix this issue?

    Vivek Singh

  • Hi Linda,

    I was sent your code and did a bit of debugging. It appears to me that somehow the lower priority interrupt is managing to occasionally interrupt the higher priority interrupt. I'm still trying to figure out when it's managing to do this.

    However, that does explain why AND-ing didn't work when a straight assignment of the mask did. The assignment was re-enabling the higher group that has been disabled when its ISR was entered. It would be similar to doing IER|=0x1; before doing IER&=0x3;.

    Whitney
  • Hello Whitney,

    Thank you for your kind help.

    As described in F2806x manual, when entering ISR, corresponding IER bit will be cleared,that is to say other IER will not be cleared, is this correct?

    So AND instruction should be OK since when entering low-priority interrupt ISR, the higher-priority interrupt IER is still kept.

    Would you please kindly suggest? Thanks!

    Best Regards,

    Linda

  • That would normally be true, but what appears to be happening in your application is that occasionally the high priority interrupt is entered (its IER bit is cleared), and then it is being interrupted by the lower priority interrupt (lower priority IER is cleared and high priority IER bit is STILL cleared). That's why the higher priority IER needs to be re-enabled.

    I still don't know why the lower priority interrupt is interrupting the higher in the first place though. I will keep studying and see if I can find a fix for the root of the problem instead of the above workaround.

    Whitney

  • Hi Linda,

    I think I figured it out. You don't need to restore IER at the end of the ISR. IER is already backed up and restored by the hardware when an interrupt is taken. When you do it by software in the higher priority ISR and the flag for the lower priority ISR is pending, it causes the lower priority ISR to execute. Since it is nested, the IER for the higher priority ISR is still 0 and therefore can't run until the lower priority ISR finishes.

    So basically, remove IER_old and things should start working as expected.

    Whitney