Comments on Transceiver board for recovering pulse shape on SWD signals - avoiding bus contention on SWDIO
Parent
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.
Post
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
0 comment threads