Cannot halt 43xx cores

[lpcware]

Content originally posted in LPCWare by chris_bayley_trimble on Wed Dec 17 14:24:56 MST 2014
I am relatively new to LPC stuff, but am working on a new product incorporating dual HS USB so have been working with USB sample code on several Xplorer-43xx boards and an Xplorer-18xx board.
Yesterday without warning all of my 43xx boards began giving problems with the debugger and started returning a 'Cannot halt processor' error when initiating debug' as below.

LPCXpresso RedlinkMulti Driver v7.5 (Oct 24 2014 22:19:37 - crt_emu_cm_redlink build 172)
Found chip XML file in /Users/cbayley/src/NXP/LPCOpen/Xplorer4330/LPC4357_test/Debug/LPC4357.xml
(  5) Remote configuration complete
Cannot halt processor
Cannot halt processor
Emu(0): Conn&Reset. DpID: 4BA00477. CpuID: 410FC240. Info: (null)
Debug protocol: JTAG. RTCK: Disabled. Vector catch: Disabled.
Cannot halt processor
Failed on chip setup: Ep(04). Cannot halt processor.

I can't identify what may have caused this change in behaviour. At first I suspected the LPCLink-2 but it is still working fine with the Xplorer-18xx board. The 43xx boards I can connect to and halt using OpenOCD and a luminary probe but I haven't yet succeeded in incorporating that into LPCXpresso so I'm still a bit stuck. I've tried with many projects which have all previously been fine, I have tried switching to SWD, but I'm not getting very far.

What things can cause a failure of LPCLink2/RedLink to halt a 43xx processor ? A boot setting ?, some OTP bit ?, ??

I've spent a few hours wrestling with it and would be glad of some suggestions at this point.

Cheers,
Chris

[lpcware]

Content originally posted in LPCWare by metraTec on Tue Dec 22 08:12:24 MST 2015
I've just have the same problem and found the same thing to cause the problem. Even an access via peripheral debug (CCU1) or direct address (*(u32*)(0x40051000+0xB00)) causes a total freeze of debugging and execution.

Has anyone already found any real solution? Just don't changing the value might be enough but is not the right aproach I think.

[lpcware]

Content originally posted in LPCWare by chris_bayley_trimble on Thu Dec 18 17:33:38 MST 2014
SOLVED:

Here's the code that caused the lockout:

LPC_CCU1->CLKCCU[0x100].CFG &= ~1

As soon as that executes I cannot communicate any further and cannot regain control until I have booted in ISP and wiped the flash.

Now I will go and learn why.....

Thanks all,
C

[lpcware]

Content originally posted in LPCWare by chris.bayley on Wed Dec 17 20:26:46 MST 2014
Thanks for the reply,

I'm not sure if I'm making progress but I have to look for small wins today! I booted the board in ISP and managed to clear the SPIFI flash using OpenOCD and an Olimex JTAG which I was not able to achieve before the ISP reboot. I was optimistic however it will still not communicate with the LPCLink2. 'Cannot halt processor' still.

Are there any OTP or CRP bits I need to be warry of that could be getting in the way ?

BR,
Chris

[lpcware]

Content originally posted in LPCWare by nerd herd on Wed Dec 17 16:27:00 MST 2014
Hi Chris,

As TheFallGuy's link mentions, there are several reasons why this may happen. The long story short is that your code likely puts the MCU into a state where the debugger is no longer able to communicate with the MCU. Booting the MCU into ISP mode is a great "catch all" solution for issues involving user code as it puts the MCU into a communicable state and avoids user code all together. After entering ISP mode, it is a good idea to erase the flash with a program such as Flash Magic and see if the issue persists.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed Dec 17 15:59:03 MST 2014
Take a look at this
http://www.lpcware.com/content/faq/lpcxpresso/regaining-debug-access