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.

TM4C1231H6PGE: Reboot being occurred in the ISR routine

Part Number: TM4C1231H6PGE

Hi ,

Implemented an ISR routine and have set the priority HIGH (0x00).

Wanted to know.. is there any specific time limitation or constraint for the ISR to be completed ?

If so ,what happens if the ISR takes longer time ?

I have a piece of code implemented in ISR to drive a GPIO and Access the I2C for configuring another Slave Device.

Driving the GPIO is Proper ,but the I2C related transactions are not happening and unit is going for a reboot.

Can you please help out in what could be the possible reasons for the reboot and is there any way that this reboot can be averted.

Thanks ,

Rohith.

  • is there any specific time limitation or constraint for the ISR to be completed ?

    The technical answer is no, but in reality interrupt routines should be very short because they typically block the CPU from servicing other interrupts. (This device does support nested interrupts, but that is a more advanced topic.) You mentioned the code is doing a reboot. Do you mean it is executing a reset? The reset sources are listed in the datasheet. From your description it sounds like the code enabled a watchdog and your long interrupt routine kept the CPU from feeding the watchdog. The proper solution is to keep the interrupt routines short. Waiting for an I2C transmission to complete in an interrupt routine is a bad idea. Depending on what you are doing in the interrupt routine you can either set a flag in the interrupt routine and then check that flag in your main loop. You then do all of the time consuming work in the main loop. Or, if the situation is that you are sending or receiving multiple bytes on I2C, then use the I2C interrupt routine with a static variable to keep track of the state.