MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog

dmarks_ls · ‎09-17-2019

I'm currently having a situation with my RT1050 where I'm trying to breakpoint inside a particular FreeRTOS task, but when the breakpoint is reached, the debugger fails to suspend itself and instead throws up a dialog stating "Interrupt failed" when I try to manually suspend the debugger afterward.

So my application boots normally. If I manually pause the program, I get a valid debugger context:

This happens to be the task I want to step into, so I've got a breakpoint set at the switch() statement just after the message queue receive call returns. I also have a second breakpoint set inside the method NetIfInit() just below there; I would expect the debugger to hit both of those, or at least one.

I've also set a breakpoint inside my test function that will initiate the message queue send. When I press my keys on the serial console, the debugger hits that breakpoint and halts.

Then I step into that NetInit() function, which eventually calls xQueueSend(), which after a pregnant pause the debugger steps into. I then step through the body of xQueueGenericSend() until I get to this point right here:

Once I try stepping over line 846, the debugger pauses for some time, then loses context. Note that I've lost my Resume All / Suspend All / Terminate All buttons, and also my thread list at the left. The only available buttons are Suspend and Terminate for this session. If I click Suspend (pause), the IDE sits for a few seconds, then throws up this dialog:

And that's it, game over for the debugger. Meanwhile, my serial console is stalled with some half-written UART output. One might think that oh crap, I've gone and blown my stack or something, target must be dead... nope. The only button remaining is the red Terminate (stop) button, and if I click that, the debug session terminates, and execution resumes... my tasks are good and alive.

Initialize eth0.

#DA4 12.996 | eth: netif init
#DA4 12.999 | eth: NV MAC = 00-07-F0-00-56-03
#DA4 12.999 | eth: NV cfg: address = 192.168.1.180, netmask = 255.255.252.0, gateway = 192.168.1.1, static
#DA4 13.000 | eth: netif add: MAC 00-07-F0-00-56-03, PHY address 3
Returning to main menu.

#BB4 17.572 | No Handle Base Curr HiWByte State Name
#BB4 17.575 | 10 80010db8 19 19 824 Blocked Tmr Svc
#BB4 17.575 | 05 20206b68 12 12 1396 Suspended led_act
#BB4 17.576 | 04 20206500 12 12 1388 Blocked led_cpu
#BB4 17.576 | 08 2020ba18 8 8 7216 Blocked tcpip_thread
#BB4 17.576 | 07 20209868 7 7 6900 Blocked eth_mgr
#BB4 17.577 | 06 20207818 4 4 1912 Blocked gui
#BB4 17.577 | 01 20203538 3 3 2812 Suspended debug_mgr
#BB4 17.577 | 02 20204a68 2 2 4248 Running test
#BB4 17.577 | 03 20205e88 1 1 3948 Blocked backgrnd
#BB4 17.579 | 09 80010d40 0 0 748 Ready IDLE‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

So it seems that execution did in fact stop at the breakpoint I set, it's just that the debugger crapped itself.

Any idea why the debugger would lose its mind like this?

(EDIT: Added console output attachement, if that's useful at all.)

David Rodgers

davidcw · ‎10-01-2021

I would also like to know if this question was ever resolved. I'm having the exact same issue - in the sense that I am using MCUXpresso (v11.4), and my FreeRTOS application can fine for hours. I can manually pause the debugger and step through the code. However, my program will eventually crash, and the debugger (through a Segger JLink) just reports "interrupt failed" - I lose all debugging functionality.

BlackNight · ‎09-17-2019

Hi David,

I had this occasionally too, but never was able to really have a reproducible case, and I guess you won't be able to share your project (otherwise: please do).

What I noticed or thing is that it might be an issue in the SEGGER FreeRTOS awareness implementation: I noticed that it does a lot of data reading, causing many view refreshs. There is a ticket pending with SEGGER on that subject.

What for sure helped was to disable the SEGGER FreeRTOS awareness in the debugger (but I admit that this makes debugging FreeRTOS applications less user friendly).

The other thing I did was closing as many views as possible (especially the disassembly view) to reduce traffic.

I know that this is not ideal, and if you could share anything else for the IDE engineering team, that would be great.

One thing which might be helpful are the GDB traces, see Board Bring-Up Tips, GDB Logs and Traces in Eclipse | MCU on Eclipse

I hope this helps,

Erich

dmarks_ls · ‎09-18-2019

I've got a lot of other items on my plate at the moment, but I will try to get some additional information to you in the next few days. You're correct, I'm definitely not going to be posting my project here in the forums, but if you have a back channel where I can send my project directly to either you or an NXP engineer, I would be OK with that. But yes, in the project's present form, it's 100% reproducible. So if it's possible to send you my project privately, then I'll see about making an altered version that runs on an EVKB and still exhibits the issue.

David R.

ErichStyger · ‎09-18-2019

Hi David,

You could use the normal support ticket way to submit your project. I think it will only help the IDE engineers if it would run on a EVK as they have that hardware available, and the smaller the project, the better.

Thanks for your help!

Erich

DavidClus · ‎02-08-2021

Hi all,

we are currently having the same problems.

We'd like to debug into an issue, but the J-Link debugger states "Interrupt failed", after hitting the breakpoint.

As this thread stops with the hint to the support system, Is there already a solution?

Kind Regards

David

dmarks_ls · ‎09-24-2019

Hi Erich,

Wait... you still have a ticket system? I thought NXP shut that avenue of support down years ago when they told everyone to go to the forums instead. (At the time I was not terribly thrilled, as I took it to be a reduction in customer service, i.e. "don't come to us, go ask the general public for help". However, NXP's engineers do seem well-engaged with the forums, and having third-party input is usually helpful.)

Do you have a quick link for where to submit support tickets? If I manage to break off some time this week (ha), I'll see if I can put together a version of my project that at least behaves correctly on an EVKB and still exhibits the breakpoint failure. Thanks.

David R.