• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1157 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.

TMS320F28069: Recommended procedure for enabling ADC interrupts?

James McLaughlin
Expert 1090 points

Part Number: TMS320F28069

Our application has 8 or so different ISR routines that run at any given time (many HR/ECAP-edge-based, others ADC based, others timer based).  During run-time, I have a need to rapidly turn some on or off.  It is acceptable to "miss" an interrupt due to it just be cleared rather than serviced, or wait until I re-enable to service it.  We know our CPU is very consumed with interrupt processing under certain conditions, so we want to shut down less necessary ISRs to prevent lock-up.

For the HR/ECAP-based ones, I can do this without issue.  I follow the procedure listed in section 1.7.3.1 of the TRM.

For the ADC-based ones (INT1 and INT2 both point to the same ISR), I run into issues with the processor occasionally locking up.

Is there a similar required disable procedure for the ADC interrupts, or any other possible ways to handle this cleanly?  I still see the issue when I use the procedure from 1.7.3.1 on PIE 1.2.  I'm assuming it's a bad ISR vector that's causing this due to some issue with the flow of the interrupt signal.

Thanks!

  • 0
    TI__Guru 54765 points
    The same procedure should apply to all of the PIE interrupts. Could you describe the lock ups you're seeing in a bit more detail? Are you getting an illegal instruction error or something else?

    Also, are you doing any software-based interrupt nesting/prioritization?

    Whitney
  • 0
    TI__Guru 62975 points
    James,

    If the ADC interrupts are not serviced, the ADCINTOVF flag will be set. In my experience, the ADCINT signals may fail to trigger subsequent PIE interrupts if the ADCINTOVF and ADCINTFLG bits are not cleared. You can avoid the flag servicing requirement by enabling the continuous interrupt mode.

    -Tommy
  • 0 in reply to Whitney Dewey
    Expert 1090 points

    Ok, that makes sense.  Wanted to make sure there wasn't a specific separate procedure just for the ADC interrupts.

    I'm not entirely sure what the lockup is. While in debug mode, some of my watch variables will just flash 0xBAD temporarily.  Rude Retry just gets it into some area of memory that has no code available (so I'm assuming just bad vector or something with the interrupt firing but it being disabled before it jumps?).

    In the past this behavior has been related to our processor being overloaded and the I2C interrupt just not being serviced fast enough (so our other controller sees a "communication error" and resets everything).  It may have actually locked up or just taken too long.  I'll disable the reset from the other controller and see if I get a different debug behavior.

    We are using software-based interrupt prioritization, but the two allowed to interrupt the ADC ISR aren't currently running.

  • 0 in reply to tlee
    Expert 1090 points
    Thanks, Tommy! I'll have a look at that, too