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.

AM2632: Systick interrupt stops.

Part Number: AM2632

Tool/software:

I'm running FreeRTOS, using SDK 10.01.00.31.  I have quite a few peripherals configured including the ADC and 3 uarts.  But not much code using them for this test.  I mention the ADC's because there was an issue in previous SDK's with enabling the ADC's and getting the systick to start correctly.  At some point during execution, nothing much happening other than serial comms to a logging port and comms to a TI BQ79361. The BQ runs it's serial at 1Mbit, so there are some 'fast' interrupts from there.  I mention the serial ports, because I can make the systick interrupt stop quicker with more serial comms happening.

After running, usually within a minute or 2, the systick interrupt just stops (interrupt 84).  When I say stops, the HwiP_irq_handler_c() function is never called again for the systick interrupt.  If the ADC is configured to run continually, the HwiP_irq_handler_c() is called for ADC interrupts.

Below is the snapshot of the RTI0 registers when it is in this state.  From what I can tell, the timer is still running: RTIFRC0, RTIUC0, and RTICOMP0 are all still being updated.  The other register settings appear as expected to me to generate an interrupt, yet none occur.  Is there a mask bit somewhere else I can look for to see if it is being masked somewhere else?

If there is a mask bit or some other setting in the RTI0 registers that is incorrect, what might cause that?  Again , there are a lot of serial interrupts happening- is there an issue there?

Thanks for you help.

RTI0_RTI0        MSS_GPIO    
    RTI0_RTIGCTRL    0x00000001    Memory Mapped    
    RTI0_RTITBCTRL    0x00000000    Memory Mapped    
    RTI0_RTICAPCTRL    0x00000000    Memory Mapped    
    RTI0_RTICOMPCTRL    0x00000000    Memory Mapped    
    RTI0_RTIFRC0    0x000589EB    Memory Mapped    
    RTI0_RTIUC0    0x00004239    Memory Mapped    
    RTI0_RTICPUC0    0x000061A7    Memory Mapped    
    RTI0_RTICAFRC0    0x00000000    Memory Mapped    
    RTI0_RTICAUC0    0x00000000    Memory Mapped    
    RTI0_RTIFRC1    0x0000875D    Memory Mapped    
    RTI0_RTIUC1    0x00000034    Memory Mapped    
    RTI0_RTICPUC1    0x00000000    Memory Mapped    
    RTI0_RTICAFRC1    0x00000000    Memory Mapped    
    RTI0_RTICAUC1    0x00000000    Memory Mapped    
    RTI0_RTICOMP0    0x000589F8    Memory Mapped    
    RTI0_RTIUDCP0    0x00000001    Memory Mapped    
    RTI0_RTICOMP1    0x00000000    Memory Mapped    
    RTI0_RTIUDCP1    0x00000000    Memory Mapped    
    RTI0_RTICOMP2    0x00000000    Memory Mapped    
    RTI0_RTIUDCP2    0x00000000    Memory Mapped    
    RTI0_RTICOMP3    0x00000000    Memory Mapped    
    RTI0_RTIUDCP3    0x00000000    Memory Mapped    
    RTI0_RTITBLCOMP    0x00000000    Memory Mapped    
    RTI0_RTITBHCOMP    0x00000000    Memory Mapped    
    RTI0_RTISETINT    0x00000003    Memory Mapped    
    RTI0_RTICLEARINT    0x00000003    Memory Mapped    
    RTI0_RTIINTFLAG    0x0000000F    Memory Mapped    
    RTI0_RTIDWDCTRL    0x5312ACED    Memory Mapped    
    RTI0_RTIDWDPRLD    0x00000FFF    Memory Mapped    
    RTI0_RTIWDSTATUS    0x00000000    Memory Mapped    
    RTI0_RTIWDKEY    0x0000A35C    Memory Mapped    
    RTI0_RTIDWDCNTR    0x002DFFFF    Memory Mapped    
    RTI0_RTIWWDRXNCTRL    0x00000005    Memory Mapped    
    RTI0_RTIWWDSIZECTRL    0x00000005    Memory Mapped    
    RTI0_RTIINTCLRENABLE    0x05050505    Memory Mapped    
    RTI0_RTICOMP0CLR    0x00000000    Memory Mapped    
    RTI0_RTICOMP1CLR    0x00000000    Memory Mapped    
    RTI0_RTICOMP2CLR    0x00000000    Memory Mapped    
    RTI0_RTICOMP3CLR    0x00000000    Memory Mapped    

  • Apologies for the delay in response,
    I am not currently aware of any masks with RTI that would cause the HwiP_irq_handler_c() function to stop being called. 
    For clarification: are you able to see if the HwiP_irq_handler_c() is stuck in an interrupt state? Or is it that the interrupts are cleared, and then it is never triggered again? It is possible an interrupt flag is set and never cleared, so no more interrupts are triggered.

    Optimizing applications with MCU SDK covers the interrupt handling in a bit more detail.

    Regards,

    Susan

  • The HwiP_irq_handler_c() is never called again for interrupt 84.  To the best of my knowledge and looking at the RTI registers as pasted, the interrupt was cleared but it never occurs again.  We do continue to see the 2 ADC interrupts we have configured.

    The RTI registers I pasted are from when the system is in this state: i.e. no systick (no interrupt 84).  To me they look correct to allow the timer to run and generate interrupts.  Could you verify?  What other specific registers and mask bits should I be looking at to see if indeed they are masked off some how? 

    I've read through the link you posted about optimizing applications, but all of this configuration and initialization is done with SysCfg is it not?  If we could determine what setting is keeping the interrupt from happening, them maybe we could figure out why it got into that state.

  • I apologize for the lack of response here,

    I will be looking into the interrupt controllers today as well as the RTI registers to make sure there isn't a mask I have missed, as well as reaching out to our software team to see if they know what might be causing the issue. 
    I will post any update I have by the end of today.

    Thank you for your patience,

    Susan

  • Hello,

    I looked again at your registers here, and according to the RTI0_RTIINTFLAG you have 4 interrupts pending. It doesn't look like you have auto-clear enabled, so are you clearing your interrupt flags as well as your interrupts in your ISR?

    You can also check the VIM (vectored interrupt manager) registers to check what interrupts are being triggered. The VIM registers are located within the R5SS section of the Register Addendum.

    Regards,

    Susan Moore