Proper Usage #4
Comments
|
Supposedly (I'm saying this because I've only looked briefly at the usermanual) you have to "Switch the POWER SELECT switch to the right for Debug mode" according to page 14 of usermanual. Apart from that I'm still trying to understand how this processor and evaluation kit multiplex the JTAG with SWD (aka SWJ) on this "ICDI" port. Page 20 of usermanual (link above) suggest that for the U1-A processor the JTAG pins are:
Yet none of those show up in the pin diagram you sent. But further, on page 22 we see that for the processor U2-A it's JTAG pins connect directly to U1-A, in a manner that doesnt appear to indicate a chained setup through (where tdi and tdo's connected in a manner that allows to exist in a chain). So I'm not sure how JTAG is configured here. I'd be happy to purchase a couple of these boards and try to resolve the issue but I'm not sure the arduino-ish firmware of the board supports JTAG? Yet, you say that JTAGulator finds JTAG, which is interesting. So perhaps I'm really missing some detail |
|
Unfortunately, I can't find a pinout diagram that actually labels the JTAG pinout. If you look at the board pinout picture you can clearly see the JTAG interface. In the TM4C123GH6PM Microcontroller Data Sheet page 201 you can see the JTAG pinout values as well as additional JTAG information. TCK - Pin 52 (PC0) I can attach some screenshots of output from the JTAGulator if you would like that to verify what I said. When I just looked at the board I was using as a target I was in fact using the debug USB power. To give additional information, I had another 3.3V target board that I used with both JTAGulator and this project and JTAGulator was able to find JTAG whereas this was not. However, as this was an unknown target board I decided to verify the JTAGenum code using these known boards. Hope I can help figure this out. |
|
Ah! Thanks for pointing out the labels. Didn't notice them at first. I seem to have chased a rabit down a hole: I tried to visually trace the labeled pins to the pins in the datasheet you linked to but they don't line up. Tracing of TMS TDO and TDI can be done visually from the first pin map image you linked to. It appears those JTAG lines connect to pins 20 21 and 22. I couldn't find a datasheet for the LX4F120 chip shown in the pin map image but assume the map is the same as for the TM4C123GH6PM page 1328 indicates pins 20 21 and 22 are PA3 PA4 and PA5. These don't clearly indicate JTAG/SWD/SWJ functionality. And as you pointed out in page 201, and page 1328, JTAG is indicated on pins 49-52. Okay, I'll assume that maybe the traces in the pin map image really depend on LX4F120, and that for the TM4C123GH6PM the traces will show up visually different and into the correct pins. Obviously if the pins you are connecting to indicate JTAG and they don't show up in a scan, the problem is on the JTAGEnum side. Do you have a board with a TM4C123GH6PM or LX4F120 chips? thinking... |
|
Okay, a small step backward: Could we consider the voltage of the target and the JTAGenum testing microcontroller? One of the things JTAGulator does great, if I remember correctly, is handle differing target voltages. Whereas JTAGenum's microcontroller and the Target need to be operating at the same voltage on GPIO's/pins. Could it be that the evaluation kit running JTAGenum is using 5v for GPIO pins while the target is at 3.3v? |
|
In my most basic test setup which I outlined in my first post I was using one EK-TM4C123GXL (oops I put EX in my first post) board to test JTAG on the other. I'm pretty sure they were operating at the same voltage as I did nothing to configure them differently. This board seems to have the TM4C123GH6PM chip. Let me know what other information I can provide for you! |
|
There is a slight chance that JTAG IO could operate at a different voltage than digital IO pins, but, probably they are the same. I'm sorry I can't look into this in detail at the moment :( I've ordered two of the boards though and hopefully I'll get a chance to try out this test over the holidays |
|
Really cool of you to order the boards! I look forward to your test results whenever you get around to it :) |
|
Okay almost a year later :/ could you by chance give me the energia board package for the TivaC boards? It fails to download. download source returns 404 which I reported (robertinant/EnergiaNG#45). Tried to also wedge the tivac-core package from Energia (https://github.com/energia/tivac-core) into the IDE by putting it in the location mentioned in http://energia.nu/guide/boards/ or just next to the existing msp430 package it ships with in the src directory of the app). Perhaps you could check where tivac is on your system and send me the files? |
|
Hey dude. I made a fork https://github.com/Brumstar/JTAGenum. You will see that in the top level there is a file |
|
thanks for that. Yes so now I appear to have some issue with the underlying arm compiler I'm using |
|
Okay resolve that (had to re-install |
|
So I'm not seeing the same results, no JTAG detected. I will try to use this on another target and will see where I get in the coming days. |
|
Do you mean that jtagenum was actually able to detect JTAG on the interface? Or was it not able to? My original results were that jtagenum could not detect JTAG on an interface that the JTAGulator could. |
|
Sorry, yes I mistyped. I meant that I am seeing the same results. I tested running same JTAGEnum code on a Teensy and was able to detect JTAG on a new target I have. But I was unable to detect the JTAG port on the Launchpad master board, from either Launchpad or Teensy. So something is wrong and I'll look at it more as I have time. |
|
Cool thanks for clarifying! |
|
Okay just a small update. JTAGenum works on the Launchpad. I had a pin def wrong and now the JTAGenum on Launchpad finds the same target that the Teensy found. Here is the output that the Launchpad gave for my target (the target is a IMX6 chip and the ID found is correct): I'm now left wondering what the story is with the Launchpad master boards JTAG. It is an interesting question for me because there is a mountain of different peculiar JTAG implementations and perhaps this is a new one (to me) worth exploring. I dont know when I will get to looking at it. Perhaps later, perhaps not. I'm on the clock :/ |
|
Not sure how to get JTAG working on the Tiva C in general. I'm following the instructions here on page 13 with no connecting it to OpenOCD. Were you able to connect with JTAG to the target? If so I'd have a couple questions about the proper connectivity While testing JTAGenum on the Tiva C as the scanner, with another Tiva C JTAG port as the target, I found that it would detect the target falsely during a scan. So now I'm starting to wonder if the detection you found with Jtagulator is false find due to a similar reason? |
|
Scratch that, I've been able to connect to the Tiva now with a different JTAG probe (Jlink). |
|
JTAGenum on either a Teensy or Tiva C is able to find another Tiva C. Appears the problem was proper setup of or enabling of JTAG on the target Tiva C. After following the instructions on how to enable JTAG on the Tiva C from link before (page 13 here) JTAG is found. So I suspect what you were seeing with Jtagulator was a false positive that also showed up on JTAGenum as well when the target Tiva C device did not have its JTAG enabled. Here is the resulting output from one Tiva C scanning another Tiva C: photo of the setup, note that I'm using one Tiva as the target and one Tiva as the scanner. So I'm closing the bug. Happy I could test the Tiva and add it as known supported platform. If you have any further questions, or more issues, feel free to re-open or open new issues. For perpetuity sake, I'll discuss why the false positive might appear when the target JTAG is disabled, and why in the above results you see the IDCODE twice. The IDCODE shows up twice because TRST and TDI are not needed for the IDCODE scan. For the IDCODE scan to show results it assumes that the target has the IDCODE as the default Data Register (DR) between TDI and TDO at reset. The reason the scan is made this way is for two reasons. 1) I think, if my memory is correct, that the JTAG standard itself specifies that either Bypass or IDCODE will be the default DR, and 2) to set the IDCODE as the DR would require knowing the proper length of the Instruction Register (IR). IR length can differ per target so to avoid another brute force scan for IR Length JTAGenum only finds IDCODE when it is already the default DR and assumes user will use the pattern scan as well which would find devices that do not have IDCODE as default. About the false positive... the pattern scan can result in many false positives when there is a short or crosstalk between wires. This is part of why the loopback test is available. But even a loopback may not always detect potential target shorts that will only show up when the device is under stress or in different runtime states. So one will have to assume some false positives can appear. |
|
For reference, using the TI Teva C as an example target requires setting it up to provide JTAG. This is described in page 13 of this document. Summary:
|
First of all, thanks for writing this tool.
I just want to verify that I am using this tool properly in my test environment. My current setup is two TI EX-TM4C123GXL boards. One board runs the sketch, and the other board is just for the JTAG interface. This JTAG interface has been tested using the JTAGulator to make sure it functions as expected. The pinout for this board can be found here. The GPIOs of the first board are connected to the second board, with the proper pin numbers placed in the sketch.
After successfully connecting to the terminal, I run a loopback check, which gives no results. Then I run a scan, and icodescan. Still nothing. Then I do a boundary scan (mentioned to be broken, can I help fix?) and get some results:
The only one of these that was correct is TDO. Again, I saw that this was mentioned as broken so this is not surprising. However, was I supposed to be getting results for the other commands? I have tried with pullup resistors on and off, as well as the prescale define there or not. I would love to use this project as part of my pentest routine. Can you please tell me what I am doing wrong?
The text was updated successfully, but these errors were encountered: