CCS/XEVMK2LX: On board XDS200 cannot be accessed

Dorothea,

Due to unknown (at least to me) reasons the Keystone II boards like yours were pre-programmed from the factory with a very old firmware on their XDS200 embedded debuggers.

As you noticed (and reported in the XDS200 wiki page), the original firmware does not work in Linux, therefore an update is mandatory it you need to use it in this OS. Unfortunately due to this very same reason the update should only be done in a Windows OS (as noted in section 7 of the XDS200 wiki page), as Linux can't properly communicate with the probe.

In this case you were caught in an unfortunate situation where the XDS200 may, in fact, be bricked (not necessarily fried as there is no physical damage to it). As a last recourse I would try to connect the board to a Windows host and see if the JTAG debugger can be detected and updated. Otherwise a RMA would be required. 

In the meantime I will try to see if there is a documented method to write the firmware using the JTAG port of the AM1802 device (the 20-pin connector near it). 

I apologize for the inconvenience,

Rafael

Dorothea,

Dorothea Pfeiffer said:

thank you so much for your answer! The sad thing is that I did actually read the xds200 TWIKI page before I tried to update the firmware. I got confused concerning the version of the xds200 firmware, since the EVM has a sticker on the Ethernet socket which reads "EVM v 1.0.3.0". And me, idiotically, took that as version of the xds200 firmware, wrongly assuming that it was not the dreaded 1.0.0.2 version.

I feel your pain... I have a bricked XDS200 mezzanine card that had the 1.0.0.2 firmware and I did exactly the same as you: I tried to update it using a MacOS host... 

Dorothea Pfeiffer said:

Anyway, damage done, and I learned something :-). I thought that I really fried something, because the LED 2 is not lit anymore, no matter whether I connect the USB cable to a Windows PC, Mac OS or Linux. Also, the USB devices are not created any more. But if the xds200 is just bricked as you say, It would be so great if you could figure out how to write the firmware via the AM1802. In the mean time I ordered a XDS560v2 with MIPI 60 connector, to be able to work with the board even if the on board xds200 cannot be recovered.

It is good that you are going to get an external JTAG debugger - you would need one to un-brick the onboard XDS200. 

By playing with my bricked XDS200 I think I was able to find a way to make it work. The procedure below takes into consideration the original XDS200 bootloader in flash memory is intact - there is no way to know until you try the procedure and see if it works after a disconnect/connect.

- Connect an external JTAG debugger to the JTAG port of the XDS200 onboard debugger. 

- Start CCS and create a target configuration using the external JTAG debugger as a connection and the AM1802 as the target device.

- Follow the steps on the video below (I will eventually "beautify it" to publish somewhere else)

Dorothea Pfeiffer said:

Three more little question:

The most experienced folks that can reply to these questions are residents of the Keystone II forum, therefore I would definitely post these questions there. 

However, I can take a stab at them:

1. The multiple boot modes in a device are generically suitable for the various applications where it can be used. The two boot modes mentioned in the documentation take into account the board hardware, but if the device runs in a different HW infrastructure it can boot from different peripherals such as the Ethernet, PCIe, etc.

2. The Processor SDK is the evolution of the MCSDK and, IIRC, supports CCSv6.2 or CCSv7.0. Given the support for the MCSDK may be stale or non-existing, I would certainly try to move ahead with the newer SDK. 

3. As you said, the application will demand which version of Linux SDK is more suitable. RT Linux has time-dependent mechanisms at the expense of a performance impact, while Linux is leaner but less deterministic. 

Hope this helps,

Rafael