SWD clock speed.

[lpcware]

Content originally posted in LPCWare by micrio on Fri Apr 23 12:19:14 MST 2010
Is there some way to slow down the SWD clock speed? I measure the SWDCLK line at about 7 MHz using a scope.

I am still having problems getting reliable results with SWD on my LPC1113 target. Using the same code on a LPCXpresso board with the LPC1114 works perfectly. The code works in the target board after a power cycle. I just can't use SWD to debug my code in the actual target. The download generally works OK.

I suspect communication problems. Sometimes I see incorrect data in the flash after download. I am using a 6 inch cable on the mini .05 DIP headers. The trace to the chip on the board is no longer than .5 inches. The signal looks good on a scope. Still, I have problems.

Is there a way to slow the SWD interface down from the 7 MHz clock rate?

[lpcware]

Content originally posted in LPCWare by rkiryanov on Wed Apr 28 01:47:47 MST 2010

---

Quote: micrio
Is there anything that is particularly sensitive with the board layout for this chip?

---

I pulled up (15K) SWDIO and SWDCLK with segger j-link, it works perfect.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Tue Apr 27 09:08:40 MST 2010
It seems obvious you have some kind of issue with the debug connections on  your custom board, and it's not certain changing the clock would improve  the behavior. Fortunately, there's a minimal number of connections you  need to worry about. Several LPCXpresso users have physically separated the LPC1xxx from the probe part of the board (at J4), but it's unnecessary as long as the J4 traces are cut. For the LPC1114 you need SWCLK, SWDIO, and GND, but should also connect RESET since the LPCXpresso IDE has occasion to use it. The  http://knowledgebase.nxp.trimm.net/showthread.php?p=342 link describes exactly what other users have done. A one inch ribbon cable should not be necessary, and I have personally used cables over 6 inches without trouble. You're better off to duplicate a known working configuration, such as the LPCXpresso board.

---

Quote: micrio
The reason why I want to slow the clock speed is to try to solve my problem with eratic behavior. I have tried a number of things without any improvement. I have 5 target boards and they all exhibit the same behavior, some worse than others. I am using the internal RC oscillator and running the chip at 48MHz.

I can download my app and it almost always works perfectly but it requires a powercycle before it works.

When I debug my app in my board it never stops at the "main" breakpoint. This works perfectly with my app in a LPCXpresso board. I can stop the app and single step and run with my board but I will get no interrupts. Examining the peripheral registers shows that interrupts are pending. Inserting breakpoints now will work.

Sometimes I see flash memory contents that are wrong after a download. Sometime I see register contents that are wrong for that position in the code.

I tried shortening the SWD ribbon cable to 1 inch. No improvement.

Is there anything that is particularly sensitive with the board layout for this chip? Is there something that I should do with unused pins?

---

[lpcware]

Content originally posted in LPCWare by micrio on Tue Apr 27 06:17:13 MST 2010
The reason why I want to slow the clock speed is to try to solve my problem with eratic behavior. I have tried a number of things without any improvement. I have 5 target boards and they all exhibit the same behavior, some worse than others. I am using the internal RC oscillator and running the chip at 48MHz.

I can download my app and it almost always works perfectly but it requires a powercycle before it works.

When I debug my app in my board it never stops at the "main" breakpoint. This works perfectly with my app in a LPCXpresso board. I can stop the app and single step and run with my board but I will get no interrupts. Examining the peripheral registers shows that interrupts are pending. Inserting breakpoints now will work.

Sometimes I see flash memory contents that are wrong after a download. Sometime I see register contents that are wrong for that position in the code.

I tried shortening the SWD ribbon cable to 1 inch. No improvement.

Is there anything that is particularly sensitive with the board layout for this chip? Is there something that I should do with unused pins?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Apr 26 18:00:33 MST 2010
Can you explain why you think you need to lower the SWDCLK? You didn't mention whether you're attempting to connect to an LPC1113 custom PCB. If this is the case, I presume you're using an LPCXpresso board as a probe. Sorry if I misled you, but Code Red did not implement the emulator speed option on the LPCXpresso probe. If the debug connection to your custom board is unreliable, there should be a few threads on this forum which may help. The LPCXpresso schematics are a good reference. Here are a couple of other links where you can find more information:

http://knowledgebase.nxp.trimm.net/showthread.php?p=342
http://support.code-red-tech.com/CodeRedWiki/CM3_SWD
[COLOR=#000000][FONT=Segoe UI]http://http://support.code-red-tech.com/CodeRedWiki/CM3_SWD[/FONT][/COLOR]
Regards,

CodeRedSupport

[lpcware]

Content originally posted in LPCWare by micrio on Mon Apr 26 05:33:36 MST 2010
I found the help screen of the stub driver which lists the speed flag but I see no change on the SWDCLK signal using a scope. Does the -c flag, CPU speed, have any effect on the line speed?

[FONT=Courier New]$ ./crt_emu_lpc11_13_nxp.exe -h[/FONT]
[FONT=Courier New]Usage:[/FONT]
[FONT=Courier New]c:\nxp\lpcxpresso_3.3.4\bin\crt_emu_lpc11_13_nxp.exe [-v | -info-x | -flash-x][/FONT]
[FONT=Courier New][arguments][/FONT]
[FONT=Courier New]Standalone use (without GDB):[/FONT]
[FONT=Courier New]-v = Display version and build date information only.[/FONT]
[FONT=Courier New]-info-target = Connects to target (without stopping) and returns[/FONT]
[FONT=Courier New]information on processor and chip. Format will be XML if[/FONT]
[FONT=Courier New]-mi specified, else text. Same as 'mon info,all' in GDB[/FONT]
[FONT=Courier New]-info-emu = Show list of emulators possible.[/FONT]
[FONT=Courier New]-flash-x = Perform operation on flash and then quit. 'x' is one of:[/FONT]
[FONT=Courier New]erase = erase all flash page by page[/FONT]
[FONT=Courier New]mass = mass erase all flash[/FONT]
[FONT=Courier New]load=file = erase/load ELF file onto target (e.g. -flash-load=test.axf)[/FONT]
[FONT=Courier New]Note: all flash ops may need -p, -c, and/or -x to be used[/FONT]
[FONT=Courier New]protect= = set flash read protection level (e.g. -flash-protect=1)[/FONT]
[FONT=Courier New]Note: Restricted for use with -flash-load option. Accepts a[/FONT]
[FONT=Courier New]comma-separated list (e.g. LMI FMPPEn|FMPREn).[/FONT]
[FONT=Courier New]-load-base=x = base address/offset for binary file provided with -flash-load.[/FONT]
[FONT=Courier New]May be specified in hex or decimal (e.g. -load-base=0x200)[/FONT]
[FONT=Courier New]Arguments for use with GDB (in 'target extended-remote |' command):[/FONT]
[FONT=Courier New]-p = Set 'package' (chip and/or board, e.g. -pChipName. Package[/FONT]
[FONT=Courier New]implies XML file name or entry in XML file for chip or board.[/FONT]
[FONT=Courier New]Note: This argument is not needed for auto-detectable chips[/FONT]
[FONT=Courier New](e.g. LMI).[/FONT]
[FONT=Courier New]-c = Set xtal speed for chip, if needed, and optionally PLL (KHz)[/FONT]
[FONT=Courier New](e.g. -c8000[,50000]).[/FONT]
[FONT=Courier New]-lfile = Log file enable (e.g. -lFileName). If no file given, then it[/FONT]
[FONT=Courier New]is to stderr (also default if -# used without -l).[/FONT]
[FONT=Courier New]-# = Log level. Default is Comms (1). Levels are:[/FONT]
[FONT=Courier New]0=none, 1=comms, 2=+target, 3=+parse-errs, 4=+commands[/FONT]
[FONT=Courier New]-e = Select emulator by number 0-9, when more than one is available[/FONT]
[FONT=Courier New](see -info-emu).[/FONT]
[FONT=Courier New]-s = Maximum emulator speed (in KHz). Defaults to auto-detect.[/FONT]
[FONT=Courier New](e.g. -s1000)[/FONT]
[FONT=Courier New]-xpath = Set path for XML files (and other chip/board data files).[/FONT]
[FONT=Courier New](e.g. -xc:\xml)[/FONT]
[FONT=Courier New]-g = Progress meter during long operations such as Flash.[/FONT]
[FONT=Courier New]-mi = Assume GDB communication via MI. Output will be for[/FONT]
[FONT=Courier New]Eclipse consumption vs. user readable.[/FONT]
[FONT=Courier New]-rd = Reset delay. Delay in milliseconds after nSRST is released[/FONT]
[FONT=Courier New]before connection sequence is resumed.[/FONT]
[FONT=Courier New]-rh = Reset hold. Time in milliseconds nSRST is asserted.[/FONT]
[FONT=Courier New]-swv-port= = Set SWV server port. E.g. -swv-port=9990[/FONT]
[FONT=Courier New]-server= = Server mode (socket) with host:port or :port[/FONT]
[FONT=Courier New]-vc = Reset vector catch. Simulated for ARM7 by patching in a[/FONT]
[FONT=Courier New]branch-to-self instruction at the reset vector prior to[/FONT]
[FONT=Courier New]assert of nSRST.[/FONT]

[lpcware]

Content originally posted in LPCWare by micrio on Fri Apr 23 19:24:08 MST 2010
I gave that a try and did not see any change in the clock speed. I tried many different values and nothing seemed to have an effect. I used Process Explorer to confirm that the parameters were being passed as expected. Perhaps there is a bug here?

I took better measurements of SWDCLK and it seems that the clock rate is about 1.2 MHz rather than my earlier statement of 7 MHz.

I did notice in looking at the SWDIO line that there seems to be some cycles that only reach half the normal amplitude. Most of the waveforms are at 0 or 3.3 volts. However I can see distinct shadows of pulses that only reach half that amplitude. Could there be a miss-timing between data in and data out where both sides are driving the line at the same time?

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Apr 23 13:00:23 MST 2010

---

Quote: micrio
Is there some way to slow down the SWD clock speed? I measure the SWDCLK line at about 7 MHz using a scope.

I am still having problems getting reliable results with SWD on my LPC1113 target. Using the same code on a LPCXpresso board with the LPC1114 works perfectly. The code works in the target board after a power cycle. I just can't use SWD to debug my code in the actual target. The download generally works OK.

I suspect communication problems. Sometimes I see incorrect data in the flash after download. I am using a 6 inch cable on the mini .05 DIP headers. The trace to the chip on the board is no longer than .5 inches. The signal looks good on a scope. Still, I have problems.

Is there a way to slow the SWD interface down from the 7 MHz clock rate?

---

[FONT=Arial Narrow][SIZE=2]
[SIZE=2]The Code Red debug utility should support this on the command-line, but  I don't see a Script value setting for it. So, you'll need to add it  manually to the debugger script. Navigate to the project Debug  Configuration:[/SIZE][/SIZE][/FONT] [FONT=Arial Narrow][SIZE=2]
[/SIZE][/FONT] [FONT=Arial Narrow][SIZE=2]
Run -> Debug Configurations... -> C/C++ MCU Application ->   Project -> Debugger (tab)

Press the Edit scripts... button, and you'll get an edit dialog for the  Debugger script.

Find the line:

target extended-remote | ${gdb.stub} -g -mi -${debug.level:2}   ${-e+emulator:$null}

You'll need to add the '-s' option to this line. This takes a parameter in KHz. So, '-s1000' is 1MHz, '-s2000' is 2 MHz, etc.

target extended-remote | ${gdb.stub} -g -mi -${debug.level:2}   ${-e+emulator:$null} [/SIZE][/FONT][FONT=Arial Narrow][SIZE=2]-s1000[/SIZE][/FONT][FONT=Arial Narrow][SIZE=2]

Press the "Ok" button, and the "Apply" button when the edit dialog closes. you can then start a Debug Configuration which uses the command-line you edited.

Regards,

CodeRedSupport[/SIZE][/FONT][FONT=Arial][SIZE=2]
[/SIZE][/FONT]