SWD fails when Logic Analyzer is (directly) attached - Page 1
Forum section: electronics / beginners

author: chilippso
author_rank: Newbie
timestamp: July 27, 2021, 10:42:48 pm
content: Hello together,I am having a problem tracing a SWD connection, because as soon as the clock signal line is connected to the Logic Analyzer (ADALM2000), my Segger J-Link EDU refuses to work.My setup is as follows:- J-Link EDU SWD connected to the DUT via a breadboard (GND, VCCref=3V, SWDIO and SWDCLK).- ADALM2000 Digital Inputs connected to the breadboard (GND, D0 = SWCLK, D1 = SWDIO)When I try to connect to the DUT via SWD, the J-Link EDU LED flashes RED a few times, meaning it resets (as far as I know). However, when I disconnect D0 (SWDCLK) at the Logic Analyzer, it works perfectly.Interestingly, everything is fine when I connect a 1k resistor in series. I can connect to the DUT via SWD and trace the SWD signal with the Logic Analyzer.The Logic Analyzer operates at nominal 3.3V LVCMOS and the Segger operates at VCCref (currently ~ 3V).I would like to understand why it does not work when there is no series resistor in between.Clock line current consumption is about 1.3 uA (on average, since clock signal and measured with simple multimeter) at 1 kHz without series resistor and a tiny bit less with .I have a feeling there's a simple reason, but maybe it's too late in the night hereKind regards

author: ataradov
author_rank: Super Contributor
timestamp: July 27, 2021, 11:19:04 pm
content: Increased capacitance on the line may be one of the reasons. Looking with the scope would give more insight.And what is the target device? Are there external pull-up resistors on the SWD lines?

author: perieanuo
author_rank: Frequent Contributor
timestamp: July 28, 2021, 06:36:50 am
content: you missed the important info, the pc or laptop supply, either how do you power your dut, smps or transformer. he's floating?GND on laptops isn't what it was in the 90'swell, isolate galvanic one side of the equation (use a laptop with no charger connected) then if it doesn't work, we can analyse the data lines and further considerationsi repaired south bridges in laptops due to that king of problems, some rogue laptop power supply injecting voltage on laptop's GND, if you connect the usb device attached to that laptop (desktops may suffer from this also) you may risk biginsulated usb exists, almost nobody buys it cause it's not cheapthe 100r trick is when some pcb isn't respecting ttl or rs232 or some other specs regarding power supply or comm side specs, in one project usb-to-ttl device someone implemented this cause of the non-conform dut devices

author: chilippso
author_rank: Newbie
timestamp: July 28, 2021, 08:56:07 am
content: Quote from: ataradov on July 27, 2021, 11:19:04 pmIn the meantime I already though of that, too. I will try to capture and export some scope traces.Quote from: ataradov on July 27, 2021, 11:19:04 pmDUT is a custom PCB with Dialog DA14695 MCU. Schematics and PCB-Layout was done by someone else (semi-professional).There are no external pull up / down for the SWD lines since the DA14695 integrates internal ones. Their reset states are: pull-up for SWDIO and pull-down for SWCLK - according to the specs.Quote from: perieanuo on July 28, 2021, 06:36:50 amI am working here with an HP EliteBook laptop and tried already with detached power supply but either no success without series resistor.At first I powered the DUT with a stabilized lab power supply and shared GND with the J-Link and the Logic Analyzer.There is nothing (relevant) floating.Quote from: perieanuo on July 28, 2021, 06:36:50 amI tried this one today and even powered the DUT completely via it's USB-C port (the board features an USB charging detection circuit and the DA14695 is able to run from VBUS, providing all necessary power-lines via its integrated PMU).Unfortunately, even when the board is powered via the laptop and is completely separated from any other external power source, the issue still exists.Quote from: perieanuo on July 28, 2021, 06:36:50 amSorry but I didn't get your point here. Maybe you can clarify that, please.

author: ataradov
author_rank: Super Contributor
timestamp: July 28, 2021, 03:53:44 pm
content: Quote from: chilippso on July 28, 2021, 08:56:07 amInternal pull resistors are typically weak (~100 kOhm). Logic analyzer may also have weak resistors to keep defined state, and it may override internal resistors. It should not matter as soon as debugger is ready to drive the lines, but MCU may care of what happens before the debugger is connected (SAM Dx MCUs from Atmel enter a reset extension mode in some cases, for example).

author: chilippso
author_rank: Newbie
timestamp: July 28, 2021, 07:55:30 pm
content: Quote from: ataradov on July 28, 2021, 03:53:44 pmThat's an interesting point a colleague also mentioned today. He suspects, that the logic analyzer's pull-up/down conflict with the internal ones, as you said.I borrowed a Scope today and made two traces on the SWCLK line. There is definitely a difference in the rising characteristic of the signal as you can see in the figure down below. Reference 1 (R1) has been captured without logic analyzer attached, i.e. working conditions; Afterwards channel 1 (1) has been captured with logic analyzer attached, i.e. bad behavior.(R1) has a rising time from 10% to 90% of 8ns while (1) has a rising time from 10% to 90% of round about 20ns and a really ugly shape. I guess the clock is way too long in an "undefined state" (i.e. no sharp edge) and hence either the MCU does not recognize it as valid clock signal or the J-Link resets itself. Actually don't know exactly what's going on, since the logic trace seems like J-Link tries to reach out to the MCU but the MCU is not responding. Maybe I'll also attach the logic trace later.Still, the question remains for me why inserting a resistor in series solves this kind of problem. However, it's also possible that I'm just "mentally stuck" at the moment - it has been a long day today

author: ataradov
author_rank: Super Contributor
timestamp: July 28, 2021, 08:54:07 pm
content: This difference should not be significant at slower clock rates. What SWD clock do you use? Try lowering its value.

author: thinkfat
author_rank: Unknown
timestamp: July 28, 2021, 08:56:38 pm
content: I didn't quite get where you connected the 1k series resistor. If it's between the LA and the SWCLK signal, of course the effect is that the capacitive load of the LA inputs will not have as big an influence on the SWCLK signal itself. The drawback is that the LA will see a degraded signal, but that might not matter enough to throw off the decoding.

author: chilippso
author_rank: Newbie
timestamp: July 28, 2021, 10:53:16 pm
content: Quote from: ataradov on July 28, 2021, 08:54:07 pmDuring this explizit capture (and in general for debugging this issue) the J-Link is set to clock out 1 kHz on SWCLK.Interestingly, I made a new observation: When I increase the clock to e.g. 13846 kHz (180 MHz / 13), the MCU actually recognizes some SWD commands (since J-Link Commander at least establishes a connection, even though not all values are getting read out correctly).Quote from: thinkfat on July 28, 2021, 08:56:38 pmExactly, between LA and SWCLK.The setup looks like this:[J-Link]--SWCLK-->--SWCLK-->--SWCLK-->--SWCLK-->[Logic-Analyzer]So the breadboard is used as some sort of "SWCLK-Hub".Quote from: thinkfat on July 28, 2021, 08:56:38 pmThat's true. It is actually working with the series resistor. But I want to understand why and how I can measure this issue, since this fix was just "by chance" / "trial & error" - and I want to find a profound explanation why the issue exists and how to fix "properly".Quote from: thinkfat on July 28, 2021, 08:56:38 pmSo maybe I need to refresh all the impedance complex formularies in my mind but how does a series resistor reduce the overall capacitive load?Unfortunately, I forgot to take a trace with the scope when the series resistor is actually "in the loop". I will capture that trace tomorrow and compare the result with the two other cases (ok /wo LA and faulty w/ LA)

author: perieanuo
author_rank: Frequent Contributor
timestamp: July 29, 2021, 05:57:48 am
content: Quoteso, if you floated your laptop, you eliminated the grounding issue. powering the dut in such cases from battery would be better, but i consider that's fineas atarodov and chilippso pointedQuote from: ataradov on July 28, 2021, 03:53:44 pm, because of DUT being not very well implemented (for example, that pull-up weak resistor issue on most micros impose schematic design engineer to add 2 restistors that costs 2 cents. most of them don't add the resistors, putting you in the situation of resolving (after scoping the communication between your communication USB device and the DUT and seeing clearly the transitions between the H and Low level are less than ok) the issue dy tinkering the comm device.one simple solution we found when we were designing USB-to-TTL communication device (for our own pcb's developed in our own company, in order to update them or communicate with them) was to add on the data lines series resistors (i already forgot, but afair we got the best results adding resistors between 47R and 100R).i wouldn't discuss all the theory behind speed, wiring lenght, pcb layout, parasitic capacity etcaetera, but if your GND rail is not noisy, then your data lines corrupt waveform integrity, as atarodov pointed very well as usual, one trick is adding those resistorsas for me, i put 47R on such interface, my boss choose to put 100R on devices for selling (a simple FT232L at the time, sometime we implemented that on specific project into the main pcb to offer rs232 or 485 comm, in conjunction with ADUM1201 as 'galvanic' insulator and LTC485 when the client wanted rs485, in older version 74HCT00 with 100R on TTL I/O was used)

author: thinkfat
author_rank: Unknown
timestamp: July 29, 2021, 08:42:30 am
content: Well, if you connect the LA directly to the signal, you basically connect the signal to a R || C element to ground, the input impedance of the LA. If you put an additional series resistor in between, you have R + (R || C).If you concentrate on high frequencies, which are responsible for the "steepness" of the rising / falling edges, those are dominantly affected by the "C" component of the input impedance. The higher the frequency, the lower the impedance, of course. But with the series "R", the impedance will be at least "R", even if "C" was a short-to-ground.Now, for a real "fix", a closer look at the total signal path will be necessary. It seems to me that the J-Link output can not drive high capacitive loads and that the MCU itself has really strict requirements for the rise/fall time of the SWCLK signal, because for a 1kHz signal, a 20ns rise time would still be plenty fast. I don't know about the input impedance of you LA, but it seems to have a considerable capacitive component to ground, looking at how much it affects the signal slope.A proper fix IMHO would be a high impedance buffer in front of the LA inputs. Some CMOS buffer might be sufficient, like 74HC126 or something. You can get it in DIP package, you could just add it to your breadboard circuit.

author: mikerj
author_rank: Super Contributor
timestamp: July 29, 2021, 09:30:42 am
content: Quote from: chilippso on July 28, 2021, 10:53:16 pmIt's either capacitive loading of the signal which is reduced by adding the resistor, or you are getting reflections which again would be reduced by the resistor

author: chilippso
author_rank: Newbie
timestamp: July 29, 2021, 11:38:01 pm
content: I've been scoping all day, but I haven't come up with a solution. The signals look almost identical, and I can't find any indication that something is off, even after reading the SWD specification and timing requirements. If anyone is interested, the SWD protocol is described in theArm® Debug InterfaceArchitecture Specification (ADIv6.0), chapterB4: The Serial Wire Debug Port (SW-DP). As noted at the very beginning of the chapter, "This specification does not describe the physical characteristics of the SWD interface, such as signal timings." Fortunately,I found something online here, even though it is related to Arm® DSTREAM. But I think I will have to check the DUT-MCU datasheet again to see if there are any other specifications - maybe general ones, because a quick search in the specification on "SWD" was not very successful.I have attached 3 trace images and CSV exports for anyone who would like to help me analyze the problem.Channels (1)/(D1) are SWCLK and (3)/(D0) are SWDIO. The markers are enclosing the "line turnaround" (B4.1.3 in the specs) cycle after the first SWD command right after the first line reset (after switching protocol from JTAG to SWD). The SWCLK frequency for these traces is now at 2 kHz.swd_without_LA:Trace when there is only the the Scope attached. Result: OKswd_with_LA: Trace when there is the LA attached. Result: NOKswd_with_LA_but_10k_in_series:Trace when there is the LA attached with 10k series resistors in line. Result: OKQuote from: perieanuo on July 29, 2021, 05:57:48 amI tried external pull-up/down resistors on the breadboard, but that didn't fix the problem. Looking at the oscilloscope trace, I would say that there is no voltage level problem here, i.e. the internal pull-up/down resistors do not seem to be the cause of this problem.Quote from: perieanuo on July 29, 2021, 05:57:48 amI've already come up with that, but I don't have a reasonable explanation as to why that works in this particular case, since I can't measure or explain the cause of the problem.By the way, a "simple impedance matching", i.e. line termination, with low impedance resistors does not lead to the desired result. If the chosen resistors value is too low, it does not work anymore.Quote from: perieanuo on July 29, 2021, 05:57:48 amI must confess, I currently have no idea how to measure fluctuations in ground potential, as I can't tell what to take as a reference on the fly.Quote from: thinkfat on July 29, 2021, 08:42:30 amI can follow you here. But I still can't see why the total capacitive load should be lower when the total resistance becomes higher.Quote from: thinkfat on July 29, 2021, 08:42:30 amI have not checked the driving strength of the J-Link EDU. I will check on that. As for the timing requirements, I found something, as mentioned a few lines above, about timing requirements. However, I am not sure if the DUT-MCU itself has specific requirements.Quote from: thinkfat on July 29, 2021, 08:42:30 amAs far as the digital inputs are concerned, I have no clue either. The analog inputs are specified with 1 MΩ || 30 pF.If someone would like to take the effort to analyze the schematic regarding the digital inputs:it can be found here.In my setup, SWCLK is on D0 and SWDIO is on D1. These are pins 16 and 18 of TSW-115-08-F-D-RA in the schematic.Quote from: thinkfat on July 29, 2021, 08:42:30 amThis is definitely a nice solution.Quote from: mikerj on July 29, 2021, 09:30:42 amI would really appreciate it if you could somehow explain to me how I can verify for sure which of the two problems are actually the case. Somehow the problem has to be quantifiable, doesn't it?And thanks to all of you who have made so many good contributions so far! I feel like we're getting closer and closer to understanding exactly what's going on in this case.

author: ataradov
author_rank: Super Contributor
timestamp: July 29, 2021, 11:52:21 pm
content: Can you try that J-Link with Open-OCD and full debugging info enabled?There is nothing wrong with those signals, so it would be interesting to know what step fails exactly.

author: thinkfat
author_rank: Unknown
timestamp: July 30, 2021, 07:46:28 am
content: What's also worth looking at is the phase shift of the clock signal that results from connecting the LA input. The signals all by themselves might look fine, but there might be a timing issue. So, it will make sense to look at both signals clock and data, with and without the LA connected.EDIT: I just noticed that is what you did with the recent screen shots, but the temporal resolution is not enough. What is most interesting here is how the phase of the clock changes against the data. If you could provide something that only shows one or two rising clock edges and data, that would be more telling. Target samples data on the rising edge of the clock while the J-Link writes data on the falling edge, so the timing is extremely relaxed at 1kHz clock. Target writes data on the rising edge of the clock, but the J-Link also reads data on the rising edge, so if the target sees a delayed clock while the J-Link samples the data already when it sets the clock signal to high, this might create a timing violation. It might be that the J-Link reads garbage in this case, while the target has no problem understanding what the J-Link sends.EDIT2: this is the reason why I added a feature in OpenOCD in the FTDI driver, to have the probe sample data on the falling edge instead of the rising edge. This helped a great deal with JTAG at higher speeds (like, above 10MHz).

author: chilippso
author_rank: Newbie
timestamp: August 02, 2021, 12:49:16 pm
content: Quote from: thinkfat on July 30, 2021, 07:46:28 amI don't really think this is the issue here, since as far as i can tell, the target already responses with an erroneous acknowledge (0b101) to the very first 0xA5 (read DPIDR) command sent by the host. As you stated, the J-Link writes data on falling clock edge, so indeed there should be no timing issues with an 1 kHz clock.Unfortunately, I have no clue what this acknowledge (0b101) means. TheArm® Debug Interface Architecture Specification (ADIv6.0)does not liste it neither in B4.2.1, B4.2.2, B4.2.3 nor B4.2.4.Quote from: ataradov on July 29, 2021, 11:52:21 pmThis is an interesting approach, I will try it later as I am quite busy with other stuff this week.

author: capt bullshot
author_rank: Super Contributor
timestamp: August 02, 2021, 01:02:56 pm
content: Quote from: chilippso on July 28, 2021, 07:55:30 pmThe prolonged rise time (and the visible "knee") most probably cause signal integrity problems at the SWCLK input of the uC. One symptom might be the uC "sees" two rising edges here instead of one, causing one (or more) bit(s) shifted into the registers than intended by the debugger.Symptoms like these are quite usual if one uses too long wires, or attaches more wires to an intended point-to-point signal. As you found out by chance, a series resistor is the proper cure for these symptoms. The series resistor dampens the ringing / reflections / capacitive loading from the additional wire length and helps to keep the signal integrity at the uC pin.Decreasing the SWD speed won't help anyway, as the real interference happens within some ns (while the signal is rising or falling). The oscilloscope doesn't necessarily show all the evil reality here, at higher frequencies than the bandwidth of the scope there might be tiny signal distortions at the rising edge of the signal causing the SWD to malfunction.These might be cause by "ground bouncing" or reflections of longer wires. These interferences most probably are the root cause for the "unknown" acknowledge, which is most probably a result of one (or more) bit(s) beeing swallowed.

author: thinkfat
author_rank: Unknown
timestamp: August 03, 2021, 07:33:55 am
content: Quote from: chilippso on August 02, 2021, 12:49:16 pmHow do you know? 0b101 is an invalid response, the target will never send it. It can well be a 0b001 sampled incorrectly by the probe. I think you're trapping yourself, ruling out causes without proper testing because they don't seem plausible to you. But does your experience really allow you to make such assumptions?I outlined above that the timing constraints TOWARDS the target seem very relaxed, yet for communication FROM the target to the probe it's much more critical and may well be affected by a CLK delayed a few nanoseconds.Now, pick up the scope and probe clock and data as close as possible to the probe side, trigger on rising edge of the clock and then pick a sequence where the target drives data and see if the data is already set and stable when the rising edge of the clock appears, which is where the probe would sample data.