Electronics > Open Source Hardware

JTAGulator self-build PCB

<< < (4/4)


--- Quote from: WaveyDipole on April 11, 2023, 01:33:44 pm ---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: ---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.


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.


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

--- End code ---

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.

--- End quote ---

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) ,


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.

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


--- Quote from: dietert1 on April 13, 2023, 08:29:16 pm ---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

--- End quote ---

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.

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?


[0] Message Index

[*] Previous page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod