Problem in LPC18LPC43InternalFLASHBootResetscript.scp

[udoeb]

I found that the debugger does not work as expected with LPC4333 and LPC-Link2. The CPU does not get reset when I start a debug session. This turned out to be a problem in the debugger script LPC18LPC43InternalFLASHBootResetscript.scp. The script contains these two statements which are inactive, though.

160 REM cmresetvectorcatchset this
170 REM cmvectresetreq this

If I remove the REM from both lines then the debugger works as it did before with LPCxpresso.

Can someone confirm this to be an issue in MCUXpresso?

Version info: MCUXpresso IDE v10.0.0 [Build 344] [2017-03-21] 

Thanks

Udo

[lpcxpresso_supp]

It's not necessary to provide example code at this time. Let me explain. Before using the flash driver, the debugger masks, then clears active and pending interrupts before issuing a core reset. Once the flash operation is complete, interrupts should still be masked. We have seen behavior which is sort of reverse to yours. That is, under debug some parts seem to come out of core reset with interrupts enabled. You may see startup code with an explicit interrupt disable as the first instruction. If your claim is the MCU state is dependent upon the firmware running when the debug session starts, you're partially correct. However, in the case where the core reset is bypassed, the last code to actually execute on the part is the RAM resident flash driver.

The continued use of the MCUXpresso connect script for LPC43xx parts with internal flash is probably the result of an internal miscommunication. The 'Reset Handling' setting provided to you earlier is the preferred method. We'll look into this further for a future update.

Thanks and regards,

LPCXpresso Support

[udoeb]

Thanks for your explanation. I don't want to stress this too much but would like to add one final comment:

Our specific problem is not related to interrupt enable/disable state. It's related to the state of the Cortex M4 CONTROL register. Our RTOS configures an alternate stack and then sets bit 1 in this register. If you execute another firmware image while CONTROL is still in this state, the images crashes when the first ISR is executed. But this is only one out of many possible problems than can occur if the CPU is not in a well-defined state when an image is launched.

As I understand your explanation above the overall sequence is:

(1) Application firmware runs and can modify CPU state in any way.

(2) Debug session is started. CPU is in an arbitrary state at this point.

(3) FLASH driver runs. New application image is flashed.

(4) New application image is launched.

To avoid side effects as the one described above, at the transitions (2)->(3) and (3)->(4) there should be a CPU reset.

In our specific case, if there is no reset at (2)->(3) and if the FLASH driver would use interrupts then the FLASH driver would crash. Bad experience too, and much more difficult to debug...

Thanks and regards,

Udo

[lpcxpresso_supp]

Is it worth stating that we would generally expect the launch configurations (and xref'ed scripts) to work as supplied without needing these modifications - certainly we see no issue in our testing here.  Thus presumably you are doing something “interesting” in your setup?  Can you perhaps provide more details?

Regards

MCUXpresso IDE Support

[udoeb]

Generally without a reset, the CPU (and NVIC etc.) is in an arbitrary state when debugging starts. This state depends on the firmware application that is currently running when the debug session starts. In my specific case this firmware is RTOS based. The RTOS modifies the CPU's CONTROL register to switch to an alternate stack. When I start debugging in this state, my startup code runs fine until the first interrupt gets enabled. The respective ISR causes an exception when it returns because of the wrong CONTROL[1] state. Note that this is only one potential problem that might occur if the CPU state is undefined when the startup code runs.

Debugging with this specific RTOS based firmware application worked fine with LPCXpresso (and the auto-generated launch config) but does not work with MCUXpresso (with the auto-generated launch config).

Possibly there are RTOS based firmware samples available which show this issue as well. I will try to find one.

Udo

[lpcxpresso_supp]

Removing those commented lines in the reset script is one way to force a reset. The historical reason the server reset command is commented out in the script is related to the behavior of the LPC4350 boot loader after reset. The early LPC4350 parts exhibited a rather lengthy boot delay was not tolerable in a debug environment. So, both the reset and boot loader initialization were bypassed. Note that removing the comment lines allows your part to be reset, but the boot loader code still gets bypassed. In your case, you should be able to remove the reset script from your launch configuration (i.e. Reset Script configuration entry), and add VECTRESET type to the Reset Handling configuration entry and accomplish the same thing. Use of the SYSRESETREQ signal is not compatible with the LPC43xx parts.

Thanks and regards,

LPCXpresso Support

[udoeb]

Thanks for your reply. I confirm that the launch configuration works after I removed the script and set the reset type to VECTRESET.

However, there are still some unanswered questions:

The script name LPC18LPC43InternalFLASHBootResetscript.scp implies that this is for parts with internal FLASH. So LPC4350 should not be affected.

For LPC4333 MCUXpresso automatically creates a launch configuration which references LPC18LPC43InternalFLASHBootResetscript.scp. Debugging with this launch configuration does not work until I modify the script, or alternatively modify the configuration as you suggested above. Shouldn't the automatically generated configuration work without manual modification?

LPCXpresso v8.2.2 automatically generates a launch configuration whch includes LPC18LPC43InternalFLASHBootResetscript.scp with both reset commands active and this configuration just works without any further modification. I just switched from LPCXpresso to MCUXpresso and found that debugging does not work any longer -- bad experience.

Udo

[udoeb]

Possibly my problem description was not clear enough: Debugging from the IDE does not work with LPC4333. When I start the debugging session then the CPU crashes randomly (exception etc.). Enabling the reset commands in LPC18LPC43InternalFLASHBootResetscript.scp fixes this.

Can someone from MCUXpresso support team confirm that this is the correct way to fix this?

Thanks

Udo