Active interrupts after MCUXpresso restart?

cancel
Showing results for 
Search instead for 
Did you mean: 

Active interrupts after MCUXpresso restart?

539 Views
edarrington
Contributor II

We are currently using MCUXpresso 11.0.1 to develop a project using LPC4330 processors (M4 with M0APP).  Our application uses interrupts to manage a few time-dependent processes.  If we set a breakpoint inside one of these interrupt processes, that interrupt is obviously active.  Here's the problem.  If, while at a breakpoint, we simply use the IDE restart button to restart, the active interrupt REMAINS ACTIVE through the restart per the system control block (SCB) ICSR register.  Because the SCB shows an interrupt active, any new interrupts being initialized--that have the same or lower priority--cannot run.  Ever.  The processor appears to continually wait for the active interrupt--which occurred prior to the restart--to complete.  But the interrupt cannot complete because the debugger has restarted the application and the code has been restarted.

I don't recall having this issue with LPCXpresso version 8, but it is consistent and repeatable in MCUXpresso version 11.0.1.

Did something change in MCUXpresso?  Is a processor reset no longer done during a debug restart?

Related:  I have looked for a way to reset the SCB->ICSR (read only) register to convince the processor that no interrupts are running, but cannot find a programatic method (obviously a full software-load restart will work, but then whats the point of the debug restart?).  If I can just clear the SCB-ICSR register, I believe this problem goes away.

Is there another solution that can get past this restart issue?

Thank you for recommendations or help!

0 Kudos
5 Replies

406 Views
lpcxpresso_supp
NXP Employee
NXP Employee

The various variants (and versions) of the LPC43xx can behaviour somewhat differently regarding reset whilst under debug control, which means that the IDE by default will try to avoid doing a real reset in some circumstances, in order to try to ensure that debug works in most circumstances on all parts. However this can sometimes causes issues/

Please try double clicking on the .launch file in your project to edit the debug launch configuration, then removing the reference to the "LPC18LPC43ExternalFLASHBootResetscript.scp" in Reset script entry (i.e. set the field to be blank).

pastedImage_1.png

Does this improve the behaviour that you see?

Regards,

MCUXpresso IDE Support

0 Kudos

406 Views
edarrington
Contributor II

Thank you for the response, and sorry for my delay in responding (traveling).  This morning I tried your suggestion, but it did not improve the behavior.  In fact, it made the situation worse, as I could not connect the debugger at all.  Looking more closely at the contents of the reset script, I can see why.  The debugger is apparently expecting the SP, PC, VTOR, and XPSR values to be passed back from the script.  Removing that script results in the debugger being lost and unable to find breakpoints.  Replacing the script got me back to where we were before.

I did try to un-comment cmvectresetreq, but trying that both before and after the print statements caused the debugger to fail as well.  So, no joy yet.

Is there a soft reset command or something similar I can add to the reset script that would provide the actual reset?

Thank you, again.

0 Kudos

406 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hi Ed Arrington,

Could you try using the most recent MCUXpresso version (11.1.0) and check if this also happen? Here's the link for the download.

Best Regards,

Alexis Andalon

0 Kudos

406 Views
edarrington
Contributor II

Alexis,

Thank you again for the suggestion.  I often hesitate when someone recommends "making sure you have the latest version" as that rarely fixes the problem.  Still, I made the effort and was able to get upgraded to 11.1.0.  Unfortunately, I tested the problem with identical results.  In other words, upgrading to 11.1.0 did not fix the problem.  Lower priority interrupts are never able to be called because, when a restart is done in the middle of an active interrupt, that interrupt is never resolved.  The interrupt remains active until we do a complete reload of the firmware.

Is no one else seeing this problem?

Any additional ideas?

Thanks again for any help you can provide.

EdA

0 Kudos

406 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello Ed,

In the LPCOpen examples (link here), at the startup code it's a routine that disables the interrupts, clear the pending interrupts and enable it again in the reset interrupt.

Maybe you could try to add something like that.

I hope this helps you.

Best Regards,

Alexis Andalon

0 Kudos