Rgh Jtag
Eliz Mettert
Hello,
I have come across a strange problem. It is very likely HW related based on other posts on the forums, but I cannot figure out exactly what is wrong. I have several custom boards with the C200 and a few of them are encountering this problem. What is particularly strange about this board is that it WAS working and then suddenly I have encountered this error. I've tried replacing the DSP with a fresh chip to no avail. I have also tried programming other boards with the same debugger and it works, so I know it's not the debugger nor the cable. I have tried alternative computers as well to no avail. I even tried the XDS110 which resulted in the same error. Any suggestions would be appreciated.
I was experiencing the cannot circulate bits error on another board, but I was able to solve it by changing USB ports. Unfortunately, it did not work here.
I have already gone through the JTAG debugging page here: -dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html
Here is the complete debugging message:
The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).
The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.
Without the emulator connected is the VDDIO of the MCU at 2.645V? Can you take a look at the 1.2V supply as well. I'd like to make sure these are within spec before we attempt to connect the debugger. You can also probe the XRSn pin to see if it is active low(device held in reset) or high or toggling.
I need to double check for this device, but many of our devices have an internal monitor on the VDDIO supply that will hold XRSn active until it sees close to spec on that supply pin. If VDDIO is not proper, this could be the reason you can't connect(device held in reset).
I'm trying to bring up a custom board with an iMX8mq on it. We are having issues and I was looking to use JTAG to try and see what's going on. In the past on iMX6 we have used the SEGGER j-link Base with good success, but from their website it looks like they don't support any ARMv8 cores at this time.
Although J-Link doesn't officially support any ARMv8 cores with their software, I was able to get things working with OpenOCD. Also, I got this going with the J-Link base which is the cheapest J-link adapter. Here is what I did:
I am also looking for a jtag debugger for IMX 8M Mini. I found out that SEGGER do not support Cortex A53 of the processor and that it is what I need; I need to debug a Linux project. However, I see that you were able to get that working with OpenOCD. But I have a question. Can I debug multi threads (analyze multi parallelism)?
We are facing an issue while interfacing JTAG with i.MX8MQ. We are following steps as mentioned in this post (cloned and compiled openocd) and we are able to detect the Core. However, we are not able to set the breakpoints. I have raised this post with a detailed query. Can you please have a look and provide some approaches?
Unfortunately that project with the iMX.8 has since been cancelled and I haven't done any more work with the J-LINK and ARMv8 since then. I can't remember if I got breakpoints working or not in the first place, I was using J-LINK to load U-Boot in early board bring up. Sorry I couldn't be of more help, but if you find a solution please post it here for posterity.
Hi Igor, thanks for the reply. OpenOCD paired with my existing J-Link seems to have been the answer. I'm surprised Segger doesn't officially support ARMv8 with their software considering it has been in the market more more than 5 years. Either way, I posted another answer in this thread on how to use the Segger J-link Base with OpenOCD to debug the iMX8mq.
I had posted a question earlier about help with Freedom running on a Digilent Genesys board. My team and I are trying to get a similar board up and running with Freedom and OpenOCD. We are using a minimodule to try and interface with the FPGA. When I run openocd this is the output I get from it.
We have a system reset that is constrained to a pin with a push button going into it. When I press it and reset the system we start to get more normal behavior. This is trying to use openocd after hitting the reset button.
I am stuck in this last scan, it repeats indefinitely, but I have put power on reset blocks in my design as suggested above, and map the power_on_reset signal to a pin which the debugger is connected to (maybe do we map the power_on_reset signal on a switch?). Did I do anything wrong? Thank you.
Also, to all the posters, it may be useful to ensure that you are applying proper clock constraints on your jtag_TCK input, as well as marking the jtag_TCK group as asynchronous from the coreClk/tlClock groups.
Also, quick question, I am in a little doubt with my core reset (ck_rst signal), how does it work in Arty. Known it is connected to ck_rst signal in Arty board, but in other board we might not have this signal available, is it ok to map this pin into a switch (ck is active low?) with pull up enable? Or a push button? Thanks!
I finally am able to use the Arduino IDE to do debugging using the USB JTAG built into the
ESP32s3! It's not perfect yet, still some bugs and issues. Here's a brief description. Treat it
as a series of hints. This was on a Windows 11 PC with Arduino IDE v 2.3.0. but I think Win 10 will be similar. The microprocessor board was an Adafruit QTPY esp32s3 but I think any esp32s3 using the native USB will be similar.
You'll need to dig around for details (e.g. the Zadig drivers) and your actual experience may differ from mine because of platform, OS etc.
I will not/can't help you with that, you'll have to work it out yourself. Just take heart that
it is now possible.
What appears to work for me, at least somewhat consistently is:
Make an arduino project for your esp32s3 device. Save it as usual.
Added a debug.cfg file to the project folder, and put "adapter driver esp_usb_jtag" in it. (no quotes)
Plugin your esp32s3 (not s2 as it doesn't support usb jtag interface....)
See if Windows device manager can see either a new com port or a dew device labelled as a usb jtag/serial.
If it's a pure serial com port, you might need to 'update' its driver to make it back into a usb jtag/serial unit (Use device manager, properties, browse, pick from list)
Use Zadig to update drivers for usb jtag device interfaces. Use USB Serial(CDC) on interface 0 and libusk on interface 2
(interface 2 might be hiding in the libusb devices)
Hit the icon on the IDE top bar to start debugging. This should create a launch.json file. It might fail because it can't flash the device.
Copy the debug config in launch.json and add it to the config array as a new config.
Make it "attach" rather than "launch". Give it a new name, "my config"
Restart the ide, open the debug window, make sure "my config" is selected from the dropdown.
Reset the micro to make sure a program is running on the micro (i.e that it isn't in boot mode)
hit the green triangle in the debug side window to start the debug
hit the blue triangle to run continuously, then to pause, step over etc. Set break points.
Use dark theme, high contrast to better show line number in the source code. Be careful that it actually aligned. Try putting breakpoints in.
If they don't all go where you click but appear a few lines offset, you might not be aligned.
(i.e. you changed the source code since last compiling) Don't do that. It messes up the 'where am I in the source file" indication
Stop the debugger and hit reset on the micro before trying to upload new code to it.
Restart IDE after uploading new code if the debug window buttons all disappear. (Make sure to select "my config")
Rinse and repeat.
Thanks @tcornall! Support for a more powerful and flexible system of configuring Arduino boards platforms for use with the Arduino IDE 2.x integrated sketch debugger was added in Arduino IDE 2.3.0. Although the previous system is still generally supported, the initial debugger support implementation in the "esp32" boards platform had to use a quite hacky approach in order to overcome the limitations of the previous system and that initial implementation was broken by the changes in Arduino IDE 2.3.0. This is the reason why the debugging experience with ESP32 boards in Arduino IDE 2.3.0 is currently not very user friendly.
That pull request was merged earlier today, but there hasn't been a new release of the "esp32" boards platform since that time. Since you already have found a way to proceed with the latest release versions, you are probably happy enough to carry on with that until the situation improves with the next release of the "esp32" boards platform, but for anyone else who is struggling with that I can offer two alternatives:
As I mentioned above, the ESP32 debugging experience is currently more friendly with Arduino IDE 2.2.1. You can download Arduino IDE 2.2.1 from the links listed under the "Assets" section of the 2.2.1 release page in the IDE's GitHub repository:
Arduino IDE >=2.3.0 is required for debugging boards of the "Arduino Mbed OS" boards platforms. If you want to debug those boards in addition to ESP32 boards, you can keep your Arduino IDE 2.3.0 installation in place in addition to the 2.2.1 installation and use the appropriate IDE version for the debugging session with each board.
c80f0f1006