LPC5528 cannot halt processor

[fruitmans]

I am working on a project that uses the LPC5528 processor. When starting a debug session i encounter the following issue. 

Console output:

MCUXpresso IDE RedlinkMulti Driver v11.1 (Feb 24 2020 13:54:38 - crt_emu_cm_redlink build 11)
Found part description in XML file LPC5528_internal.xml
Reconnected to existing LinkServer process.
Using memory from core 0 after searching for a good core
debug interface type = Cortex-M33 (DAP DP ID 6BA02477) over SWD TAP 0
processor type = Cortex-M33 (CPU ID 00000D21) on DAP AP 0
number of h/w breakpoints = 8
number of flash patches = 0
number of h/w watchpoints = 4
Probe(0): Connected&Reset. DpID: 6BA02477. CpuID: 00000D21. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Content of CoreSight Debug ROM(s):
RBASE E00FE000: CID B105100D PID 0000095000 ROM (type 0x1)
ROM 1 E00FF000: CID B105100D PID 04000BB4C9 ROM (type 0x1)
ROM 2 E000E000: CID B105900D PID 04000BBD21 CSt ARM ARMv8-M type 0x0 Misc - Undefined
ROM 2 E0001000: CID B105900D PID 04000BBD21 CSt ARM DWTv2 type 0x0 Misc - Undefined
ROM 2 E0002000: CID B105900D PID 04000BBD21 CSt ARM FPBv2 type 0x0 Misc - Undefined
ROM 2 E0000000: CID B105900D PID 04000BBD21 CSt ARM ITMv2 type 0x43 Trace Source - Bus
ROM 1 E0040000: CID B105900D PID 04000BBD21 CSt type 0x11 Trace Sink - TPIU
NXP: LPC5528
DAP stride is 1024 bytes (256 words)
Inspected v.2 On chip Flash memory using IAP lib LPC55xx.cfx
Image 'LPC55xx Feb 17 2020 13:57:00'
Opening flash driver LPC55xx.cfx
Sending VECTRESET to run flash driver
warning - watchpoint hit but none found set
Flash variant 'LPC55xx (512KB)' detected (512KB = 16*32K at 0x0)
Closing flash driver LPC55xx.cfx
Connected: was_reset=true. was_stopped=false
Awaiting telnet connection to port 3330 ...
GDB nonstop mode enabled
Opening flash driver LPC55xx.cfx (already resident)
Sending VECTRESET to run flash driver
Flash variant 'LPC55xx (512KB)' detected (512KB = 16*32K at 0x0)
Writing 23024 bytes to address 0x00000000 in Flash
Sectors written: 0, unchanged: 1, total: 1
Erased/Wrote sector 0-0 with 23024 bytes in 81msec
Closing flash driver LPC55xx.cfx
Flash Write Done
Flash Program Summary: 23024 bytes in 0.08 seconds (277.58 KB/sec)
Starting execution using system reset and halt target with a stall address
Retask read watchpoint 1 at 0x50000040 to use for boot ROM stall
Waiting for target to stop...
Warning - processor did not halt - gave up waiting
flash - system reset failed - Ep(04). Cannot halt processor.
Target error from Commit Flash write: Ep(04). Cannot halt processor.
GDB stub (crt_emu_cm_redlink) terminating - GDB protocol problem: Pipe has been closed by GDB.

This prevents me from debugging the target on my desktop PC for almost  90% of the time. There are some cases that it does start the debug session correctly. Unfortunately i could not find a solution to maken the debugging more stable on this system. 

When is use the same hardware target and debugger on my laptop it works flawless and debugging works like a charm.  

On my laptop i have version 11.1.0 of MCUXpresso installed. 

On my desktop i started with version 11.1.1. I also installed the older version 11.1.0 to see if this solved my issue but unfortunately i get the same result. 

Both machines run on windows 10. 

I alsready tried to "Clean up debug" data but this did not resolve my issue. 

Any suggestions on how to solve this issue?

[myke_predko]

Hi fruitmans‌,

I've had this situation with MCUXpresso (as well as CodeWarrior) and there are a couple of things you can check.  You don't mention the programm/debugger that you are using, what are the circumstances and my experiences are Kinetis based but I would expect that the debug processes are very similar, if not identical. 

Are you sure that the debugger has stopped from a previous debugging session instance?  I found situations where both stop buttons in MCUXpresso were not both disabled (greyed out) after the previous debug session and when I tried a new debug session I got one similar to what you're getting - it seems like the indications that the programming operation occurred normally is not accurate which confuses the situation.  By clicking on the "Terminate All Debug Sessions" button the debugger is reset and you can restart debugging.  This is the easy case.  

Next, if that doesn't work, open up Windows Task Manager (Ctril-Alt-Delete) and select "DE.exe" in "Processes and click "Exit Process" (Windows 7) or "End Task": (Windows 10).  In this case, when you ended the last debugging session the GDB task didn't end.  It may not end and you have to exit out of MCUXpresso at which point it may end automatically or you have to try again to end it with Task Manager.  

The worst case is that DE.exe will not end, requiring you to shut down the PC and start it back up before the debugger will work again.  

I work with Segger JLink Plus, P&E Multilink Universal and OpenSDA and I have seen these problems in all these programmers BUT I should point out that generally when there is a problem it's because something extraordinary happened, ranging from pulling the USB cable from the programmer/debugger while debugging was still active or shorting something on the processor with a 'scope probe or (referencing a previous question from today) passing EZ_CS_b to an input or driver with while using the JTAG programmer/debuggers listed above.  

I put in this final caveat here because generally MCUXpresso is very reliable and you generally have to do something electrical and/or stupid to get it into a state where it refuses to restart a debugging session.  If you're not doing any of the things that I'm listing then you should be looking at your circuit for something that would cause the programmer/debugger to lock up.  

Sorry, re-reading your question and one more thing I've discovered - if you're good with your laptop, what kind of USB cable are you using between the systems?  I've found that with my (Linux) desktop it won't work with a USB cable longer than 5' (1.5m) but I have three laptops (Lenovo - Windows 10, Acer Windows 7 and HP Ubuntu 18.04) that work with 10' (3m) USB cables.  This is with my JLink Plus and OpenSDA (I haven't experimented with the Multilink Unversal).  I have no idea of what the (electrical) differences are between the laptops and the desktop, especially since the laptops are somewhat decrepit and the desktop is a fairly new and Xeon system/motherboard.  It probably sounds crazy, but try a shorter USB cable (3' or 1m or shorter) on your desktop.  

Good luck,

myke

[fruitmans]

Hello Myke,

Thank you for the replay and sorry for the delayed response. Ha had to wait for the momente that i could take the development board with me to my non functioning work station. As i said it some systems work fine and some do not...

For debugger is use the LPC-LINK2 which is usually working fine for me. How is you experience with different debuggers and debug session stability? Are there big differences?

I am sure that i stopt all debugging sessions and still encounter this issue during development. Even de use of the button "Clean up debug" in MCUXpresso doesn't help.

For the "DE.exe" there is no process active with this name. I scanned through all the tastks to check if there is any process that could be it but didn't find it. So i could not try this.

For the hardware relate issue indeed this can be the case but we use the same circuit compared to the development boad schematics. During these debugging sessions i did not use any "floating" measustment tools like scope probes. For all signals we want to measure we use fixed measurement connectors on this board. But even multiple power off/on cycles and system reboots did not solve the issue.

When i did the experiment why it was working on my laptop and not on my desktop i used all the same cables etc. I just plugged 1 usb cable which goes to a USB hub from my desktop back an forth. One thin i did not try is to connect the debugger directly to on of the desktops USB ports without the addition of a USB hub. I wil try this later this week and keep you posted on this. If you have any other thought please let me now.

With kind regards,

Rik

[myke_predko]

Hey Rik,

I have seen differences in debuggers - they're more pronounced in CW than in MCUXPresso but they're still there.  I find my Segger J-Link Plus works best and provides the fastest single stepping and TAD information updates (but is marginal with 10'/3m USB cables) and my P&E Multilink Universal is somewhat problematic but there's been a number of updates that seem to be making it more reliable.  The OpenSDA on Freedom & Tower boards seems to work fine in all cases. 

I've never found "Clean Up Debug" to do anything.  I'm not really sure what it's for.  

How are you wiring you board's power and how are your USB hub, desktop and laptop powered?  Are you connecting the laptop thorugh the USB hub?  I'm wondering if you have a ground issue.  

Let me know how things work without the USB hub.  

myke