LPC4357 - Dual Core Debugging Broken

[Eli_H]

I have a project that has been working in LPCxpresso V8.2.  After bringing it into MCUXpresso I noticed odd behavior with dual core debugging in the LPC4357.

Step 1:   Start Debugging the M4.    The debugger will download and run to main.  I will leave it paused

Step 2:  Start Debugging the M0 as "attach only".

Step 3:  Press Go for the M4.     The M0 session will how be stopped at main

Step 4:  I place a breakpoint at a known place I know the M0 code will reach and press Go.

The M4 will stop after Step 4.   Both Cores are running FreeRTOS.   It uses pauses in the Idle Task.

[lpcxpresso_supp]

I can reproduce the Red Link interface error 255, but only during the M0 debug session connect, and only if the M4 is executing. The debugger is polling the M4 processor for debug halt, and I suspect the error is caused by insufficient USB bandwidth allocated to the debug probe. If you're not using SWO trace or the VCOM, you can experiment with the non-bridge debug probe which provides more bandwidth to the debug endpoint.. Find this setting in Preferences -> MCUXpresso IDE -> LinkServer Options -> LPC-Link 2 boot type. Set the type to CMSIS-DAP (Non-bridged - Debug only).

With regard to the pause of M0 debug, I cannot reproduce this. Please copy and paste the M0 connection gdb-traces console and debug logs and post here.

Thanks and regards,

LPCXpresso Support

[Eli_H]

Hello:

I deleted my debug configurations, unchecked "Enable Non-Stop Mode" and recreated my configurations.

I first tested without any of the task aware debugging enabled.    I noticed that I still get the "Red Link Error 255" messages when attaching and the "Target Rejected debug access at location 0xE000EDF0" when I "unpause" a session.

I with this new debug setting,  I can never "unpause" the M0 after I pause.   I get the "Target Rejected debug access at location 0xE000EDF0" and it appears the session has crashed.    The green play button is greyed out.

What exactly does "Enable Non-Stop Mode" do?

[lpcxpresso_supp]

With regard to FreeRTOS task aware debug, you'll need to ensure the debugger is using All-Stop mode.

1. Delete your FreeRTOS project(s) launch configurations.

2. Uncheck "Enable Non-stop Mode". This is found from the File menu:

Window -> Preferences -> MCUXpresso IDE -> Debug Options (Miscellaneous) -> Enable Non-Stop Mode (checkbox).

3. Recreate your project(s) launch configurations.

4. Connect debug session first to the M4, and attach debug to the M0.

Thanks and regards,

LPCXpresso Support

[lpcxpresso_supp]

I've been unable to reproduce this behavior using a standard LPCOpen multicore project. I'd first caution you to import your project into a new workspace if you haven't already done so. MCUXpresso should also warn about incompatible launch configurations, so this should have been taken care of when you changed over. If you'd like to post your debug logs, and gdb-traces logs, I'll have a look.

The Debug Log

Thanks and regards,

LPCXpresso Support

[Eli_H]

Ok, sorry for the delay but I am back on this. We went through refreshing the debug configurations (I used CodeRed from day 1 so I am well aware of the process).

I think I have some clues.

1.)   As a control,  played with the multicore_mc_sa_blinky examples in the LPCXpresso4337.   I used a LPC4337Xpresso board as my known working control hardware.

My debug sessions always start by

a.)  Downloading the M4 project

b.)  Start the M4 

c.)  Start the M0 debug session (attach only)

I notice that I always get the the redlink error 255 when I pause/unpause the M0 project.

With this project,   dual core debugging seems to be somewhat stable except for the Redlink 255 errors.

2.)   The problem project uses FreeRTOS running on each core independently.

Things seemed to go south very quickly when trying to use the task aware debugging in anyway.   I followed the instructions from "MCUXpresso IDE FreeRTOS Debug Guide".

a.)   When the macros configINCLUDE_FREERTOS_TASK_C_ADDITIONS_H and bare enable in the RTOS of both cores,  debugging on the M0 is completely unusable.    I cannot pause, etc on the m0 core with the debugger crashing.  Once in awhile it will work but it pauses the M4 core.

I do notice a couple things in this case.  on the M4 side when I start, here is the GBD log:

GNU gdb (GNU Tools for ARM Embedded Processors) 7.12.0.20161204-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

Program stopped.
0x00000000 in ?? ()
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at ../src/main.c:6
6 fpuInit(); //Start the Floating point unit
[New Thread 4]
[New Thread 5]
[New Thread 3]
[New Thread 2]

When I attached to the m0 core

GNU gdb (GNU Tools for ARM Embedded Processors) 7.12.0.20161204-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

Program stopped.
0x00000000 in ?? ()
[New Thread 5]
[New Thread 8]
[New Thread 4]
[New Thread 9]
[New Thread 10]
[New Thread 2]
[New Thread 6]
[New Thread 7]

I can never really pause the M0 core so I can't see if it recognizes the different threads.  On the m4 side,  I can see the different thread names in the debugger window.   When I pause,  nothing really happens except that the play button is grayed out and I lose debugger control.

b.)   If I completely disable the trace facility on both the M4 and M0 core,  things are a bit better.   I can pause the M0 core but I get this message when I try to unpause.

0: Could not start execution from stop

Target Rejected debug access at location 0xE000EDF0

If I click OK and try hitting the "play button",   it will ride through this array and start again.   This behavior seems to happen every time I pause.

That is a strange address that doesn't map to anything

Also. I do get a "Redlink 255" error when I attach but it seems that I can ride through that error.

3.)  Having trace enabled in just the M0 or M4 yields the same results as #1.

So... It seems I can make the problem better or worse when trying to use the new task aware debug.

Also,   it seems the the 1 breakpoint limitation on the M0 makes debugging really difficult.   An accidental placement of a 2nd breakpoint will return an error that there are no more resources and the debugger connection will be lost.

4.)  On the M0 side, clicking a line to enable/disable breakpoint can cause a crash.

 I get a message that "arm-none-eabi-gdb.exe" has stopped working.    This happens when my project is configure without task aware debugging so I have some basic control over the core.

[Eli_H]

I will try to also make a little screen capture video showing the problem.  It may be part of the process I use to debug. Most of the application is on the M0 side.  It is difficult to debug this deviceas it only has one breakpoint on the M0 and I get "Redlink Error 255" consistently if I am not diligent in how on click on things to start a break point, pause execution, etc.   This problem may be related.

I'll do my best to get you an example to look at.