Transceiver board for recovering pulse shape on SWD signals - avoiding bus contention on SWDIO
In the R&D section of the company I work for we use a Segger JLINK to communicate and program our devices. We use our own small "converter board" PCB to convert the JLINK 2x10 pin header connector to a mini DIN-6 connector that transfers SWDIO and SWCLK signals to our device using a CS44 cable. The SWD clock frequency is 16 MHz.
The problem with this is that the drive strength of the JLINK itself is weak, and that the CS44 cable presents significant capacitance from the signal wires inside the cable, to the cable's shield.
These two things degrade the pulse shape of the SWD signals so much, that we can only use very short CS44 cables to communicate with our devices. There are situations where we might need to use 1m long CS44 cables, so I have thought about extending our converter board to be a transceiver (pulse regenerator) board. The current schematic is seen below. I have omitted decoupling capacitors on VCC, but they obviously have to be included.
The idea is quite simple, and uses one SN74LVC1G125 buffer for the SWCLK signal since it is unidirectional and always comes from the JLINK. The SN74LVC1G125 has a pin called OE (output enable) which is active LOW. When OE is pulled HIGH, the output of the buffer is disabled (high impedance).
The SWDIO signal, however, is bidirectional, so I need two buffers pointing in opposite direction, and only one should be active at a time to avoid bus contention. I have the ability of controlling which buffer output should be enabled via the OE pins, but the question is
Question: How do I know which buffer should be active?
How do I know when the JLINK is transmitting commands or receiving instructions? The SWD protocol is not a simple 1 byte transmit, 1 byte receive. If it was, I could monitor SWCLK and increment a counter on each rising edge using a microcontroller, and use the micro's GPIOs to drive the two OE's appropriately. But that is not applicable here. That is why I have left the OE pins unconnected on the SWDIO buffers.
If there is a better/smarter way to do this that I'm not aware of I would be happy to learn. If there is a solution that doesn't involve firmware then that would be ideal.
2 answers
The SWD clock frequency is 16 MHz.
That's ridiculous, turn it down. You don't need anything beyond 1-2MHz for programming, there is nothing during programming that needs a high baud rate, so it can get turned down significantly.
1MHz might be a good compromise between speed and reliability. Even for some >100kib project it gets erased & programmed more or less instantly anyway. Connecting the cables take far longer.
Debugging close to real-time is another matter, but then you would always keep cables short. And there's just so many scenarios where you need to debug close to real-time with SWD. If your MCU doesn't have instruction trace or you aren't debugging by watching trace, then 16MHz is nonsense for debugging purposes too.
The SWDIO signal, however, is bidirectional
So don't use 74LCV125. Use something like 74LVC245. By using a unidirectional buffer IC instead of a bidirectional, you are only creating artificial problems needlessly. Either part is cheap so part price is not a reason. LVC245 works down to 1.65V so it should be no problem even with 1.8V supply.
Ground /OE, keep things enabled at all times.
In general, I strongly recommend the KISS principle for designing hardware and software both.
1 comment thread
The first thing to do would be to see if the clock rate can be configured. Running at 4 MHz, for example, might work reliably even with long cables. I'm not familiar with the JLINK, but other programmers and debuggers I have used do have configurable clock rates. The Microchip ICDx series are examples.
The second thing would be to contact Segger and see what they suggest. They may already have encountered this before and have a solution, even if they didn't turn it into a product. Or they might know why it wouldn't work or what the pitfalls are. These guys are intimately familiar with the programming and debugging protocols of the target chip.
If you are really on your own to make an extender, here are some ideas:
-
Always drive both ways
DATJ is the data line at the JLINK, and DATD the data line at the device. The long wires are always driven by a strong buffer, so the cable capacitance becomes much less of an issue. R1 is a low as possible but still high enough to allow the JLINK output to overcome it. R2 is the same such that the device can still overcome it. R1 and R2 may be different, depending on the drive capability of each end.
-
Always drive both ways, differential
The long wires are now differential for more noise immunity and tolerance of capacitance. This also allows for terminating each differential signal at its receiver with the characteristic impedance of the cable. Use a separate twisted pair for each differential signal.
-
Interpret the protocol
If the protocol is really simple, you might be able to interpret it, at least to the level of knowing the direction data is being transferred. However, I would be weary of corner cases, possibly undocumented behavior, and never getting it quite right.
Turnaround speed might also be a problem. At 16 MHz, each clock cycle is only 62.5 ns. The time to detect and turn around the driver would need to be less than that. Any mismatch with what is implemented in either end would cause a power glitch, even if it doesn't affect the protocol.
The speed means this has to be implemented in hard logic, like an FPGA. Even if you do make it work, it sounds like an endless support problem.
Overall, I don't like this idea.
explain the "driving both ways" circuit
The signal is buffered at each end as physically close as possible to where it is produced. Even a weak driver in the JLINK or the device will be able to drive the input to the buffer after a short length of wire.
Only the buffered signals are subject to the long cable. The point of the buffers is to make the signal low impedance and with more current capability than the weak original signals. The lower impedance and higher current capability can overcome the capacitive loading of the cable.
Now we can get a reasonably clean copy of the signal at one end of the cable to show up at the other end of the cable. We read the signal at each end and manage to transmit those values to the other end despite capacitive loading of the cable.
what you mean by "R1 should still be high enough to allow JLINK output to overcome it"?
The problem from above is what to do with the buffered signal at each end. At the JLINK end, for example, do we drive the buffered signal from the other end onto DATJ (the JLINK is receiving) or ignore the buffered signal (the JLINK is transmitting)?
R1 is a compromise so that we don't have to know. The input to the buffer is high impedance, so has not effect on the signal. We can always read the signal without interfering with it. The buffer can therefore stay always connected. When the JLINK is receiving, its input will be high impedance. In that case, the input is driven thru R1. Again, the connection between the JLINK and R1 is short. There will be little parasitic capacitance, so the signal at the left side of R1 should be pretty close to what is on the right side of R1 when the JLINK is receiving.
When the JLINK is transmitting, its output is low impedance. The JLINK output needs to be able to drive DATJ to whatever it wants regardless of what is on the right side of R1. To allow for that, we make R1 high enough so that the current thru it is limited to what we know the JLINK can source and sink. Let's say for example the JLINK output is specified to be able to source and sink 2 mA. If 3.3 V logic levels are being used, then R1 must be at least (3.3 V)/(2 mA) = 1.65 kΩ.
Taking tolerances into account, let's say the 3.3 V supply can be up to 3.5 V. That means R1 has to be 1.75 kΩ minimum. Using a common 1% resistor, it must have a nominal value of at least (1.75 kΩ)/0.99 = 1.77 kΩ. The next higher common 1% value is 1.78 kΩ.
Now let's take a look at the other consideration, which is edge delay. Assume there is 20 pF parasitic capacitance on DATJ for sake of example. Continuing with the above example of R1 being a 1.78 kΩ 1% resistor, the maximum time constant is (1.78 kΩ)(20 pF)⋅1.01 = 36.0 ns. That means the ½ time is 24.9 ns, the ¾ time 49.9 ns. Perhaps that is too long for a clock period of 62.5 ns. If so, taking extra care to make the connection between R1 and the JLINK output short to reduce capacitance will help. Also, this is based on the JLINK only being able to drive 2 mA. R1 can be reduced if it can drive more, shortening the rise/fall time. This would need to be examined carefully.
0 comment threads