Custom Board - debug launch problems

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Thu May 24 08:35:04 MST 2012
I have been using the LPC1769 demo board, have a project working and no problems. I just received my custom board with an LPC1756 on it (same family). I changed the MCU setting to LPC1756 and rebuilt. When I try to connect, I get various errors and by repeatedly attempting to launch the debugger, at various times, I have gotten all the way to the "Executing in boot loader" but if I do get this far, it get the following error:

16: Target error from status-poll: Em(12). System rejected access at location 0xE000EDF0 - verify Population of memory and peripherals

Here are the other errors I have received up to this point:

02: Failed on connect: Em(05). Cannot find emulator speed that works.
Emu(0): Conn&Reset. Was: None. DpID: 2BA01477. Info: T1S6RGRIA

02: Failed on connect: Ep(02). Invalid or missing ROM Table.
Emu(0): Conn&Reset. Was: None. DpID: 2BA01477. Info: T1S6RGRIA

Emu(0): Conn&Reset. DpID: 2BA01477. Info: T1S6RGRIA
SWD Frequency: 100 KHz. RTCK: False. Vector catch: False.
Packet delay: 1 Poll delay: 0.
03: Failed on chip setup: Em(12). System rejected access at location 0xFFFFFFFC - verify Population of memory and peripherals

Here is my config:

Running under WindowsXP
Board:

I have verified that TRST, RESET and EINT0 are pulled high through external pull-ups.
TRST is NOT controlled by the LPC-Link, it is always high as soon as power is applied
RESET IS controlled by the LPC-Link
EINT0 is controlled by another chip, but is high at power on (through pull-up)
Clock is connected in slave mode from another chip (13Mhz)

Custom ribbon cable between LPC-Link and my board, I have verified all connections from the LPC-Link to the LPC1756. Cable is about 8" long

I have verified voltages: I'm running at 3.0 (not 3.3) and all Vdd connections are 3.0 volts

Do you have any suggestions/ideas as to what might be causing my problem?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Mon Jun 04 05:33:16 MST 2012
It turns out the other key issue was the voltage. The LPCLink runs at 3.3V, my target's onboard regulator runs at 3.0V. With the Vcc's unconnected, it would not work. As soon as I disabled my target's regulator and connected the Vcc's together so they were both running at the same voltage, everything started working correctly.

Thank you all for your input and assistance. I was pulling my hair out over this.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Wed May 30 08:54:06 MST 2012
Great,

Quote: robert.palmer
WOW. I just got it working.

The issue was with the SystemInit() code setting the processor clock to use MAIN when there was no external EXTAL AND waiting for the USBPLL to stabilize (even though it had not input). Once I fixed those, I now seem to be able to consistently drop all the way into my main() and run.

What I find very disconcerting is that the error messages do not reflect at all that this was a software issue.

This issue comes up about every week or so with new users.
The problem is that the SWD interface relies on a working ARM core (i.e. with a clock) for most of its functions. So if you program the clock or PLL with wrong values and force the main clock to switch over to this source then you end up with a non working (non debugable) solution.
It's almost impossible to detect over the SWD interface if the clock is running or not.

Pulling down P2.10 (ISP pin) will let you program the device again.
But then the debugger will try to run the app and break at main() - this fails since SystemInit() is called before main() is reached ...

As far as I remember the standard SystemInit() switches on the main oscillator and waits (forever) for the clock to become active before switching over.
But I implemented my own clocking stuff (clocking.c, clocking.h) and I only switch clocks within the application (when needed).
Switching CCLK and programming the PLL can be a pain in the ... since this is very hard to debug when something goes wrong. Hence I only switch clocks when needed through my own interface that I know works the way I use it.

Regards,
[INDENT]Rob
[/INDENT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Wed May 30 07:45:32 MST 2012
WOW. I just got it working.

The issue was with the SystemInit() code setting the processor clock to use MAIN when there was no external EXTAL AND waiting for the USBPLL to stabilize (even though it had not input). Once I fixed those, I now seem to be able to consistently drop all the way into my main() and run.

What I find very disconcerting is that the error messages do not reflect at all that this was a software issue.

There was a lot of problems just connecting to the LPCLink. Why would the TARGET affect the LPCLink<-->PC connection. This should be a good stable, working, connection regardless of the TARGET's state and status messages should reflect that.

I'm a complete newby WRT SWD/JTAG and the LPC processors, but as I previously stated, the CLKSRC register does appear to be a volatile register and therefore, the TARGET SHOULD restart correctly after a reset (or at least after a power down), but even with this, the LPCLink would not seem to connect without multiple tries (and the Vector Catch DOES appear to help with this - you have to toggle it On/Off/On and attempt to connect with each setting).

Lets hope this is the end of this issue

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Wed May 30 07:22:56 MST 2012
Ok, I THINK I'm getting closer. I put a breakpoint in the code at the beginning of SystemInit() (I'm using CMSIS). The few times that I can get it to load the code, it will now hit that breakpoint. I then single step in assembly and as soon as I load the CLKSRC register, it bombs. Well, I don't have an external XTAL - I'm using only the internal RC (4Mhz) at the moment and the code is using the default configuration to select the MAIN OSC (external xtal).

Now that I've tracked this down, I've modified the code to NOT select the MAIN and I'm trying to reconnect.

I assumed:
- CLKSRC is a RAM register and would return to the IRC on RESET
- the SWD LPCLink would be able to connect regardless of the clock setting at startup

The errors most of the time seem to indicate failures to connect, I would never have thought those would or could be related to the CLKSRC register.

Toggling the Vector Catch on/off does seem to help some, but I can't figure out the exact sequence that gets the best response.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed May 30 07:03:32 MST 2012
With regards to TCK/SWCLK, ARM recommends a pull-down and, and in some of its docs I think NXP recommends a pull-up. In either case, the main concern is that this signal is not left floating!

Unfortunately I can't comment on what may or may not be implemented in the LPCXpresso board hardware.

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed May 30 06:39:42 MST 2012
A couple of points:

1. If you are running under Parallels, does this mean that you are running on a Mac? If so, you must be very careful as to which USB ports you use to connect the LPC-Link. On my MacBook Pro, (with 2x USB ports), one works correctly and the other fails virtually every time.

2. The errors you are reporting are generally cause by insufficient power being supplied to the board. Flash programming, especially, ups the power requirement well above the steady-state state.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed May 30 06:11:56 MST 2012

Quote: robert.palmer
- I have 10K pull-ups on RESET and TRST. No capacitors
- Vector Catch: how do I enable it? what benefit does it provide?

#1 Increase this pullup :mad: Use 15-47k and add 100nF :)

#2 Vector catch is making debug connections more reliable :)

See: http://support.code-red-tech.com/CodeRedWiki/DebugAccessChip

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Wed May 30 06:02:57 MST 2012
Zero:
- I guess Code Red should correct their information to indicate that SWDCLK should be pulled HIGH, not low
- I have 10K pull-ups on RESET and TRST. No capacitors
- Vector Catch: how do I enable it? what benefit does it provide?

Regarding Rob65's comment " Apparently Embedded Artists and NXP did not find this that important."
- I can see how one could reach this conclusion since the LPCLink/LPC1769 demo board does not have any pull-ups. Apparently, at least for this board EA and/or NXP did not consider it an important issue. I initially left these out, but have since come to my senses and have added the appropriate pull-ups

Rob65:
This problem has happened from the start and is very consistent. The only thing not consistent is how far the startup process gets. As for power, the custom board has a 3.0V linear regulator with plenty of bypass caps around the processor.

POTENTIAL POWER issue
Something I mentioned in the initial post, but no one seems to have indicated it would or could be a problem is:
- LPCLink runs at 3.3V
- Custom board runs at 3.0V
I'm going to disable the custom board's linear regulator and run the board at 3.3V to see if that has any effect

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed May 30 00:46:19 MST 2012

Quote: Rob65
The first link from Code Red mentions that there should be a 10-100k pull down on the SWCLK line (and pull ups on the other lines). On the 1769 LPCXpresso board there are no pull up/downs and I have also no resistors on my board. Apparently Embedded Artists and NXP did not find this that important

Don't know how you reach that conclusion :confused:

RDB1768 from Code Red shows a 100k pullup :eek:

AOAA Kit from EA is pulling up 10k :eek:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Tue May 29 23:04:59 MST 2012

Quote: Zero

Quote:
Originally Posted by [B]robert.palmer[/B] [IMG]http://knowledgebase.nxp.com/images/buttons/viewpost.gif[/IMG]
[I]...that SWCLK should be pulled LOW with a 10k[/I]

Nonsense :eek:

The first link from Code Red mentions that there should be a 10-100k pull down on the SWCLK line (and pull ups on the other lines). On the 1769 LPCXpresso board there are no pull up/downs and I have also no resistors on my board. Apparently Embedded Artists and NXP did not find this that important.

Quote: Zero

Yes, my 58cm 4*0.35mm SWD cable is working without problems since 2 years and 24 weeks now :rolleyes:

I'm not even sure that qualifies for a "Works on My Machine" certification :) It just shows that longer lines are possible - under circumstances.
Fact is that the timing is not that critical. We don't need special balanced lines. I have just a few loose 5" 26 AWG wires between my board and the LPC-Link module and that works for me.

Robert, some questions still:
Does this problem appear also on brand new chips or did this happen only after you programmed your own software in it? although - if the software works on a 1769 module then I don't see why it should not on the lpc1756.

This seems a strange 'bug'. Could be due to power problems too. What's your 3.3V power source? Are there good capacitors on the board (elco with low ESR, ceramic 100 nF caps as close to the chip as possible)?

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Tue May 29 13:54:20 MST 2012

Quote: robert.palmer
...that SWCLK should be pulled LOW with a 10k

Nonsense :eek:

What's your reset pullup & capacitor?

Quote:
...Vector catch: False....

Why don't you switch on Vector catch?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Tue May 29 13:44:23 MST 2012
I did not design the board, but I do have the schematics.

- The board uses a 10pin connector (similar, but not the same as the LPCLink) for the debug connection.
- This is placed very close to the LPC1756 (less than 1 inch)
- The traces are routed directly to the chip without interference from other signal lines.
- I have shortened my cable to about 3". One end is the connector to mate with the board, the other end is bare wires soldered to the holes on the LPCLink at the END of the board (I removed the solder jumpers to isolate the 1769 target from the LPCLink portion - I have verified that I have NO shorts or solder bridges to the 1769 target board)

I WAS using TCK/TDI/TDO/TMS/GND/RESET, but after reading your message, I disconnected TDO/TDI so I'm left with SWDIO/SWDCLK/RESET/GND

I have manually added pull-ups/downs for all of the signals right at the connector on the custom target board.
P2.10 has a 10K pull-up attached to it, manually added by me on the custom target board.

At this point, I got the furthest I had ever gotten. This was the output:

LPCXpresso Debug Driver v4.0 (Mar 24 2012 17:40:00)
Looked for chip XML file in C:/nxp/LPCXpresso_4.2.2_275/lpcxpresso/bin/LPC1756.xml
Looked for vendor directory XML file in C:/nxp/LPCXpresso_4.2.2_275/lpcxpresso/bin/nxp_directory.xml
Found generic directory XML file in C:/nxp/LPCXpresso_4.2.2_275/lpcxpresso/bin/crt_directory.xml
Emu(0): Conn&Reset. DpID: 2BA01477. Info: T1S6RGRIA
SWD Frequency: 3000 KHz. RTCK: False. Vector catch: False.
Packet delay: 0 Poll delay: 0.
NXP: LPC1756 Part ID: 0x25011723
Connected: was_reset=true. was_stopped=false
v Registered license, download limit of 128K
Writing 98692 bytes to 0000 in Flash (assumed clock: 100.0MHz)
Verified-same page 0-7 with 32768 bytes in 2001msec
Verified-same page 8-15 with 32768 bytes in 2033msec
Verified-same page   16 with 32768 bytes in 2002msec
Verified-same page   17 with 388 bytes in 234msec
Flash write Done
nSRST assert (if available)
Executing in user flash.
Stopped: Halt
15: Target error from Register access: Em(12). System rejected access at location 0x0002FFFF - verify Population of memory and peripherals
15: Target error from Register access: Em(12). System rejected access at location 0xFFFFFFFC - verify Population of memory and peripherals

The code hung and when I hit the stop button, I got the last two error messages. I assumed the hang was because I had not yet modified the SystemInit() to use the InternalRC, it was still configured for the Main Oscillator and there is no xtal connected to the chip.

When I updated the code and ran again, it seemed like I was back to square one:

LPCXpresso Debug Driver v4.0 (Mar 24 2012 17:40:00)
Looked for chip XML file in C:/nxp/LPCXpresso_4.2.2_275/lpcxpresso/bin/LPC1756.xml
Looked for vendor directory XML file in C:/nxp/LPCXpresso_4.2.2_275/lpcxpresso/bin/nxp_directory.xml
Found generic directory XML file in C:/nxp/LPCXpresso_4.2.2_275/lpcxpresso/bin/crt_directory.xml
02: Failed on connect: Em(01). Cannot find selected MEM-AP (check target power)
Emu(0): Conn&Reset. Was: None. DpID: 2BA01477. Info: T1S6RGRIA

In addition, the LPCLink is constantly failing to connect (I'm running under Parallels). I have to unplug/plug and uninstall/reinstall the drivers to get it to be detected again.   I'd be fine doing this if I could get a consistent connection to the target board - it seems to work fine when I'm using the 1769 target board.

One thing I noted is that the code-red link listed earlier in this thread says that SWCLK should be pulled LOW with a 10k. However, the link you listed about the SWD connection says that SWCLK should idle high. Bottom line, I tried the pull-up configured both ways, with no additional success.

I'm at a complete loss

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Fri May 25 23:06:15 MST 2012

Quote: robert.palmer

What I didn't expect is what I'm seeing on the SWDIO signal. The LPC1769 is running at 3.3V. SWDIO idles at about 2.1/2.2V. When data goes by, it will then toggle between 0 and 3.3, but I'll also see it go from 2.1 to 3.3 and back to 2.1 or from 2.1 to zero and back to 2.1

SWDIO is a bidirectional signal that can be pulled high or low from both the LPC17xx and the debugger pod. Due to (internal) pull ups and protection circuits you will indeed see something like 2.1V when this line is idle (like with other input pins to the LPC17xx).

Even though the P2.10 pin on the original LPCXpresso board has no pull up, you should always apply a pull up on this line to make sure that the CPU always detects a proper signal.

I have been using a custom LPC1754 board (see bikealive.nl/lpc1754-target.html) in combination with the LPC-Link part of an LPCXpresso board without problems for a long time now. My cable is just 3 wires (about 5" long) only connecting the ground, SWDCLK and SWDIO and this works. There are no pull ups on this board but that is not guaranteed to work - I've seen it failing sometimes when connecting (long) loose wires to P2.10.
In my applications I always use pull ups on P2.10 and reset.

Did you develop the board yourself?
How are the power signals routed to the LPC1756? (and what about the routing of the SWD pins?)
As you can see on the photos of my board you'll notice that the gound plane connects to VIAs close to the gnd pins of the processor, the 3.3V is connected via a star under the chip: all power pins connect to one point and all lines have a 100 nF decoupling capacitor close to the pin.
For power pins I always use wide traces and large VIAs: a larger VIA has a bigger circumference resulting in more copper and thus a smaller resistance.

How are your boards soldered? Are you sure all pads are connected properly? I've had one or two boards that had a bad soldering joint on a PAD - hardly visible without a good microscope.

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri May 25 15:14:30 MST 2012

Quote: robert.palmer
What I didn't expect is what I'm seeing on the SWDIO signal...

but usual :rolleyes:

See: http://lpcware.com/content/blog/introduction-cortex-serial-wire-debugging-part-one

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Fri May 25 14:41:45 MST 2012
I'm trying to understand the SWDIO signal. I've reconnected the LPC1769 demo board and am just using that, examining signals to see what I should/should not expect.

What I didn't expect is what I'm seeing on the SWDIO signal. The LPC1769 is running at 3.3V. SWDIO idles at about 2.1/2.2V. When data goes by, it will then toggle between 0 and 3.3, but I'll also see it go from 2.1 to 3.3 and back to 2.1 or from 2.1 to zero and back to 2.1

Is SWDIO a push-pull with the ability to set it to high impedance? It seems like 2.1 is the voltage when SWDIO is not driven, but the LPC1769 does not have a pull up on this line so it's setting at some undetermined level.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Fri May 25 07:49:03 MST 2012
Regarding the pull-up/down info at the debug cable link...

On the LPCXpresso 1769 board, those are NOT present on the processor side of the board. Are they on the LPCLink portion or is this only a recommendation for custom boards where one would expect the LPCLink to be disconnected and the board run independently?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by robert.palmer on Fri May 25 07:40:15 MST 2012
I'm using a 10K pull-up to Vdd. Yes, I have verified that it is high after reset.

I'll take a look at the link and try to shorten my cable.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Thu May 24 14:48:19 MST 2012

Quote: CodeRedSupport
Signal integrity may well be an issue here then. I would recommend you try using a (much) shorter cable.

Yes, my 58cm 4*0.35mm SWD cable is working without problems since 2 years and 24 weeks now :rolleyes:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Thu May 24 13:09:59 MST 2012

Quote: robert.palmer
ICable is about 8" long

Signal integrity may well be an issue here then. I would recommend you try using a (much) shorter cable.

You might also want to check your debug/circuitry against...

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

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Thu May 24 09:05:38 MST 2012
All "Bootloader" messages indicate problems with P2.10 :eek:

#1 What's your P2.10 pullup?

#2 Did you scope P2.10 and Reset to ensure that P2.10 is high after Reset?