eBay J-Link OB clone SWO hacking

Some time ago I bought a standalone J-Link OB clone off eBay. The J-Link OB (On Board) is a small footprint debugger, which Segger licenses to manufacturers to put on their boards, so that no external debugger needs to be used. Despite of this, standalone clones of this debugger have been available on eBay for some time very cheaply. I couldn't resist the price, although looking back, I probably should have just bought the J-Link EDU for 60e.

The J-Link OB standalone clone, which I purchased. Picture taken from eBay listing.

To the point. The debugger works well and all, but lacks SWO capability - in fact there are no J-Link OB clones on the market, which would support it. SWO is a fast serial line for transferring debugging data from the microcontroller to the host computer. The microcontroller has dedicated hardware for this, and the transmission of data is managed without breaking the execution on the microcontroller. Lack of this capability limits the tracing to either UART based transmission or semihosting, which requires setting special break points in the code and thus causes a considerable delay in execution. The material from Segger however indicates that the J-Link OB should support SWO. This got me thinking if the debugger could be modified to support SWO.

Looking around the internet I managed to find the schematic of a J-Link OB debugger using the same microcontroller as the one in my debugger (this is the STM32F103C8 in a QFP48). I won't link it or replicate it here as it is something that should be licensed from Segger. The schematic wasn't an exact representation of the circuit in my debugger, but it was close enough.

The schematic showed that all JTAG pins were in fact connected to some pins of the microcontroller. Most of the them in fact had two pins on the microcontroller - a drive pin and a sense pin - and had 100 ohm resistors connected between the drive and sense pins. The SWO is transmitted through the JTAG pin TDO. This pin is an exception to the drive and sense arrangement, as it only had the sense pin. Luckily it was still connected to an external pull-up resistor, which allowed for easy modification.

The SWO input is directly tied to microcontroller pins PA6 (pin 16), PA10 (pin 31) and PB15 (pin 28). For a first test, I just soldered a wire to the low side of the pull-up resistor and attached that to the SWO output of my target.

Quick bodge to see if SWO works on the debugger.

The initial test produced output on the SWO terminal, which was synchronized with the output from the target, but complete garbage. This turned out to be only a problem of configuration. Once that was taken care of, the messages were coming through loud and clear :-)

Satisfied by the way everything was working, I then built a more permanent solution by removing the old 4 pin connector and replacing it with a 5 pin header. There is no hole for the fifth pin, so I cut the pin short (making sure it couldn't touch the ground pad under it) and soldered the 4 other pins. The fifth pin was then connected with a bodge wire over the to resistor. To support the unsoldered fifth pin mechanically, cyanoacrylate glue was added to attach it more securely to the pin header frame as well as the neighboring pins.

A more permanent solution.

The speedup of using SWO instead of semihosting is considerable. In the plots below there is an example of quasicontinuous I2C communication, where some tracing messages are periodically sent to the debug host. The channels 0 and 1 are the I2C lines, while channel 2 is connected to a "data ready" IRQ pin of the I2C device. Channel 3, which is only shown in the latter figure, is the actual SWO data.

It is clear from the figure below that when the semihosting mechanism is used for message transmission there is a period of more than 30 ms where the microcontroller is not capable of responding to the IRQ. When the execution continues, the first few I2C transfers are considerably longer than typical, as unread data is read out from the FIFO of the device.

Logic analyzer view of I2C communication with semihosting tracing messages.

When tracing is sent through SWO, on the other hand, there is no noticable change in the I2C communication in this example. In fact, the time required to respond to the interrupt doesn't change by a measurable amount, nor can I see any other change in the timing.

Logic analyzer view of I2C communication with SWO tracing messages.