Post History
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 pro...
#2: Post edited
by
Olin Lathrop
·
2026-07-09T13:28:51Z (2 months ago)
- 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:<ul>
- <li><b>Always drive both ways</b><br>
- <img src="https://electrical.codidact.com/uploads/diw1knxv73copgilbdszsyamvoev">
- 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.
- <li><b>Always drive both ways, differential</b><br>
- <img src="https://electrical.codidact.com/uploads/hj1desmf3h8twq9e0efweigmrnwa">
- 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.
- <li><b>Interpret the protocol</b>
- 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.
</ul>
- 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:<ul>
- <li><b>Always drive both ways</b><br>
- <img src="https://electrical.codidact.com/uploads/diw1knxv73copgilbdszsyamvoev">
- 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.
- <li><b>Always drive both ways, differential</b><br>
- <img src="https://electrical.codidact.com/uploads/hj1desmf3h8twq9e0efweigmrnwa">
- 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.
- <li><b>Interpret the protocol</b>
- 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.
- </ul>
- <blockquote>explain the "driving both ways" circuit</blockquote>
- 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.
- <blockquote>what you mean by "R1 should still be high enough to allow JLINK output to overcome it"?</blockquote>
- 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.
#1: Initial revision
by
Olin Lathrop
·
2026-07-08T22:08:29Z (2 months ago)
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:<ul> <li><b>Always drive both ways</b><br> <img src="https://electrical.codidact.com/uploads/diw1knxv73copgilbdszsyamvoev"> 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. <li><b>Always drive both ways, differential</b><br> <img src="https://electrical.codidact.com/uploads/hj1desmf3h8twq9e0efweigmrnwa"> 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. <li><b>Interpret the protocol</b> 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. </ul>