LPC-Link2 (LPC4370) Multi-Core Debugging Robustness

[SynBilly]

Hello NXP-Community,

currently, I am evaluating the LPCXpresso's robustness in multi-core debugging before starting an actual project based on a LPC43xx MCU.

I'm running into serious trouble when I try to start a debug session on the following projects with a LPC-Link2:

- LPCOpen Blinky Multicore Example (from lpcopen_2_12_lpcxpresso_nxp_lpclink2_4370.zip), running the M4 and M0 from SPIFI

- A new, plain multi-core project using the Project Creation Wizard (LPC43XX Multicore M0/M4), running the M4 from SPIFI, the M0 from RAM

Trouble means, that

a) starting the debug session on the M0 fails sometimes with various errors and sometimes leads to flash locks (see Flash driver operation failed - Program operation failed validation or readback compare )

b) trying to pause execution or restart the M0 via the debug toolbar leads to a freeze of the complete IDE

It seems that there are many pitfalls and that there is no way to get an example out of the box up and running. So my general question is: Is LPCXpresso v8.2.2 considered stable in terms of multi-core debugging?

Thanks,

-Thomas

PS: Please note that I do not want to blame anyone. I'm just trying to find out if LPCXpresso is the right development environment for multi-core debugging the LPX43xx.

[lpcxpresso_supp]

You might also find the Multicore section of the NXP FTF LPCXpresso workshop presentation useful: 

DES-N1973 Hands-On Workshop Master Development on the LPCXpresso Toolchain with Our LPCOpen Developm...

and the videos linked to from the LPCXpresso IDE product page at : http://www.nxp.com/lpcxpresso also contain some demonstrations of multicore debugging.

Regards,

LPCXpresso Support

[lpcxpresso_supp]

Yes, multicore debugging is pretty solid. We use it ourselves a lot for both development work and testing.

There is an issue recently identified which you might be hitting though, which is related to the automated selection of the M0 cores done in LPCXpresso IDE v8.2.x sometimes not working as expected. This is described in the following post :

• https://community.nxp.com/thread/435991#comment-837948 

The other issue you may encounter is related to the fact that the multicore examples currently shipping in LPCOpen are not configured as "real" multicore projects, from the LPCXpresso IDE viewpoint. Which makes them much more awkward to debug. There is an article here that explains how they can be debugged - How to run Multicore examples provided in LPCOpen LPC43xx packages? but generally we would recommend that you create new a set of new multicore projects using the LPC43xx new project wizard.

Finally, a small number of customers have reported some strange SPIFI flash lockups with. You might want to try swapping to using the flash driver provided in this thread ...

• https://community.nxp.com/thread/434100#comment-836273 

Regards,

LPCXpresso Support

[SynBilly]

Hello NXP Support,

thank you for your advices. I'm currently successfully debugging code on the slave M0 core(s), but there were many pitfalls in LPCXpresso v8.2.2 which I want to make you aware of.

Problem 1: Starting the debug session

There is an issue recently identified which you might be hitting though, which is related to the automated selection of the M0 cores done in LPCXpresso IDE v8.2.x sometimes not working as expected.

In my case, this seems a bit optimistic. The automatic core detection (as far as the M0 cores are concerned) does work every now and then. Most of the time, the debugger selects the wrong core and there is no possibility to choose the correct one manually. Having the "Disable Auto-select device on multicore target" selected as you adviced in LPC4370 Cannot reliably enumerate JTAG TAPs, starting the debug session with the M4 after choosing it from the core list results in an error:

probelist
[Started server]
[Connected on port 3025]
Index = 1
Manufacturer = NXP Semiconductors
Description = LPC-LINK2 CMSIS-DAP V5.173
Serial Number = IWFWCXOT
VID:PID = 1FC9:0090
Path = \\?\hid#vid_1fc9&pid_0090&mi_00#8&1e624100&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
probeopenbyindex 1
Probe Handle 1 Open
wirejtagconnect 1
corelist 1
TAP 0: 4BA00477 Core 0: M4   APID: 24770011
TAP 1: 0BA01477 Core 0: M0   APID: 04770021
TAP 2: 0BA01477 Core 0: M0   APID: 04770021

The only way to force LPCXpresso to start the debug session on the right cores is to have projects and debug configs for every core (even the unused) and start the debug session in the sequence M4 -> M0SUB -> M0APP.

When attaching to the M0 cores, we often get these messages:

However, debugging is still working after that.

Problem 2: Debug access to peripherals from a M0 debug session

Debugging the M0APP core it is not possible to use the "Peripherals+" view in order to access peripheral registers (at least for the ADCHS module). This results in the following error and a debug session crash:

Despite the problems listed, debugging is working quite stable now.

Thanks,

-Thomas

[SynBilly]

Hello!

Regarding my M0 debug connection problem, I've found out that the following advice from https://community.nxp.com/thread/390661 is not always true:

The device closest to TDI (device 2 here) is then the M0APP core.

With my LPCXpresso V8.2.2 I must select (at least sometimes) the device closest to TDO. Linker settings and startup-code seem to refer both to M0APP, so it shouldn't be the M0SUB which runs the code.

Regards,

-Thomas