• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 223 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem programming development kit with on board xds100v2

Pablo Cottens
Genius 3020 points

Hello,

I am using a Hitex development kit for functional safety. I used to be able to program both microcontrollers, but since I removed the accelerometer I am unable to program one of the microcontrollers.

However, when I run the xds100serial.exe, it is able to find both microcontrollers, but when I test the connection with one of the microcontrollers in the target configuration, it gives me this error:

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

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

The value is '-151' (0xffffff69).
The title is 'SC_ERR_FTDI_OPEN'.

The explanation is:
One of the FTDI driver functions used during
the connect returned bad status or an error.
The cause may one or more of: invalid emulator serial number,
blank emulator EEPROM, missing FTDI drivers, faulty USB cable.
Use the xds100serial command-line utility in the 'common/uscif'
folder to verify the emulator can be located.
  • 0
    Genius 3020 points

    Found the problem.

    Everything was ok with the hardware and I tried everything I coud think of.

    Finally I just restored the system with its initial binaries. The moment I restored one of the microcontrollers the other was accessible for the JTAG.

  • 0 in reply to Pablo Cottens
    TI__Guru 68920 points
    Thanks for sharing the answer Pablo.

    It may also be that one of the MCU's on the Hitex kit is designed to inject faults on the other MCU. Some of these faults include dropping the power rail, doing things to cause reset, etc. which would also mean that you can't debug the other MCU. For example, you can't debug if the core power rail is dropped out or if the device is held in reset.