All interrupts are not handled except systick and Svcall

MarvinLiu · ‎11-05-2021

hi all

I'm using IMXRT1176 now.

As the title said in the following case will cause all interrupts, except systick and SVCall, pending and not be executed by processer. I'm using more than ten interrupts such as CAN, DMA, SPI etc....

Interrupt Priority:

Systick : 0x40

All other interrupts have the same priority of 0x80.

Generally, everything goes well. But after a period of normal operation, maybe 1 hour or 12 hour, the bad thing coming out. Every interrupts which I'm using shows enabled and pending through the NVIC register. But none of them are executed now. There nothing happened, even after I add some break points at the beginning of the function which is reference by vector table.

I have catch the moment by Lauterbach, hoping you can find something useful.

ICSR is always in pending state and it always stuck by interrupt 16 ( DMA0 \ DMA 16)
Systick's priority is 0x40

All interrupts which I'm using are enabled.

you can see all interrupts are pending.

Active register always stuck in interrupt 25 or interrupt 27 which represent I2c2 and i2c4

all the priority are 0x80

Also, there nothing wrong with the CPU register. (Interrupt was not prevented by FAULTMASK \ BASEPRI \PRIMASK)

The CPU load is 100% now, I don't know what would cause interrupts to remain pending state, could you give me some advice about this question. It stuck me over a week.... anything you need just add a comment. I will provide as soon as I can.

BR

Marvin

jeremyzhou · ‎11-07-2021

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
According to your statement, whether the code will be stuck in the interrupt handler function of interrupt 25 or interrupt 27 after running several hours. If yes, I think you'd better check the reason of the interrupt handler can't jump out
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

MarvinLiu · ‎11-07-2021

Hi, @jeremyzhou

Thanks for your response. Very glad to hear any ideas about this issue.

Unfortunately, the code is not stuck in the interrupt function. Os's periodical main function will be executed, but the period is not corrected.

BTW, all the interrupts are category 2. I have tried set it to category 1, but still get the same result.

When this issue coming out, I have one way to let everything go back to normal temporarily by boosting the priority of interrupt 27. But after a long enough time(normally greater than 12 hours) this problem will come up again....

I think maybe the interrupt 27 not handled is a result but not the reason that cause other interrupts not working normally.

jeremyzhou · ‎11-09-2021

Hi,
Thanks for your reply.
I basically agree with your guess, maybe you can try to increase the priority of interrupt 27, meanwhile, eliminating any dependencies that affect the response to interrupt 27.
BTW, I'm confused with interrupt 27, does the 27 mean the Interrupt number? If yes, 27 stands for the LPUART8 TX interrupt and RX interrupt actually.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

MarvinLiu · ‎11-09-2021

HI,

I have tried to increase the priority of interrupt 27 and 25, but the result is only extend the time of issue happened.

Yep, you are right. 27 stands for the LPUART8 TX interrupt and RX interrupt.

Now we are using LPI2C_MasterTransferNonBlocking to send the i2c frame. The more frequently I send the i2c frame, the faster the issue will happened. We can using LPI2C_MasterTransferBlocking to avoid this issue, but this issue will cause a very dangerous situation that is unacceptable in any case. So yes there are lots of ways to realize this feature without issue, however once the problem is exposed we need to know the root reason about this.

Thanks for your replay!

jeremyzhou · ‎11-10-2021

Hi，
Thanks for your reply.
Do you use the RTOS in your project? Further, I'd like to suggest you can create a much simpler demo project that can replicate the phenomenon, it can help you to figure it out.
Lastly, I think you'd better some time comparing the LPI2C_MasterTransferNonBlocking and LPI2C_MasterTransferBlocking.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------