TMS570LC4357: eQEP IRQ stops being called when using a maskable IRQ

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Hello,

I posted a question earlier about the RX IRQ of the EMAC that stopped being called.

By doing more analysis and by testing other peripherals of the CPU, we got to the point where the IRQ of the eQEP is not being called anymore. This seems to be linked to the usage of the maskable IRQ RTI CMP3. We follow the guidelines listed by the application report SPNA219 and reviewed it many times to make sure we didn't miss something.

We created a simple project using the Launchpad of the TMS570LC4357

In the attached project, we need to apply a 1khz signal on the input J1_7 of the launchpad. After 10 minutes (can sometimes be longer), the IRQs are not called anymore. By using the buttons, it is possible to force a clear of the IRQ and then it starts working again.

Here are the traces on the serial interface that we can see:

------------------------------------------------------------------------------------------------------
Welcome to the Hercules Launchpad demo
------------------------------------------------------------------------------------------------------
1> USER LED B (LED3) blinking frequency is controlled by the ambient light sensor.
2> USER LED A (LED2) is blinking every 250ms.
Vary the intensity of the light on the sensor to observe the response.
3> Press USER SWITCH A button to clear QEP1 pending IRQs.
4> Press USER SWITCH B button to clear QEP2 pending IRQs.
------------------------------------------------------------------------------------------------------
PLEASE DO POWER ON RESET(PORRST) WHENEVER YOU SEE ERR LED ON
------------------------------------------------------------------------------------------------------


Potentiometer Reading: 3
QEP1 Period: 1001us
QEP2 Period: 1001us

Potentiometer Reading: 3
QEP1 Period: 0us <== IRQ not called anymore, so period seen is 0
QEP2 Period: 1000us

Clear QEP1 pending IRQs <= press the button
Clear QEP1 pending IRQs
Clear QEP1 pending IRQs

Potentiometer Reading: 3
QEP1 Period: 1001us <= starts working again
QEP2 Period: 1001us

Do you have any clues about the cause of this issue?

Please let me know if you need more details.

Kind regards,

Frederic.

LAUNCHXL2_570LC43_EQEP.zip

  • I will take a look at your code, and come back to you later.

  • Happy New Year QJ!

    Did you have a chance to try the code I sent regarding this issue? Have you been able to reproduce it?

    Best regards,

    Frederic.

  • Hello QJ,

    do you have any updates regarding this ticket? Have you been able to test the code on your side?

    Kind regards,

    Frederic.

  • Hello QJ,

    any update on this issue?

    Do you have any hints of things to look for regarding this topic? We have been going through the technique note for the nested IRQ many times, with many engineers, and can still not see what is going wrong.

    Many thanks

    Best regards,

    Frederic.

  • Hi QJ,

    The original question from Frederic, was back in November 2020.

    It has been almost 4 months now without much help.

    We cannot afford waiting anymore time. We need to know if the SPNA219 (Nested Interrupts on Hercules...) can be used or not on the TM570LC4357 without losing interruptions.

    Regards,

    Nicolas

  • The code has been executing for 8 hours, I have got the issue so far.

    I generate 1KHz PWM using ePWM, and feed this PWM signal to eQEPA, and  eQEP is used as UP-count mode.

  • Hi QJ,

    One difference with our setup is that we use an external 1KHz PWM source to feed the signal to eQEP1A and eQEP2A.

    Internal ePWMs are not used. Try to keep the provided halcogen configuration and source files as is with no change. Otherwise it could be harder to reproduce. I reproduce the issue every 10-15 minutes.

    For reference (in case it matters):

    Halcogen: v04.07.01

    Code Composer studio: v8.2.0.00007

    Arm compiler: TI v18.1.3.LTS

    Regards,

    Nicolas

  • I will do a test with an external PWM signal.

  • I generated the issue using irqDispatch for RTI_Compare3. If irqDispatch is not used, or nested IRQ interrupt is not used, there is no issue.

  • Ok great we are on the same page. We need this nested IRQ interrupt mechanism in our application.

    rtiCompare3Interrupt uses the code provided from the application note SPNA219, see page 7, 8. We believe that something is missing in the application note to make this nested feature really working. What could be wrong or missing ? Why eQEP's interrupts stop being executed ?

    One clarification in case it helps, we lower the priority of rtiCompare3Interrupt to make sure eQEP interrupts can interrupt the rtiCompare3Interrupt.

    // Lower the priority of the IRQ RTI1 CMP3
    vimChannelMap(5, 124, rtiCompare3Interrupt);
    vimChannelMap(124, 5, phantomInterrupt);
    vimEnableInterrupt(124, SYS_IRQ);
    vimDisableInterrupt(5);

    Regards,

    Nicolas

  • I will study the dispatch 

  • Hello QJ,

    any luck in your analysis of this issue? Is there something we could try to help resolve this?

    Kind regards,

    Frederic.

  • Hi Frederic,

    Actually I didn't find any problem with the assembly code in irqDispatch. 

  • Hi QJ,

    we think we have found the issue (after months of investigation!). Here is a small explanation of the issue, in case someone would take our example to implement the maskable interrupt for a single IRQ.

    The handler of the maskable IRQ handler rtiCompare3Interrupt was implemented like this in the snippet of code sent:

    __REENTRANT_IRQ__(rtiCompare3Interrupt)
    {
        uint32 u32IrqIndex = vimREG->IRQINDEX;
    
        /* TI C Step 3 */
        /* Save VIM REQENASET[0,1,2,3] Registers for later restore */
        uint32 SaveREQMASKSET0 = vimREG->REQMASKSET0;
        uint32 SaveREQMASKSET1 = vimREG->REQMASKSET1;
        uint32 SaveREQMASKSET2 = vimREG->REQMASKSET2;
        uint32 SaveREQMASKSET3 = vimREG->REQMASKSET3;
    
        /* TI C Step 4 */
        /* Mask out lower priority IRQ's and the current IRQ itself, keep FIQ's enabled */
        if (96U < u32IrqIndex) /* 96-...*/

    It was assumed that vimREG->IRQINDEX contains the index of the IRQ being handled - this was taken from the example SPNA219 of TI, where all the IRQs are maskable. But in our case, where we have only a single maskable IRQ, we finally found that this index would change since the start of the execution of the handler (which is the assembly code, not the C code), leading to the wrong mask being calculated and preventing other IRQs from running. Instead of using vimREG->IRQINDEX for the index, we just hardcoded it using a define, that is also used to set the priority of the IRQ at other places in the code.

    We just finished running a week long test on our complete system and didn't see this issue again. This could have been seen within 1 day of execution before the change.

    Thank you QJ for your continued help with this issue. This issue can now be closed.

    Kind regards,

    Frederic.