JTAG to SWD Converter

Readers: If you'd like to build the project featured in today's post, please go to PCBWAY's Community pages--gerber file, KiCAD files and a B.O.M. are here.  

You can also help out this site immensely by checking out PCBWAY using the link here. Thanks!

===== 

Hello again:

Another simple one!  

I use GDB to debug C based embedded system projects--I currently use a Segger J-Link EDU debugger with a JTAG interface:

Segger J-link EDU Mini

But! The development board I am currently debugging is a Raspberry Pi PICO that has an SWD interface:

JTAG is not difficult to turn into SWD, it's a "connect this pin to that pin" challenge.

However I got tired of fiddling with tiny fragile adapter cables so I whipped up a simple JTAG to SWD PCB; the focus of this post.

 

REQUIREMENTS

The J-Link EDU Mini's JTAG interface uses a 2x5 pin 50 mil pin header--1.27mm --extremely small--conforming to the "Coresight 10" JTAG pin specification. 

The Pico uses 3 x 100mil SWD pins for SWCLK, SWDIO (data), and ground:

The Segger J-Link EDU board, unlike Segger's more expensive debuggers, requires a 5V reference....there were may ways I could have gotten 5 volts to the adapter PCB, from a USB cable for instance? Or a battery? 

However I used wirepads and 22 gauge solid wire and connected a bench power supply for 5V; I may rethink this design choice down the road. 

DESIGN AND LAYOUT

Simplicity itself....took me maybe an hour to lay out the PCB in KICAD, very little thought went into design, perhaps it shows?

Did a very quick 3D check in KICAD....good enough--sure. Off the gerbers went to PCBWAY.

BUILDING/TESTING:

PCB's are back! Happiness is new PCB's from this blog's sponsor, PCBWAY. Please help this blog by checking them out.

Easy build. The SMD JTAG 2x5 connector was pretty small but I managed to solder it without needing my microscope.

For the Pico I used a 3 pin JST connector:

The more JST connectors I use the happier I get, they are inexpensive and extremely reliable. You can get them for next to nothing from Tayda.

To test I coded a simple C proof of concept program: "PrintRTT", which used the adapter board to bring printf() statements from the PICO to a Segger J-Link and then to my Linux system. 

Wired it up:

Pico needs power as well--use USB and/or 6V-9V and GND to pins 39 and 38. 

Worked--I dragged the UF2 file to my Pico and ran the Segger "JlinkRTTViewerExe" terminal app on my Linux virtual machine..

You can get the code from Github here. 

Instructions for using the Segger printf() overload and the Segger RTT app are covered in latter half of the post here and the Segger page here.

Adapter with a "stock" Pico....the red and black gator wires are 5V and GND from a bench power supply, needed to provide the JLINK with its 5V reference.

And to debug the rotary encoder experimenter's board....

The adapter board was a piece of cake and worked first time. Viola! No more fiddling with tiny fragile SWD cabling. 

I had a few ideas for improvements: clarifying the silkscreens and adding more diode protection.

But for now it's time to move on.  

I remain extremely happy with the Segger J-link Mini EDU. There are other PICO/RP2040 GDB debug options  (DIY "PicoProbe" and the offering here) but to me the Segger offers a good mix of simplicity, value, and useful software tools for a Linux-based toolchain.  

That said....I'm feeling a little tired of crafting embedded RP2040 projects and might fabricate a few analog EFM based circuits (will it work? it effectively frigging might?) in the next few weeks, a distraction.

And some analog design.  

Wait, analog? Math, breadboards, smoked parts. Sure, why not? Until then: don't breathe the fumes! 

 

Rotary Encoder Expermenter's Board: Improving the Hardware

Quick one this time....I have posted a few projects lately that incorporated a Raspberry Pi Pico, rotary encoder, and .96" OLED: here, here, and here. To make it unnecessary to breadboard the hardware, I posted an "experimenters board"--a development board to enhance a RP Pico that adds a rotary encoder, an OLED, a buffered GPIO output, and other enhancements.

Just now I updated the KICAD and Gerber files on the PCBWAY community site salient to the posts: go here.

The 9-29-24 revision of the experimenter's board uses less components, incorporates the encoder debounce library here, superseding the less responsive CD4011 based hardware debounce discussed here. 

Good news: it all works.

Thanks to Wendy and the gang and PCBWAY for patiently providing revised me with PCB's. You can help this blog by checking 'em out. 

9-29-24 revision

To make sure the grounding issues I saw with earlier revisions was a function the PCB's layout, not the schematic nor code, I breadboarded the entire "dev board for a dev board":

The breadboard example worked every time, but some of the older experimenters PCB's didn't, so, for versions of the board prior to 9-29-24, I felt I proved that this was a hardware/PCB layout issue.

I thought trace layouts for low frequency audio wasn't terribly important--put things almost anywhere, thrown in whatever traces you want--it will work--we are the bottom feeders?

Wrong. Apparently the I2C traces (at the very least) needed to be treated with forethought. probably any digital traces? 

Previously: more narrow traces....no ground pour

9-29-24 design improves that. 

I found myself putting the 9-29-24 assembly on hold for a couple of weeks, partially because I was tired of revising the board, and also having a feeling (incorrect, fortunately) that the 9-29-24 revisions would make things less reliable, not more.

Word of caution: 1306 128x64 .96 OLED's are everywhere but there appear to be 2 different pinouts coming from Shenzen: GND far left, and VCC far left.  

My design requires VCC on the far left--make sure you get that style of OLED if you build this project.

Spinning the rotary encoder advances or diminishes the counter on the OLED as expected. Every time, without fail. Thank goodness.  

Next: I have augment the code to create a user interface for the frequency counter....yes, I will get to that someday, but it means a lot of code changes.  

For now it's back to my day job--for better or worse the Pandemic is over.