Fun and games with Serial Wire Debug

[ianbenton]

I retracked the pcb for my LPC1517 project to move the SWD socket, and shall we say - the routing wasn't the best. The data and clock went directly, but the 0V took a round-the-houses route around the back of a little (1 Watt) buck regulator. Not the pcb tracking I'd use if I wanted -130dBV/√Hz out of a microphone preamp but for a digital signal with 1V of noise immunity, at no great speed I thought it would be OK - but no - loads of ACK, Failed to write Flash and that sort of error.  I cut the track, replaced it a piece of wire following the route of the data and clock tracks and it worked.

So, SWD is like a half-duplex version of SPI with MOSI and MISO multiplexed on to one pin, and it runs at 1MHz; so the important times are the clock transitions. Nothing else matters much. So there could be three things preventing it working - ground bounce caused by too fast an edge, jitter caused by too slow an edge, or interference getting in because the target is at quite a high impedance. So I tried a few things - 220pF across clock to ground, 1k pull-down, and 10k series impedance - 1k seemed most promising, but no real success.

The LPCXpresso crashed - I force quit it, and restarted it.
Then it all worked

So no I'm more puzzled than ever.

Another board from the same batch was prone to errors, but would work if my oscilloscope earth clip was connected to the circuit 0V.

I hear you saying that that that means the circuit should be properly earthed - but the circuit 0V is bonded to mains earth and the oscilloscope isn't.

A further puzzle is the "Target error from Commit Flash write" which says "system rejected access at location x"; but all the errors I got location x was in the RAM.

A different circuit won't connect when it is in its cabinet where it lives next to a switched mode supply. Take it out of the cabinet and it works with no problems.

I find this all very puzzling as I used SPI all the time at ten times the speed with no great considerations for pcb tracking. If it worked this badly, my LED displays would be flickering like a fluorescent tube with a duff starter.

Anyone any ideas?

[frank_m]

> Anyone any ideas?

One thing I would try is to reduce the SWD clock frequency, just to see how it works.

And I would suggest an order of magnitude, i.e. 100kHz or less.

Debugging isn't fun that way, but it could prove a point.

[Luke862]

I created a singleton named Debug and a basic text box that is always on top. Instead of printing, I can now do

Debug.output(text)

As a result, it shows up in-game while I'm testing. When you only have one monitor, it makes things so much easier sometimes, practically all of the time.

Sims 4 satisfaction points cheats here was most recently useful when the only way to debug anything was to get live updates on the exact coordinates that my reticle was looking at, which would have been a pain to do using print() and would have enraged Godot. "reduce the amount of text printed"

Also useful for catching those only-occurring problems in real time without having to keep a close eye on the Godot output log.

[jeremyzhou]

Hi  Ian Benton,

To provide the fastest possible support, I want to point you to refer to Serial Wire Debug chapter in reference manual

to view the details.

Have a great day,

TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ianbenton]

Not quite sure what you were expecting me to find in the reference manual that I didn't already mention in my post. In the three pages in the LPC15xx manual there is very little other the connection diagram and the fact that both pins have pullups. It doesn't even say that SWCLK is only an input and SWDIO is bidirectional. Most of my information came from ARM's white paper on the subject.

At least I'm glad that NXP has stopped recommending a pullDOWN on SWCLK - that would really trash the noise immunity especially if you happened to get the same resistance as the internal pullup.

Anyway, I pursued my experiments a little further, and added a schmitt trigger to the SWCLK input. I tried a 74LVC1G17 and also a pair of gates from a 74HC14. The result was astounding. On my not-too-well-tracked board the error rate dropped from 65% to ZERO. Not a single programming failure in 100 attempts (no difference between 1G17 and HC14)

I then extended the lead beyond the standard 150mm. Not a single failure with a 1 metre lead between LPC-LINK and targert. Still no failures at 3 metres. Beyond that the bulk capacitance of the cable on the un-buffered SWDIO line became a problem and errors crept in.

Next to try it on the circuit with the noisy-switched-mode supply!

Hysteresis seemed to solve the problem, and pin PIO0_18 has a hysteresis option, but I'll bet you a pound to a penny that it's not switched on during SWD operation. Though I wonder if I set bit 5 of the IOCON register in my software, will the hysteresis remain switched on for the next time it is programmed?

Note to anyone else who wants to try this: Your SWCLK input (the input to the 74LVC1G17) will now need a pulldown resistor. I used 3.3kΩ. The value doesn't matter too much as the connection is too short to be regarded as a transmission line so it isn't technically a "terminator".