JTAGulator self-build PCB

[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 
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

[artag]

I used the TX104 level translaters on i2c and was unimpressed - they seemed very inclined to false-trigger on noise. It's possible the 108s are the same. Do everything you can to ensure they don't see a reflection on output signals. They do have capacitors near them but check they're good as darkspr1te says - maybe change them for some known fast capacitors if they were junkbox parts. Use good local grounds and short wires etc.

[WaveyDipole]

I tried an experiment which involved removing the MIC2025 chip and bridging pins 6 and 7 with solder to connect VUSB in directly to the 5V rail. This bypasses input protection and connects the USB 5V rail directly to the regulator and therefore to the JTAGulator MCU and its components. Checking on the scope, I found that the transient blip had mostly disappeared from the supply rail. There is still noise on the USB supply, but with only a few 10s of millivolts fluctuation that is barely discernable at 1v/div and at a different frequency period. The 40kHz blip seemed to be being caused by the MIC2025 IC. I don't have a spare so if I can get the board working properly, I will have to order a rerplacement.

With the PSU rail protection/switching bypassed, the JTAGulator scan results seemed more stable in that the JTAG pin identification and the ID code being read each time was the same, but still the ID code was still incorrect. I tried both the Rigol scope and a Raspberry Pi. It should read the correct ID code from the latter at least without any difficulty. I could still not get anything via SWD from the Pico either. The problem runs deeper than just instability of the the supply rail.

I tried another experiment using the GPIO feature and pulling each pin low in turn. This worked just fine, correctly pulling each pin to logic 0 in turn. There were no anomalies that might indicate a short or adjacent pins affecting their neighbour, at least in manual slow mode!

I haven't tried an older firmware yet, as I haven't found one. The 'Releases' tab in GitHub mentioned by Joe in his video seems to be missing for me.

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.

Well its good to know that everything at least seems to look OK. If you are referring to the 'slides' file, I totally missed that! Thanks for the suggestion. I will definitely have a look at it.

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,

Yes, with the exception of what you say about devices behind nda's, that's about as much as I have learned so far about openocd. I am still very much a newbie to it. The first step was to identify the JTAG pinout and then extracting the ID code to identify the device, which why I got interested in JTAGenum and JTAGulator. Once done, then its a case of connecting up whatever interface one has available, and using the appropriate .cfg files for the interface being used (Olimex, BusBlaster, FTDI etc) and for the device being accessed from the openocd library.

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) 

Sadly, j-link is beyond my means as a hobbyist, but I did have a look at the ur-jtag documentation. It seems that it is compatible with my Olimex interface so I will download and experiment with this software.

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.

I did test UART passthrough when I finished building the JTAGulator and it worked just fine, although only one pair of pins was tested. Systematically testing the other pins sounds like a plan. It will take some time but I try this and see what results I get.

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 
but you could spread it by testing a different stage on each of the 3 groups.

Sounds like another excellent suggestion if I find no problems with the UART pass-through. Both the Pi and the Rigol are 3.3V devices, so should be find to experiment with for this purpose. Given that this process will involve a bit of messing around with reworking the board, I would like to try alternative firmware and the UART pass-though tests first.

I used the TX104 level translaters on i2c and was unimpressed - they seemed very inclined to false-trigger on noise. It's possible the 108s are the same. Do everything you can to ensure they don't see a reflection on output signals. They do have capacitors near them but check they're good as darkspr1te says - maybe change them for some known fast capacitors if they were junkbox parts. Use good local grounds and short wires etc.

Artag, thanks. Useful to have this info. The only junkbox parts I used were the reset switch and LED. The capacitors were brand new from DigiKey as specified on the JTAGulator BOM list so all things being equal I would expect them to be fine, although anything is possible. Point taken about cables. Although I am using a BusPirate cable as suggested by Joe, I do have some shorter DuPont wires I could use.

[WaveyDipole]

I just spend a while testing UART using every pair of pins on the JTAGulator. The simple test consisted of connecting each pair of pins to the UART pins on an RPi 2b running at 115200 baud, logging in, checking that the login banner consisting of several lines of text was not corrupt and echoing a string of 80 or so characters using the echo command. This was repeated for each pair of JTAGulator pins starting at 0+1 and ending on 22+23. There were no problems seen. All data was sent and received without any corruption using each pair.

I then tried some tests using random pins and ran into some interesting effects:

Using pin 10+15 resulted in the JTAGulator reporting back something pin 15+11 at 1200 baud in addition to the usual output for pins 15+10. When using passthrough, I had to manually override the automatically stored pin 11 with pin 10, but passthrough worked.

Similarly, then using pins 17+21, the JTAGulator reported back on pins 18 and 19 as well as 17. However, a usable connection could only be established on 17 and 21 as expected.

I have no idea whether this is normal detection operation or cross-talk between channels. JTAG, or course, works at much higher clock rates. The next step, I think, is to see what's going on at the pins using the oscilloscope.

Here is another fun fact. Thinking about the point mentioned earlier as to whether the same result is obtained on each group of pins (connectors P7, P8, P9), I connected up the Pi to each group of pint (P7, P8 and P9) in turn with wires connected in the same order on each group. I got the same but seemingly incorrect ID code of 0xFC300037 (should be 0x4ba00477) read back on each group of pins. How can that be? If this was down to hardware (e.g. TX108s) then shouldn't I expect to get different and random results on each group? Either that or the same correct result if all is functioning correctly. Detailed results in the attachment.

This starts to point to a common denominator which would seem to lead back to the Parallax chip and firmware. I ruled out the firmware by trying a much earlier version (1.5) which gave me the same wrong result. On the other hand, the Parallax chip uses different GPIO ports for each group of pins. I buzzed out the connections and everything seems to match the circuit diagram so I am a bit puzzled.

[darkspr1te]

Ok, I dug out a "diy'ed" jtagulator i built a while ago as this latest behavior was similar.

While mine does not use the propeller chip , the code is based on that and ported to stm32f417 , I have the same results on mine if i dont tie the unused lines to ground, i was only provided a hex file for this design so i never had the source code but the idea was it would test pull up/pull down and hi-z but the latter (which is the normal method of checking as pull up is provided by the level convert in theory) but in my haste i got a clone stm32f417 which was not 100% assembled right, one pin only was lifted above the board and had no solder, this was the vdd in for the chips pull up circuit and the result is pull up will float (there parasitic draw from nearby transistors) and hi-z wont function at all as it needs the vdd input to actually switch, 

So what am saying here is two possible ideas to test, first one is tie unsed lines high or low and test again (uart or jtag) , two is maybe reflow the mcu it's quite possible you maybe have a under chip short and a little application of flux/wick and heat should be done.

My way on confirming the two above failures was first I would always get better results if unused lines were tied to a set level, also when i created a led board to sap the jtag lines and give me visuals there was no current available so the leds never lit (they would btw if i reversed the connection and put the led vcc on the pin and the led vdd direct to 3.3v, another clue)  , this told me there was a vdd missing (data sheet points this out too) ,
I see from the schema that 8,18,30,40 are vdd and 5,17,27,39 are vss so worth just checking they are well bonded. It's too hard to tell from the uploaded photo's with the size limits in place.
Looking at online images and the pin layout shows the usual VDD/VSS per gpio bank so chances are that all 4 groups are not soldered is doubtful but worth checking anyway, the stm32 are a little different in that one specific vdd/vss pair of pins deals with pull up/down etc but i could be wrong and the propeller is the same.


darkspr1te
 

[WaveyDipole]

Thank you for your time and trouble.

Upon your advice I reflowed the P8X32A using a bit of flux and heat as suggested. I kept the heat on long enough to observe the solder to melt and pool but no longer than that. It did make the soldering look rather neater than the original drag soldering. I also did the same for the TXS0181s.

I then tested all connections, including all P8X32A GND pins to GND, P8X32A VCC pins to VCC, P8X32A GPIO pins to the TXS0108s, TXS0108s to resistor arrays and 1k to output pins. I also checked that the clock was actually running at 5MHz (it was) and there were no shorts from GND or VCC to any of the other pins. I also checked the LED connections and the ADC connection. I found no broken or shorted connections anywhere. Under the chip there is a large coated area connected to GND. There are also 3 vias with tracks running to adjacent pins. I checked to make sure that the connected pins are not shorted to GND or adjacent pins and found no problems. I ran through the entire JTAGulator test procedure again all tests passed.

At various stages I tried probing the JTAG pins on the RPi with grounding and driving high (3.3V) the single unused pin in the group as suggested. Unfortunately the result has remained unchanged throughout.

Incidentally did you mean for all GPIO pins to be grounded or just the active group?

I am starting to move towards a faulty P8X32A. However, all GPIO pins can be addressed correctly. Other functions such as LEDs and VADJ seem to be working correctly. Any problems with registers would presumably have resulted in the program not being flashed or loaded from memory correctly. All of this seems to argue against the P8X32A being faulty. Still, except for maybe bypassing one of the TXS0108 chips, I am out of ideas at this stage.

I have noticed that the TXS0108 chips are actually marked YF08E. Searching that code returns results for the TXS0108E and also a link to a datasheet for the YF08E. Opening the latter displays a datasheet for the TXS0108E so I hopefully this is only alternative SMD nomenclature for the TXS0108E?

I hooked up the oscilloscope to the TCK, TMS, TDI and TDO pins as shown in Joe's PDF but the IDCODE scan looks a bit different. The output shown on TDO does not look right.

[darkspr1te]

Thank you for your time and trouble.

Upon your advice I reflowed the P8X32A using a bit of flux and heat as suggested. I kept the heat on long enough to observe the solder to melt and pool but no longer than that. It did make the soldering look rather neater than the original drag soldering. I also did the same for the TXS0181s.

I then tested all connections, including all P8X32A GND pins to GND, P8X32A VCC pins to VCC, P8X32A GPIO pins to the TXS0108s, TXS0108s to resistor arrays and 1k to output pins. I also checked that the clock was actually running at 5MHz (it was) and there were no shorts from GND or VCC to any of the other pins. I also checked the LED connections and the ADC connection. I found no broken or shorted connections anywhere. Under the chip there is a large coated area connected to GND. There are also 3 vias with tracks running to adjacent pins. I checked to make sure that the connected pins are not shorted to GND or adjacent pins and found no problems. I ran through the entire JTAGulator test procedure again all tests passed.

At various stages I tried probing the JTAG pins on the RPi with grounding and driving high (3.3V) the single unused pin in the group as suggested. Unfortunately the result has remained unchanged throughout.

Incidentally did you mean for all GPIO pins to be grounded or just the active group?

I am starting to move towards a faulty P8X32A. However, all GPIO pins can be addressed correctly. Other functions such as LEDs and VADJ seem to be working correctly. Any problems with registers would presumably have resulted in the program not being flashed or loaded from memory correctly. All of this seems to argue against the P8X32A being faulty. Still, except for maybe bypassing one of the TXS0108 chips, I am out of ideas at this stage.

I have noticed that the TXS0108 chips are actually marked YF08E. Searching that code returns results for the TXS0108E and also a link to a datasheet for the YF08E. Opening the latter displays a datasheet for the TXS0108E so I hopefully this is only alternative SMD nomenclature for the TXS0108E?

I hooked up the oscilloscope to the TCK, TMS, TDI and TDO pins as shown in Joe's PDF but the IDCODE scan looks a bit different. The output shown on TDO does not look right.

When i Look at this picture my brain says to me that (A)TMS is behaving like TDO, (A)TDI is behaving like TMS and (A)TMS is behaving like TDI  with only TCK behaving like it should , well kinda , it look's inverted compared to what i'am used to too, the pulse on is shorter than pulse off and that differs from my experience.

I will have to setup my scope on jtag , i have enough lying around lol

darkspr1te

[darkspr1te]

Btw, have you read this thread, they cover a lot of your issues and also on the main site is a problems/mods sections that also cover issues with the level converters and resistor loads. well worth a read of both.
 
https://github.com/grandideastudio/jtagulator/issues/3


darkspr1te

[dietert1]

The propeller crystal oscillator looks unusual. In the schematic the two caps for phase inversion are missing. The caps may be on-chip though.
If the two UART lines between the FTDI USB interface and the MCU had two resistors in series, e.g. 220R, you could check for contention using a scope. The resistors would already provide a little protection.
A shunt for measuring MCU supply current would be nice, too. According to the propeller datasheet its current consumption may easily exceed the 50 mA current capability of the FT232 internal 3.3 V regulator. Depends on what it does. One should also look at USB suspend and sleep modes. I think the 5 V and Vadj get disabled, but the MCU remains on. Difficult to say whether the design is complete.

Regards, Dieter

[WaveyDipole]

Btw, have you read this thread, they cover a lot of your issues and also on the main site is a problems/mods sections that also cover issues with the level converters and resistor loads. well worth a read of both.
 
https://github.com/grandideastudio/jtagulator/issues/3


darkspr1te

Yes, I have seen that discussion. One of the posts also mentions that the wrong results were obtained from a Pi 4. I have seen Joe's revision information which involves changing the resistor array and/or bypassing the TXS0108s, the latter of which I am not too keen to do. I added a pair of 10Ω resistors across a couple of the channels in order to get SWD detection to work but it made no difference. Joe confirmed that the JTAGulator does detect a Pico via SWD so I should have been able to replicate his result with lower value resistors, but it didn't work with this board. I could tack on another few 10Ω resistors to also heck whether it makes a difference to detecting JTAG pinout, but since it made no difference to SWD, I am doubtful that it would make a difference to JTAG. Still, it couldn't 't hurt to try. A further option would be to do some bypass surgery on one of the TXS0108/YF08s to see whether that make a difference. That would be rather more tricky though.

The propeller crystal oscillator looks unusual. In the schematic the two caps for phase inversion are missing. The caps may be on-chip though.
If the two UART lines between the FTDI USB interface and the MCU had two resistors in series, e.g. 220R, you could check for contention using a scope. The resistors would already provide a little protection.
A shunt for measuring MCU supply current would be nice, too. According to the propeller datasheet its current consumption may easily exceed the 50 mA current capability of the FT232 internal 3.3 V regulator. Depends on what it does. One should also look at USB suspend and sleep modes. I think the 5 V and Vadj get disabled, but the MCU remains on. Difficult to say whether the design is complete.

Regards, Dieter

Dieter, thanks. The power to the MCU is derived directly from the on-board A1117/LD33 regulator. However, the 5V rail to the regulator is switched via the MIC2025 which I have bypassed for now. I cannot get a reliable measurement of current draw using those cheap USB gizmos as they don't show current below around 100mA and even then are not that accurate. I could do with a better tool for USB power measurements. I did try but the current level does not register even with a serial session open. That's a reasonable indication that the total current draw is probably less 100mA but that's about all I can determine.

With regards to the oscillator, I had a look at the datasheet. The example connections diagram shows only the crystal connected to pins 30/31. There is a comment in the pin description table above this stating with regards to XI/XO pins: 'No external resistors or capacitors are required.' Possibly they exist on the chip but it does not appear to be explicitly stated. Evidently the designer chose to leave them out.

[WaveyDipole]

Well, well, well! It seems changing the resistors does make a difference!

I had already tacked on two 10Ωresistors across the last two channels to test SWD, but hadn't got around to doing so on any of the other channels. So following your reminder about Joe's modification, today I tacked on 10Ω resistors across the remaining channels of the resistor array for group 3 (P9), CH16-CH21 and tried JTAGulating the Pi again. This time it did return the correct ID code:

Code: [Select]

JTAG> j
Enter starting channel [0]: 16
Enter ending channel [16]: 23
Possible permutations: 1680

Bring channels LOW before each permutation? [y/N]:
Press spacebar to begin (any other key to abort)...
JTAGulating! Press any key to abort...

TDI: 16
TDO: 18
TCK: 17
TMS: 21
Device ID #1: 0100 1011101000000000 01000111011 1 (0x4BA00477)
TRST#: 20

---
JTAG scan complete.

JTAG>


JTAG> d
TDI not needed to retrieve Device ID.

Enter TDO pin [18]:
Enter TCK pin [17]:
Enter TMS pin [21]:

Device ID #1: 0100 1011101000000000 01000111011 1 (0x4BA00477)
-> Manufacturer ID: 0x23B
-> Part Number: 0xBA00
-> Version: 0x4

IDCODE listing complete.

JTAG>


JTAG> t
Enter TDI pin [16]:
Enter TDO pin [18]:
Enter TCK pin [17]:
Enter TMS pin [21]:
Number of devices detected: 1
Pattern in to TDI:    11111100011101011010001111010001
Pattern out from TDO: 11111100011101011010001111010001
Match!

JTAG>
I had expected JTAGulating the Pi to just work given how ubiquitous it is, but evidently, the modification proposed by Joe is required to solve the problem for the RPi v2b that I am using. I then also tried JTAGulating the Rigol 1054Z again and found that I now get the correct ID code for the ARM MCU as well. I also tried JTAGulating the second JTAG port on the Rigol that previously returned 'No target device(s) found!' and it now returns an ID of 0x24004093 which the ID code for the Xilinx XC6SLX25 FPGA and corroborates the result from JTAGenum. I will be ordering replacement 10Ω as well as 100Ω resistor arrays to test. This is something of a relief as it means that the effort I put into building this project has not been wasted after all!

Now that I had 10Ω resistors on CH16 thru CH23, I was able to test SWD detection of the Pico using different channels in the range for that group, but unfortunately with no result.

Partial success then. JTAG detection works with the resistor modification, but SWD detection still fails.

Incidentally, I was considering purchasing an official JTAGulator pink board from Parallax while they are on offer as I thought having a known working board for comparison would be useful, but had reservations because there is no way to know whether it would behave any differently given the devices I am testing. I don't really need two JTAGulators and since I now know that the one I built can be made to work with Joe's modification, it is perhaps no longer necessary to buy another. However, I am still troubled by SWD not working especially since Joe presented proof that it should work. Then again there are other tools such as the BusBlaster that might also be useful to add to the toolkit. I will have to give it some more thought.

[darkspr1te]

Well, well, well! It seems changing the resistors does make a difference!

I had already tacked on two 10Ωresistors across the last two channels to test SWD, but hadn't got around to doing so on any of the other channels. So following your reminder about Joe's modification, today I tacked on 10Ω resistors across the remaining channels of the resistor array for group 3 (P9), CH16-CH21 and tried JTAGulating the Pi again. This time it did return the correct ID code:

Code: [Select]

JTAG> j
Enter starting channel [0]: 16
Enter ending channel [16]: 23
Possible permutations: 1680

Bring channels LOW before each permutation? [y/N]:
Press spacebar to begin (any other key to abort)...
JTAGulating! Press any key to abort...

TDI: 16
TDO: 18
TCK: 17
TMS: 21
Device ID #1: 0100 1011101000000000 01000111011 1 (0x4BA00477)
TRST#: 20

---
JTAG scan complete.

JTAG>


JTAG> d
TDI not needed to retrieve Device ID.

Enter TDO pin [18]:
Enter TCK pin [17]:
Enter TMS pin [21]:

Device ID #1: 0100 1011101000000000 01000111011 1 (0x4BA00477)
-> Manufacturer ID: 0x23B
-> Part Number: 0xBA00
-> Version: 0x4

IDCODE listing complete.

JTAG>


JTAG> t
Enter TDI pin [16]:
Enter TDO pin [18]:
Enter TCK pin [17]:
Enter TMS pin [21]:
Number of devices detected: 1
Pattern in to TDI:    11111100011101011010001111010001
Pattern out from TDO: 11111100011101011010001111010001
Match!

JTAG>
I had expected JTAGulating the Pi to just work given how ubiquitous it is, but evidently, the modification proposed by Joe is required to solve the problem for the RPi v2b that I am using. I then also tried JTAGulating the Rigol 1054Z again and found that I now get the correct ID code for the ARM MCU as well. I also tried JTAGulating the second JTAG port on the Rigol that previously returned 'No target device(s) found!' and it now returns an ID of 0x24004093 which the ID code for the Xilinx XC6SLX25 FPGA and corroborates the result from JTAGenum. I will be ordering replacement 10Ω as well as 100Ω resistor arrays to test. This is something of a relief as it means that the effort I put into building this project has not been wasted after all!

Now that I had 10Ω resistors on CH16 thru CH23, I was able to test SWD detection of the Pico using different channels in the range for that group, but unfortunately with no result.

Partial success then. JTAG detection works with the resistor modification, but SWD detection still fails.

Incidentally, I was considering purchasing an official JTAGulator pink board from Parallax while they are on offer as I thought having a known working board for comparison would be useful, but had reservations because there is no way to know whether it would behave any differently given the devices I am testing. I don't really need two JTAGulators and since I now know that the one I built can be made to work with Joe's modification, it is perhaps no longer necessary to buy another. However, I am still troubled by SWD not working especially since Joe presented proof that it should work. Then again there are other tools such as the BusBlaster that might also be useful to add to the toolkit. I will have to give it some more thought.

Thats good news, but it was something i suspected but could not get across right, i could see the charge voltage was right for the first few databits on TDO then faded, same as i saw on ALDL device  , transistor hyristysis , I had this issue designing a ALDL interface , my choice of pull up/downs ment my signal was sketchy for gpio to register via the transistor so input influx on voltage reflected in that tiny minor flux on the register.   discussion on on suzuki uk forums and covers it, just use username grimreefer topic ALDL
What i advise forward is you choose different resistor value for different bank as a common (10ohm bank 1, 100 bank 2, 4.7k bank 3(via 3.3v pull up ) , i tend to find most jtagble device can be spotted and only require four target pins, unless you looking and a "no-jtag connector at all"  would i want more than 4 pins to work out , that being said there no reason to you cant remove the resistors and have daughter board having that so you can swap out the entire board , but the basic is does the device have the grunt to throw that current/voltage to GND or pull up to vcc/vdd.

technically this is how the bus pirate and bus blaster can work via the switches within the pic + level converter chosen on bus pirate and the older cpld of the busblaster which via a adv switch does auto 5/3.3/3v conversion as additional logic (demon core addition) ,


 
 darkspr1te

[WaveyDipole]

After having looked at Joe's modification, I had thought about setting each bank with a different resistor array, e.g. 10Ω, 100Ω and the default 1kΩ. Joe also agreed that was a sensible approach, so I think there is consensus regarding that strategy. Given my experience here with the Pi and Rigol, part of me did wonder whether 1kΩ is actually too high and therefore 100Ω would be more suitable, but having a 1kΩ array one one bank does provide a higher voltage tolerance which might be useful. I am curious, however, as to why you suggest 4.7kΩ?

The 100Ω arrays arrived today, so I swapped the original centre array for one of the new 100Ω arrays. Bank 2 now works on both the Rigol and Pi. However, on the Pi, all pins must be driven to a known state as you suggested earlier, by grounding them. With 10Ω I can get away with grounding just one of the spare pins but with 100Ω I have to ground both. With the Rigol it didn't seem to matter. This seems to be true even if e.g. channel 8 is provided as a starting point and 13 as the finishing point to the J command. The remaining channels in the bank (channels 14 and 15) still need to be grounded for the ID code to be returned successfully, otherwise it just returns 0xFC1C0873 as before. Why would pins within the bank that are NOT specified for the J command to use for scanning and therefore theoretically no longer relevant to the scan process, still need to be grounded?

The other odd thing is that this only works if the two spare pins are connected to GND pins on the Pi. It does not work when the spare wires are connected to the GND pins on the JTAGulator. This seems rather strange since connecting the GND pin on the bank to a GND on the Pi should establish a common ground. I measured 0.6Ω between Pi GND and JTAGulator GND, which includes approximately 0.3Ω DMM lead resistance. Why would that 0.6Ω make a difference?

I haven't had a chance to read the thread on Suzuki forum yet, but hopefully will get around to it later or tomorrow. Thanks for the reference.

[dietert1]

Special Gnd requirements are normal for digital communication. The connection cable for a JTAG interface that is to run at MHz frequencies should be twisted pairs (Gnd + one signal) or a flat cable with a Gnd wire between any two signal wires. Otherwise there will be crosstalk.
What is necessary also depends on cable length. A JTAG and SWD cable should not have more than 20 cm. The shorter the better.

Regards, Dieter

[WaveyDipole]

Special Gnd requirements are normal for digital communication. The connection cable for a JTAG interface that is to run at MHz frequencies should be twisted pairs (Gnd + one signal) or a flat cable with a Gnd wire between any two signal wires. Otherwise there will be crosstalk.
What is necessary also depends on cable length. A JTAG and SWD cable should not have more than 20 cm. The shorter the better.

Regards, Dieter

That is a point. Better high frequency LA probes often have shielded or twisted pair wires. The busblaster cable I am using is just a ribbon with no particular consideration for grounding - no shielding or ground wires between signal wires - unless manually connected up in that way. The cable is around 30cm long, so around 50% longer than the 20cm you mention. Repeating the same test with shorter, 20cm Dupont wires yielded reliable results on both the 10Ω and 100Ω banks with only the single designated GND pin connected, even with spare pins left unconnected. Evidently that the extra 10cm does make a difference so I shortened the buspirate cable to just under 20cm and it now works the same as the 20cm Dupont cables. Obviously I have still taken onboard the point made earlier that it is recommended to drive the remaining pins to a known state (e.g. GND).

Unfortunately SWD still stubbornly refuses to work so I'm not sure what's going on there.

[DarkMode]

Interesting, I purchased a JTAG (usb) version for programming the esp32's I have.
It worked fine.
I must admit that I paid about $35 USD for it.
Is there special JTAG's that I don't know about that are costing $200?