LPC4357 LPCXpresso Multicore M0 Issue

[lpcware]

Content originally posted in LPCWare by GTA on Tue Aug 06 18:08:07 MST 2013
Hello All,

I am using an Embedded Artists LPC4357 dev kit and have started to work with getting both the M4 and M0 cores up and running. I have started with the most basic approach of using the LPCXpresso project creation wizards to create LPC4357 multicore projects, following the Code Red Wiki "LPC43xx Cortex-M4 / M0 Multicore Applications".

The M4 seems to work fine; I can debug the default sample program and everything is in order. There are however some problems with the M0 core. When debugging the M0 I get a message "No source available for "0x0", and the static variable in the sample main() is not initialized to zero as it should. Any breakpoint set is also not stopped at, until you set one after the debug session has started. See the attached images for how it looks.

I have tried both LPCXpresso 5.2.4 and 5.2.6 with the option to to locate the M0 image in Flash Bank B, and with 5.2.6 to locate the M0 image in 2nd RAM bank. The result was the same in all cases.

I have attached a .zip with the projects exported from 5.2.6, including all memory maps, link files, launch configs etc. plus the .png images from above.

I look forward to having some information on what the problem is and how to get the M0 to work as it should.

Many thanks,

Original Attachment has been moved to: LPCXpresso_5_2_6_LPC_4357_Multicore_M0_Dbg_Issue1.zip

[lpcware]

Content originally posted in LPCWare by GTA on Thu Aug 08 08:45:22 MST 2013

---

Quote: lpcxpresso-support

No, you can't access the DHCSR on the M0. And even if you could, the problem is that the debugger probably wouldn't actually be connected to the M0 at the time you would want to sample the register anyway,

---

Right, thinking about it now, with the debug procedure you have to use what I suggested will not work even if DHCSR was accessible. I got a bit carried away there... :S

---

Quote: lpcxpresso-support

I suppose one thing you could do would be to use a memory location shared between the M4 and M0, such that the M0 would poll on that location being a certain value before continuing - and the M4 code could actually write to that. You would then need to control when this happened from your M4 debug connection.

---

Would it be possible to from the M4 debug connection script write to that M0 memory location, using something like this gdb syntax: set {int}0x10000000 = 4

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Aug 08 06:28:54 MST 2013
[h3]@ wlamers[/h3]

More information on the multicore debug support will be announced in due course. In the meantime, I suggest you read:

http://support.code-red-tech.com/CodeRedWiki/RedSuiteFuture

[h3]@ GTA[/h3]
No, you can't access the DHCSR on the M0. And even if you could, the problem is that the debugger probably wouldn't actually be connected to the M0 at the time you would want to sample the register anyway,

I suppose one thing you could do would be to use a memory location shared between the M4 and M0, such that the M0 would poll on that location being a certain value before continuing - and the M4 code could actually write to that. You would then need to control when this happened from your M4 debug connection.

We are pondering ways that we might improve matters here longer term from the tools side - but unfortunately there are limitations imposed by the design of the actual chip here.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by GTA on Thu Aug 08 02:29:52 MST 2013
Hello again,

and thanks for the YouTube-link!

Until we have that LPC-Link2 behaviour it would be nice to have a programmatic way to detect whether the M0 core is under debug control and when so enter the debugger attach loop suggested above.

I found this for the Cortex-M3, http://www.keil.com/support/docs/3510.htm, stating there is a register bit one can check to see if the M3 is under debugger control. Looking through the ARM ref docs for the M0, the register is there too: "DHCSRDebug Halting Control and Status Register"

The register is not mentioned in the LPC43xx user manual but its address should be 0xE000EDF0, which according to the LPC43xx UM is in the "ARM private bus" range. IN 3.5 the UM also states "Each processor uses its own ARM private bus memory map for the
NVIC and other system functions.", and I assume the M0 and M4 have their own copy of this register(?).

Looking through the LPCOpen CMSIS core_cmX.h header files the DHCSR is there for the M3 and M4, but not for the M0. I then found this thread on the topic, http://knowledgebase.nxp.com/showthread.php?t=1921&langid=2 so it seems not to be doable, but maybe with a "workaround"?

BR,

[lpcware]

Content originally posted in LPCWare by wlamers on Wed Aug 07 07:24:05 MST 2013
The dual-core debugging support in LPCXpresso would be a very welcome update. Is this going to be supported for the Red Probe+ debug probe also, or only for the LPC-Link 2? Can we expect this update from Code Red or the "new" tool of NXP?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Aug 07 06:25:49 MST 2013
Terminating a debug connection does not (by default at least) halt the CPU:

http://support.code-red-tech.com/CodeRedWiki/DebugDisconnect

When you start a debug connection to the M0 on the LPC4357, you are actually connecting to the running target, using "attach" functionality, as per the FAQ:

http://support.code-red-tech.com/CodeRedWiki/DebugRunningSystem

The IDE will automatically use the attach functionality for the M0 debug session. You do not need to modify the launch configuration.  You need to do this because the M4 is system master, not the M0.

FYI - part of the complexity here is due to the current IDE and probe technologies only supporting connection to one of the two cores on the LPC4357 at once. There are some changes coming here though. For a preview see the video at:

http://www.youtube.com/watch?v=THqkAcZvMXI

[skip through to time 26:28 of the video for the LPC43 part]

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by GTA on Wed Aug 07 01:47:49 MST 2013
Hello lpcxpresso-support,

and thanks for your prompt and thorough answer, very helpful!

---

Quote: lpcxpresso-support
...When you debug the M0, you have to have set the M4 off running first, and then do an attach only connection to the M0...

---

I actually thought about this a bit when I read the "LPC43xx Cortex-M4 / M0 Multicore Applications" page on the CodeRed Wiki. In its debug section it is stated:

"...Having connected to the M4, close down the debug session. Now launch a debug session for the **M0** project..."

I interpreted this as M4 debug session terminate, but it should be debug session disconnect instead? I don't have my projects at hand now, but as it actually works to connect to the M0 even if I terminate the M4 debug session first, it seems the M4 continues to run after debug session termination, or that the debugger actually can connect to the M0 even if the M4 is not running. (I use all default launch config debug settings).

BR,

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Aug 07 00:59:26 MST 2013
There was an issue with LPCXpresso 5.2.4 over the initialisation of the M0's .data section, but this was fixed in 5.2.6 (though you should make sure that you do a full clean build after updating). However this did not affect .bss variables.

I think that the issue you have here is a misunderstanding of how the M4 and M0 in the LPC43xx are actually implemented. The M0 really very much is a slave, controlled by the M4. When you debug the M0, you have to have set the M4 off running first, and then do an attach only connection to the M0. This means that you won't hit a breakpoint on main, and nor will you hit any other breakpoints. You have to pause execution before you can do this. Until you do this, the M0 will be running its code. This is probably why you never see your variable having a value of 0. And it is why you see the "No source available for "0x0" message when you start the debug session, as until you pause, the debugger doesn't actually know where the PC is.

The simplest way to prevent the M0 "running away" like this is probably to add a "pause loop" at the start of main whilst you are debugging such that the real body of your application is not executed until you have terminated this loop from within the debugger. For example, you might have:

unsigned int pause_at_main = 42;

int main(void) {
  int z = 0;
  while (pause_at_main > 0) {
    z++;
  }

::: rest of main :::

Then when you pause execution you will be in the "while (pause_at_main > 0)" loop, and you can simply set the variable "pause_at_main" to 0 (via the Expression view) to exit the loop and begin execution of your main body of code.

Regards,
LPCXpresso Support