After converting LPC812 code to run in LPC824, programming problem

[jamesl1]

We have a product which uses a LPC812 and I have run out of code space for the next feature. I could probably optimise it a bit, but I think it's pretty well utilised! So I have ported it to run in a LPC824, and changed the GPIO pins etc.

I changed the device in Project Settings in MCUXpresso IDE, and have found I am unable to program it reliably (or make a debug connection). I have been trying for a week or more, fiddling with settings, making a new SWD cable, making a new ISP cable etc., and have succeeded a couple of times out of what feels like hundreds of failures. Cables are about 200mm (8") long ribbons.

I have an LPC-Link (OM13053) and an LPC-Link2 (OM13054) both of which work fine with the LPC812.

I confirm the RESET line is pulled up with 10k and the ISP line is not connected, so free to be pulled high by its internal pullup. 

I thought I might have a bad batch of micros so I bought some more from a different vendor - different batch, same behaviour.

What did I miss?

[frank_m]

Did you try a "native" LPC824 project, and does it have the same problems ?

I think any SDK example should work for that purpose. Just to exclude hardware issues.

If that works, I would consider setting up your project anew for the LPC824. My experiences with changing the target of projects for Eclipse-based IDEs had been ... mixed, to say the least.

[jamesl1]

No I didn't. Thanks, good idea, I'll try that tomorrow.

I have another puzzle piece: the output of lpc21isp

james@minty:~$ lpc21isp -bin ./Phathom.bin /dev/ttyUSB0 115200 12000
lpc21isp version 1.97
File ./Phathom.bin:
	loaded...
	image size : 14240
Image size : 14240
Synchronizing (ESC to abort). OK
Read bootcode version: 1
13
Read part ID: unknown (0x00008242)
Internal error: wrong chip variant 0 (detected device 0)
james@minty:~$ 

I know that only tells me that my version of lpc21isp doesn't know the chip, but it might also contain a clue

[ZhangJennie]

Seems this project select wrong part.

Please follow above advice to create a new project to test connection.

[jamesl1]

I have created a new project with LPC824 selected. This is now my console output. It looks better, I now can see the USB Path has a value, and the CPUID is no longer 00000000 and it is 00000C60 (which is still wrong, but something has changed).

MCUXpresso IDE RedlinkMulti Driver v11.4 (Jul  2 2021 12:03:47 - crt_emu_cm_redlink build 1)
Found chip XML file in C:/Users/OEM/MCUXpressoIDE/workspace/Phathom/Debug\LPC824.xml
Reconnected to existing LinkServer process.
Probe Firmware: LPC-LINK2 CMSIS-DAP V5.361 (NXP Semiconductors)
Serial Number:  JXBUJZIW
VID:PID:  1FC9:0090
USB Path: \\?\hid#vid_1fc9&pid_0090&mi_00#8&20a91899&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Using memory from core 0 after searching for a good core
On debug connection - reset using system reset
request to clear DAP error failed - status 5
debug interface type      = CoreSight DP (DAP DP ID 0BC11477) over SWD TAP 0
processor type            = Cortex-M0+ (CPU ID 00000C60) on DAP AP 0
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
Failed on connect: Nn(05). Wire ACK Fault in DAP access
Connected&Reset. Was: NotConnected. DpID: 0BC11477. CpuID: 00000C60. Info: <None>
Last stub error 0: OK
Last sticky error: 0x0 AIndex: 0
Debug bus selected: MemAp 0
DAP Speed test unexecuted or failed
Debug protocol: SWD. RTCK: Disabled. Vector catch: Enabled.
(100) Target Connection Failed
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
error closing down debug session - Nn(05). Wire ACK Fault in DAP access

[ZhangJennie]

In addition of above suggestion, see if below debug design consideration can help you.

https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Design-Considerations-for-Debug/m-p/469565

[jamesl1]

Thank you Jennie, That was interesting. The pull-down resistor on SWCLK recommended in the microcontroller manual UM10800 has conflicting advice in this document "Design Considerations for Debug". In the LPC8xx all these pins (and also the ISP pin) are inputs with pullup when they come out of reset. And this document says not to pull down externally.

When I do pull down externally, the CPUID goes back to 00000000 which I had originally. 

There is a sentence under the heading "Logic levels and ground" which clearly describes the function of jumper JP2. I need JP2 installed. It wasn't. I think it's working for LPC-Link2 now.

Still not working for  LPC-Link, maybe it is broken - I'll try both on an LPC812 tomorrow.

[jamesl1 · Accepted solution]

Sorry for the delay. We are a small company and there are other things I had to attend to. Thank you for your support and encouragement. It is good to know you are there to help with problems. Sometimes I feel lonely in this regard: I do not have a colleague who understands this stuff, who I can discuss these things with.

After realising that my target is expected to power the LPCLink2 buffers, I installed jumper JP2 and succeeded in connecting reliably to the PCB with only the microcontroller installed. I looked at the data exchange on the SWD interface and got used to what a good one looks like, and what my failed one looks like. The clock signal was the same. But on the faulty one, the data signal starts properly, and then stops working part way through the initial "conversation".

I decided to change the micro on the 2 fully populated PCBs I have here at home in lockdown, and they now work as expected. I have to conclude that either I did bad soldering, or I damaged the micros when I installed them, or the first batch is bad. I won't know until I can get back to the office and test them. Two units from the second batch, which I have here, are working.

[jamesl1]

Thanks Jennie and Frank. It seems I have a hardware problem

Error in final launch sequence:

Failed to execute MI command:
-target-select extended-remote | crt_emu_cm_redlink -msg-port=57208 -g -mi -2 -pLPC824 -vendor=NXP -vc   --reset= -ProbeHandle=1 -CoreIndex=0 --flash-hashing --flash-driver LPC800_32.cfx --telnet 3330
Error message from debugger back end:
Remote communication error.  Target disconnected.: Success.
Failed to execute MI command:
-target-select extended-remote | crt_emu_cm_redlink -msg-port=57208 -g -mi -2 -pLPC824 -vendor=NXP -vc   --reset= -ProbeHandle=1 -CoreIndex=0 --flash-hashing --flash-driver LPC800_32.cfx --telnet 3330
Error message from debugger back end:
Remote communication error.  Target disconnected.: Success.

The IC is on my PCB, and there's only another resistor there, RESET pullup. I'll start cutting tracks to the other pins (except power, gnd, swdio and swclk of course) until it works

The console shows this

MCUXpresso IDE RedlinkMulti Driver v11.1 (Jul  7 2020 10:48:32 - crt_emu_cm_redlink build 5)
Found part description in XML file LPC82x.xme
Reconnected to existing LinkServer process.
Probe Firmware: LPC-Link Probe v1.3 (NXP - LPC-Link)
Serial Number:  WIN64HS12
VID:PID:  1FC9:0009
USB Path:
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
Failed on connect: Em(19). Communications with DAP fails - is probe connected to a target?
Connected&Reset. Was: NotConnected. DpID: FFFFFFFF. CpuID: 00000000. Info: <None>
Last stub error 0: OK
Last sticky error: 0x0 AIndex: 0
No debug bus (MemAp) selected
DAP Speed test unexecuted or failed
Debug protocol: SWD. RTCK: Disabled. Vector catch: Enabled.

[frank_m]

> The IC is on my PCB, and there's only another resistor there, RESET pullup.

A pull-up on the JTAG/SWD reset line is fine, I would not cut it.

But otherwise, you have two unknowns here - the differing project setting, and your own hardware.

I would do a careful hardware check, i.e. connections of all connector pins to IC pins. Then the current consumption (without debug pod). I had occasional power supply problems with larger boards, i.e. the supply line from the debug pod was not sufficient. You would need to supply the debuggee externally then.

The MCU will start up with the internal RC oscillator, but PCB design issues with supply tracks and buffer caps could affect it at this state. I am no hardware expert, though.

[jamesl1]

When I said there is only another resistor (reset pullup) this is what I meant. Actually the other resistor I didn't mention is a 10R in series with the power, and shows me it's drawing 2.2mA which is textbook correct. I'll add the 100k's to the SWD data and clock pins and see if that fixes it.

[frank_m]

> Actually the other resistor I didn't mention is a 10R in series with the power, and shows me it's drawing 2.2mA which is textbook correct.

This seems a bit much to me. Flashing and other operations might cause higher current consumption (flashing definitely will !), causing the supply voltage to drop. This can cause trouble.

I would either remove it once you checked your board, or reduce it to 1R or less.

[jamesl1]

I have always used 10nF/10R filter on the power to modern microcontrollers. (I mean since I stopped using 68HC05's and -11's which have much more powerful I/O. A different approach is needed). The equivalent series inductance of a 100n capacitor is so much higher than a 10n cap it won't catch spikes, so I don't want to take the resistor down to 1R if I can help it.

I hope it's not that bad because there are millions, I exaggerate, hundreds of thousands of product out there designed by me with these wrong values!

For troubleshooting I'll short it out. Thanks for your continued support. We'll get there

[frank_m]

> The equivalent series inductance of a 100n capacitor is so much higher than a 10n cap it won't catch spikes, so I don't want to take the resistor down to 1R if I can help it.

These caps do not buffer "spikes" created by a series resistor in the power supply.

The supply voltage is created by some voltage-regulated power supply circuit. And this IC regulates to 3.3V (I assume) over your 10R + MCU series circuit. The MCU only sees 3.3V - (I * 10R), thus the less VDD the more current it draws.

[jamesl1]

Thanks for your input Frank. It was you who unblocked my thinking on this, and ultimately allowed me through to the solution.

Solving one problem at a time is easy. Fixing a faulty system with two simultaneous faults is harder. This one had three.

And you're right, you're not a hardware guy. Your last message is correct generally but the last half-sentence is backwards: should be "thus the more current it draws the less VDD it sees." That is a drawback of the RC filter, but I'm not using the analogue section so I don't need an accurate stable Vdd. (This device only needs a 20ns spike to activate reset so I have gone overboard on filtering.)

[frank_m]

> And you're right, you're not a hardware guy. Your last message is correct generally but the last half-sentence is backwards: ...

A schematic might have been helpful ...

> Solving one problem at a time is easy. Fixing a faulty system with two simultaneous faults is harder. This one had three.

That is a significant part of the (embedded) SW business - partition your task or problem into small, easily comprehensible and verifiable sub-tasks. Just a learning process we go through ...

BTW, referring to the previous post : you would wonder how tiny the SW engineering departments even of large companies are sometimes. Especially machine engineering companies tend put very little importance and effort in their embedded software and a proper development process. Unless they are forced to by e.g. safety requirements and regulations ...