Electronics > Open Source Hardware

JTAGulator self-build PCB

(1/4) > >>

WaveyDipole:
I have recently been doing some baremetal work and decided to purchase a JTAGulator to help me identify JTAG port pins. Since the board here in the UK costs over 200GBP (From RS), I decided to purchase a ready made PCB off eBay and the parts on the BOM list from Digikey and make the board myself. Not only would this be a useful excercise in SMD work, but also would cost around 76GBP total, saving me over over 120GBP (or so I had hoped!) on the cost of a fully assembed product. Although the JTAGulator appears cheaply from time on outlets such as Alibaba and AliExpress, I decided to avoid these since there was no way to know whether these were genuine.

I managed to assemble the board and load the firmware. I ran through all the tests, finding an unexpected solder shorts between a couple of pins on one of the Level translator chips, but one that was cleared, all tests passed successfully. However, my excitement was short-lived because the completed JTAGlator was returning erratic results. For example, it would identify pins correctly, but return the wrong chip ID. It would randomly return a different ID every time the ID was read. It wouldn't work with SWD on a Pico.

I reached out to GrandIdeaStudio and got a response from Joe Grand. Briefly, it turns out that the PCB is not an 'official' product and therefore not supported as such. Understandably, products not purchased from Parallax or their authorised distributors are not supported. Someone has simply taken the gerbers, changed the board colour and started selling the PCB on eBay. Having said that, Joe was very helpful and confirmed that the JTAGulator should work with the Pico with a slight modification but I was not able to replicate his result. Furthermore I was also puzzled by the erratic behaviour of my board when reading back chip ID codes from my Rigol 1054Z. Some of the discussion and screenshots can be referenced here.

After a little further digging, I discovered that there was noise on the GPIO pins which could be traced back all the way to the 3.3V and finally through the regulator to the 5V USB power rail. Looking at the USB power rail from the PC to which it was connected did reveal some noise, but not on the scale of what I was seeing on the JTAGulator board. Next, with the JTAGulator board plugged in and idle, there seemed to be little change. However, as soon as a connection was established via a serial terminal to the JTAGulator, the problem started up again. Suspicion then immediately fell on the FT232RL chip. The pins were examined carefully under a microsocope but no shorts or other problems found. Just to be sure, the area around the chip was cleaned again and adjacent component legs and tracks also checked but this made no difference. A replacement FT232RL has been ordered. Its possible, I suppose, that the problem could lie with the Parallax MCU, but I think that less likely.

The screenshot below shows the measurement taken from the output pin of the 3.3V regulator. Even though its a transient, a variance of almost a volt in each direction seems non-trivial so I am speculating that this could be the causing enough disruption to result in erratic readings. I am also rather curious about the 40kHz cycle of the 'blip'. The FT2323RL has an internal clock running at 12MHZ (and x4 multiplication to 48MHz) so why specifically 40kHz?

In order to get a known working sample I might end up going full circle and buying an 'official' pink JTAGulator board from Parallax. If I can get my self-build version working properly, this will be used to test Joe's modifications. In the meantime, however, I am curious whether anyone else has purchased one of these PCBs and successfully built a working JTAGulator board?

WaveyDipole:
The replacement FT232RL arrived today and I have replaced the original chip. Unfortunately, the problem persists which is very disappointing. Evidently the problem is being caused by something else but I am uncertain what to suspect: theMIC2025>? The Parallax MCU? I have attached a circuit diagram of the JTAGulator for reference.

darkspr1te:
Can you provide some pics of the assembled board ?
I would take a look at the caps for the board, even go as far as adding electrolytic caps on top of existing ceramics to see if the behavior changes,
When you run tests and get feed back (like CHIP ID) have you tried moving the pins from the current JTAGULATOR pins to the next batch (eg move from p2 to p3) and see if the results change a lot 
do you have any JTAG enabled chips that are unused or on a dev board to test ? i ask this as sometimes in production equipment the jtag port maybe be incomplete(missing pull ups)  or disabled or in the case of some broadcom chips need a code sent or it will go into random data mode and just spit out junk ( or the pins are used by the running code)

When this first came out i must admit i wanted one but the price was not quite right for me, since then i have found other tools that are cheaper and do more, a example is bus-blaster from dangerous prototypes , theres firmware out there for it that provides various jtag types like kt-link, jtagkey and more as well as jtagulator type functions.
There are also pi-pico(blueTAG) and arduino firmwares(JTAGEnum)  providing the same functions as well as glitching functions for working with more secure products.

The JTAGEnum project and it's many forks also have provided jtag finding and glitching features as well as a the chip whisperer , although the latter is pricey ($1000 plus once your buy the probes etc).

One final though also is try older/different firmware on the propeller chip, I recall a design change discussion that allowed the device to auto detect pull ups and apply if required but need the primary voltage set first (3.3v/5v) and it does kinda sound like maybe your pins are floating and thats why it "works sometimes".
I see also on the schema that there is a eeprom, i assume thats for saving settings but is there any initial data put onto it first? i have not looked at the code so i dont know if there is a required initialization or factory defaults and maybe because it's assuming the current data is right it doing some strange behavior, but thats just a idle thought.


darkspr1te
 

WaveyDipole:
darkspr1te, thank you for your post. I have attached a picture of my board.

I will give your capacitors idea a try. I don't think its a smoothing issue but it is still worth a try.

In the meantime, in answer to your question about trying different pins, I have tried all three groups and sometimes get different results on each group. For example, I get random ID codes on group one (CH0-CH7) , but none on group two (CH8-CH15) and similar random results on group three (CH16-CH23). The cable is a standard BusPirate cable, but I have also used single Dupont wires with the same result.

Before I built the JTAGulator, I used JTAGenum running on a Pico (also Leonardo with level shifters) and probed a Raspberry Pi 2B and an ESP as well as the Rigol scope. I must confess that I find the output confusing as there are several 'detected' results with different pin combinations, some of which are not even connected. It did, however, give me the correct ID code on each tested device, including the Rigol scope. I had considered a BusBlaster, but I saw no indication that it is capable of detecting the JTAG pinout. If it is, then I would certainly be willing to consider it as an alternative to JTAGulator. I haven't seen blueTAG before, but have just found the information for it, so will give it a try.

I also have an Olimex ARM-USB-OCD-H and have successfully downloaded the Rigol scope firmware using OpenOCD/gdb and probed the Raspberry Pi JTAG with it. I have also successfully probed another the Pico via SWD using the Olimex SWD adapter. I did wonder whether OpenOCD can provide JTAG/SWD detection but have so far drawn a blank on that. It would be great if the Olimex could be used for JTAG pinout detection.

darkspr1te:
Thanks for the pic , Must admit nothing stand out at me. And comparing to other images on the net all seems right.
I did notice that the creator has a pdf on his site with scope screen shots , maybe worth grabbing your rigol and doing a screen cap as well and compare the levels and signal quality at the device and at the target.
I also have the same scope and oddly enough need to jtag something soon and have actually not used that function in my scope yet so i will do so and post the shots here for comparison if you like but your have stated you do have other jtag interfaces you can scope and get needed comparisons.

The one thing i've found with openocd is that you need to know target information already and pass that onto the server when you start it, when digging into say unknown chips , router and secure device, devices behind nda's etc that become a issue. plus there also needs to be support in someway within openocd for sending the correct commands to mode switch , sending correct cpu halts etc.
I have not learned it well enough to go in blind and get results other than a id scan and thats it,
for the task of looking at these unknowns i found urjtag and my bus-blaster with j-link setup to provide me more info including boundry scans and io control, which in theory with the right scripts (again , i failed there) you can in theory bit bash flash memory and even halt cpu etc, but again further work without the mode switch commands is hard. (looking at you broadcom) 

another thing to try is the uart passthrough , again in theory you can send specific packets and do a comparison on the other end in duplex , then probe along the board with two channels to see where there is possible corruption, you can do the same with jtag really but you dont have passthrough for direct comparison, there's process involved on the data. but you could compare data at the device and data at the mcu , it should be just level shifted.

if you have a true 3.3v target then maybe bypass each stage starting direct at the mcu and adding each stage until you get errors , sadly that will involve a lot of board rework  |O
but you could spread it by testing a different stage on each of the 3 groups.

The more i think on it , I think your quickest results might be found by only connecting 4 wire to a known target and using your scope to compare the jtagulators idscan to that of another jtag interface that has the ability to just do idscan and not do other process and setup work which should save on setting up triggers on the rigol.
I know this trick to have saved me a headache once before where a coding error on my part switched 0 and 1 on a jtag interface ment it would read TDO and if high says it's low and vice versa , this was due to me using transistors as level shifters so i had forgotten to invert in the right places and not invert in others , i also had Hysteresis issues but that should not apply here, but later when i switch to actual level translators i forgot to remove the inversions in my code, again should not apply here as we are using tested firmware and are looking for possible board issue.   


darkspr1te

Navigation

[0] Message Index

[#] Next page