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.

TM4C1294NCPDT: GPIO edge interrupt not cleared

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: AFE4404

Hi !

I am porting working code of tiva tm4c123gh6pm launchpad to tiva tm4c1294xl launchpad.

I was using polling for i2c interface with afe4404 but as per tm4c1294 errata,i have changed i2c polling code to interrupt based.

adc rdy signal from afe4404 is used as gpio interrupt(pin P2) to uc.when checking this code on debugger, p2 gpiointerrupt is not getting cleared by GPIOIntClear.The pin isr & initialization is in attached file.

Let me know what is causing it.i2c.docx

Thanks & regards,

Neelima

  • What is your clock speed on the AFE4404? Do you get multiple interrupts (such as might be caused by ringing on the ADC_RDY signal), or continuous interrupts?

    Where are you setting the breakpoint in the debugger to check the interrupt status? Because there is a write buffer in the Cortex-M processor, it may take several clock cycles before the interrupt source is actually cleared.
  • Hi!
    Afe4404 internal clk is 4Mhz & PRF is set 500HZ with 5% dutycycle.
    I do not understand ur question about multiple & continuous interrupt.Pl.elaborate.I am not having oscilloscope to check pin.
    As per my observation,when debug cursur enters in isr,GPIO_RIS & MIS registers r showing 0x00000004.
    after execution of intclear command,NVIC_PEND2 & NVIC_UNPEND2 show 0x00004000 along with MIS & RIS = 0x00000004.
    after remaining isr code execution it goes again at start of isr & NVIC_PEND2 & NVIC_UNPEND2 become 0x00000000 while MIS & RIS remain always = 0x00000004.
    Where are you setting the breakpoint in the debugger to check the interrupt status?
    --------I am checking at ui32Status = GPIOIntStatus(GPIO_PORTP_BASE, true); line & then single stepping to check if MIS & RIS get cleared.
    Because there is a write buffer in the Cortex-M processor, it may take several clock cycles before the interrupt source is actually cleared.
    ----The code is working code with tm4c123 which is also Cortex-M processor.

    Thanks & Regards,
    Neelima
  • I suspect that the issue is that with conversions 500 times a second, the next edge from ADC_RDY has come in while single stepping and as a result you do not see the interrupt source as cleared.