AM5728: JTAG connection

Peaves@ How do I check if I have revision A3a using software? The serial number seems to start with A3?? 

Biser@ By devices I mean the cores (Cortex A15). I could not connect to the cortex-a15 using a third party debugger. Hence, I am looking for documentation which says about the position of the devices in the JTAG chain? Are they in a JTAG chain at all? etc.

You do not need to read anything in software to determine your board is revision A3.

The sticker along the right edge of the board is labeled A3. The latest revision should be labeled A3a.

I can also confirm this by looking at components installed in R432 and R197. The first page of the AM572x GP EVM schematic for revision A3a has a list of changes made when going from revsion A3 to A3a. The change list removes R432 and installs R197. I can see in the photo, your board has R432 installed and R197 removed. So this confirms your board is revision A3.

Regards,
Paul

Thanks a lot for the reply Paul.

So, to conclude and confirm, there are no jumper settings I need to fiddle with (like some open source boards out there) to put the board in JTAG debug mode right? I just boot the image (Matrix Gui 2.0) and then connect the JTAG debug probe after it completely boots up. right? (I am debugging software applications. not the kernel or the uboot. )

Regarding my issue: I could not connect to the cortex-a15 on AM572x EVM board using a third party debugger (Segger JLink). I know that this is not the place to ask for support for that debugger. But, I am looking for documentation with information on JTAG scan chain which talks about position of the Cortex A15, M4, IVA etc.. on the JTAG chain? I would like to bypass everything and target the cortex-a15's if they are on the same daisy chain. I looked into the technical reference manual, but could not find it. 

Thanks again for your time. 

Hi,

For information about Segger Jlink support, please check section 2 of the page below:
processors.wiki.ti.com/.../J-Link_Emulator_Support

Their list of supported devices does not mention AM57x devices, but it seems that Cortex A15 is supported.

Hope this helps,
Rafael

Hello Rafael,

It looks like the the first level of debug interface seen by the debugger is the ICEPick module embedded in the debug subsystem. The MPU subsystem is on TAP number 15 (page 7871, TRM of AM5728) on the scan chain. Could you please confirm this?

I am guessing that the debugger should first negotiate with the ICEPick module and then only I can see the MPU subsystem. So, is it be possible that even if third party debugger vendors say that Cortex-A15 is supported, due to the presence ICEPick module it could be possible that AM5728 SoC is not supported?

Hi,

solid repellent said:

It looks like the the first level of debug interface seen by the debugger is the ICEPick module embedded in the debug subsystem. The MPU subsystem is on TAP number 15 (page 7871, TRM of AM5728) on the scan chain. Could you please confirm this?

Yes, that is correct. You can also check this information by creating a configuration in CCS with a different JTAG debugger and see each configuration along the way of the JTAG tree.

solid repellent said:

I am guessing that the debugger should first negotiate with the ICEPick module and then only I can see the MPU subsystem. So, is it be possible that even if third party debugger vendors say that Cortex-A15 is supported, due to the presence ICEPick module it could be possible that AM5728 SoC is not supported?

I know there is a way to bypass the ICEPICK, given that Jlink connects fine to MSP432, CC13x, CC32xx, AM335x and other devices that have ICEPICK on them. 

Below I provide a few alternatives that, despite I haven't tested myself, have a high chance of working. 

In this case perhaps it may be a matter of simply bypassing the ICEPICK:

Or perhaps re-creating the device configuration from scratch but this time removing the ICEPICK altogether - something similar to what is done to accommodate the CC3200 for SWD:

Hope this helps,

Rafael

desouza said:

Yes, that is correct. You can also check this information by creating a configuration in CCS with a different JTAG debugger and see each configuration along the way of the JTAG tree.

Wow, that is such an nice and intuitive way to check the JTAG tree. Thank you very much. 

desouza said:

I know there is a way to bypass the ICEPICK, given that Jlink connects fine to MSP432, CC13x, CC32xx, AM335x and other devices that have ICEPICK on them. 

Below I provide a few alternatives that, despite I haven't tested myself, have a high chance of working. 

In this case perhaps it may be a matter of simply bypassing the ICEPICK:

Or perhaps re-creating the device configuration from scratch but this time removing the ICEPICK altogether - something similar to what is done to accommodate the CC3200 for SWD:

Thanks for the tip. How should I flash this device configuration (either bypassing or completely removing ICEPICK) on to the target board?

Rafael@ Could you please answer the above question. Depending on that, I will decide the best possible option for my AM572x board (either to write a custom JLinkScript file or to go ahead with one of your suggested options). 

Thanks again for your time. 

Hi,

solid repellent said:

Thanks for the tip. How should I flash this device configuration (either bypassing or completely removing ICEPICK) on to the target board?

The target configuration file only describes the hardware which the JTAG connection is going to use - in other words, it is not really loaded/flashed to the target.

That said, I was experimenting with this today trying to create a configuration from scratch but unfortunately I couldn't find a suitable Jlink driver for the Cortex A15 processor - the Segger Jlink connection only allows the CPUs below:

The main issue at this point would be to see if Segger will provide a suitable Cortex A15 driver to enable its use in CCS. I can check if there is any further developments on this. 

With this, I think that unfortunately at the moment there'll be no way to use AM57x devices with Segger Jlink and CCS. Sorry.

Regards,

Rafael

desouza said:

That said, I was experimenting with this today trying to create a configuration from scratch but unfortunately I couldn't find a suitable Jlink driver for the Cortex A15 processor - the Segger Jlink connection only allows the CPUs below:

While the Segger Supported CPUs and devices says the Cortex-A9 and Cortex-A15 are supported cores, as of CCS  7.1.0.00016 with SEGGER J-Link Support (Windows) 6.14.5.0 the installed device XML files show Cortex-A9 and Cortex-A15 are not supported with the Segger J-Link, but the Cortex-A8 is supported.

In case the limitation was just missing XML files I tried creating a jlinkcortexa15.xml, based upon ccsv7\ccs_base\common\targetdb\drivers\jlinkcortexa8.xml and changing the core type. With that change CCS 7 allowed a target configuration to be created with Segger J-Link and a Cortex-A15 but attempting to launch the debug configuration failed with the error:

CortexA15_0: Error initializing emulator: ERROR! Core type not supported!

That error message is coming from the ccsv7\ccs_base\DebugServer\drivers\JLINK2GTIAdapter.dvr driver. That confirms that there is not yet any support in the CCS Segger J-Link driver for Cortex-A15 CPUs.

Do you think it is because of the proprietary IcePick router controller on this particular SoC that Segger cannot provide support for this SoC? If there are SoC's without the IcePick interface then may be it would work?

 

Hello Rafael,

From where do I get/build ICEPick IDCODE and DAP IDCODE? I am trying to writing Jscript file for the JLINK debugger and I need this information. Could you please let me know?

Hi,

solid repellent said:

Do you think it is because of the proprietary IcePick router controller on this particular SoC that Segger cannot provide support for this SoC? If there are SoC's without the IcePick interface then may be it would work?

Actually no. My previous assumption was incorrect, given that I can connect to my BeagleBone White using my Jlink using the unmodified device configuration (Cortex A8 is supported). The issue is lack of support from the driver itself.

solid repellent said:

From where do I get/build ICEPick IDCODE and DAP IDCODE? I am trying to writing Jscript file for the JLINK debugger and I need this information. Could you please let me know?

This information is usually provided by the device TRM. If you can't find it there, you can get this directly from the debugger, as shown in the short clip below.

Hope this helps,

Rafael

Thank you Rafael for the post. The video truly shows the power of Code Composer Studio.

But, unfortunately, it is not very useful now as I cannot yet connect to the target. I will not be able to get those register values I guess. You connected to the target at 0:20 minutes in the video.

Also, when I try to make a search in TRM for "IP_IPCODE" or "IP_TAPID" etc.. (basically, the names of the registers obtained by using the technique shown in your above video), it does not yield any results. Do you think, that the those names are different in the TRM? or I should be looking at a different place. Can you for example just let me know on which page I can find the ICEPick IDCODE?

Hi,

solid repellent said:

But, unfortunately, it is not very useful now as I cannot yet connect to the target.

I suspect you will not be able to connect to the A15 due to the driver anyways.

solid repellent said:

Also, when I try to make a search in TRM for (...)

Unfortunately it seems they either removed or never included this information in the AM57x. 

At any rate, I exported the registers of each JTAG entity on the chain on the attached file. Unfortunately I can't find my AM572x board and thus the registers are for the AM571x device (single core Cortex A15). 

Tomorrow I can try to find my other board and give you the updated registers.

Regards,

Rafael

AM57x_Router_Regs.zip

Hello Rafael,

>>>Unfortunately it seems they either removed or never included this information in the AM57x. 

Could you please confirm this with the person responsible and let me know again? 

The thing is I am now writing a JLinkScript file from a template (for TI CC3200) provided in the JLink installation directory. The template file is in the following link. 

https://goo.gl/KvBqu6

Could you please have a look at it. I need to know lots of other constants apart from the JTAG entity registers. 

Meanwhile, I have also found this pdf which is linked in the TRM. 

http://processors.wiki.ti.com/images/f/f6/Router_Scan_Sequence-ICEpick-D.pdf

It seems to have some information. But, if I were to write the JLinkScript which bypasses the ICEPick, I need to have full access to documentation with all the information that is required to write such a file. 

There seems to be some discrepancy in the names which Code Composer Studio produces (like in the video you attached) and the names in the documentation. I am not exactly sure about this though. 

Hi,

solid repellent said:

>>>Unfortunately it seems they either removed or never included this information in the AM57x. 

Could you please confirm this with the person responsible and let me know again?

This thread is placed at the Sitara forum, thus the experts will be made aware of this question and probably know this information.

solid repellent said:

The thing is I am now writing a JLinkScript file from a template (for TI CC3200) provided in the JLink installation directory. The template file is in the following link. 

Sorry, I am not sure if I can help further with this. Not only I do not have access to Google Drive from work but I am not at all familiar with how Jlink deals with targets.  

I forgot to tell you, but since the beginning of this discussion I have been in contact with Segger to report the absence of support for the other devices. They told me they can start looking at the integration efforts next week, which will probably be more productive (as they have the source code for their drivers). 

solid repellent said:

There seems to be some discrepancy in the names which Code Composer Studio produces (like in the video you attached) and the names in the documentation. I am not exactly sure about this though. 

The document seems to be quite old (I can't pinpoint its date, but version 0.1 probably puts it as more than ten years old), therefore it is possible that name changes were incorporated in subsequent versions of the Hardware/software. 

Regards,

Rafael

Hello Rafael,

I have now bought TI XDS200. I am trying to connect to the target with it. But unfortunately, I could not make a connection. It gives me the following error. I have deleted the old workspace and created a new one. rebooted my machine. Changed the USB cable. But still no luck. The green light on the XDS200 emulator is on though. Any more things I could do?


**************************************************************************
[Start: Texas Instruments XDS2xx USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

/home/solidrepellent/.ti/ti/0/0/BrdDat/testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_io
Failed to open i/o connection (xds2xxu:0)

An error occurred while soft opening the controller.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-250' (0xffffff06).
The title is 'SC_ERR_ECOM_EMUNAME'.

The explanation is:
An attempt to access the debug probe via USCIF ECOM has failed.

[End: Texas Instruments XDS2xx USB Debug Probe_0]

**************************************************************************

My lsusb command on the terminal tells me that it detects Texas instruments usb device. 

solid@rep% lsusb
Bus 002 Device 002: ID 0424:5534 Standard Microsystems Corp. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 04ca:7053 Lite-On Technology Corp.
Bus 001 Device 007: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 009: ID 0451:bef0 Texas Instruments, Inc.
Bus 001 Device 004: ID 046d:c313 Logitech, Inc. Internet 350 Keyboard
Bus 001 Device 002: ID 0424:2134 Standard Microsystems Corp. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

solid repellent said:

This error is generated by TI's USCIF driver or utilities.

The value is '-250' (0xffffff06).
The title is 'SC_ERR_ECOM_EMUNAME'.

The Wiki Host connection error entry lists some reasons which can cause that error.

Also, by default the XDS200 configuration file attempts to connect to /dev/ttyACM0. If some other device has enumerated as /dev/ttyACM0 then the above error can occur.

if you have more that 2 /dev/ttyACM* entries the work-around is to use the "Debug Probe I/O Port Number" field on the XDS200 target configuration file to specify which /dev/ttyACM* entry the XDS200 has enumerated as - see XDS troubleshooting on Linux