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.

TM4C1294NCPDT: XDS 110 Debugger sets pins by accident on daisy chained device

Part Number: TM4C1294NCPDT

Hi,

I am having a strange issue where I use daisy chained TM4C1294NCDPT devices. The problem occurs when accessing the JTAG chain through XDS110 and CCS 10.2. It seems as if the boundary scan on the second device is active even though I am just using the TAP to download code or debug. As I understand it the XDS110 startup sequence should disable the boundary scan functionality at first connection. Still I have input pins suddenly turning to outputs  or pull-up on my second device. Debugging and loading code is fine. When using the XDS 200 debugger everything works.

The issue is not urgent since I can use the XDS 200 instead. Just curious if there is a bug in the XDS 110 or in my setup.

Best regards

Jens

  • Hi,

      I guess there is some difference between XDS110 and XDS200 that I cannot explain. I will forward your post to our CCS/Tooling experts for comments. In the meantime, please also check the target configuration files between XDS110 and XDS200 for your daisy-chain configuration. 

  • Hello Jens,

    Using an XDS110 for debug daisy-chained devices should work. I have successfully daisy-chained two TM4C1294NCPDTs and debugged them with an XDS110. I have not heard of the issue you described. If you put the first CPU in bypass and only debug the second CPU, do you still observe the issue?

    Thanks

    ki

  • I should note that there is one known issue with hardware breakpoints on the second CPU of daisy chained Tiva devices. But this appears to be a separate issue from the one you are describing:

    https://sir.ext.ti.com/jira/browse/EXT_EP-10378

  • Hi,

    1. I forgot to mention that the I/O pins only change state for a split second but it is enough for the connected devices to behave badly. I have not had the time to measure for how long unfortunately. I have scoped the JTAG signalling though and the XDS200 traces seem to differ from the XDS110. The known break point issue I am aware of.
  • Hi,

    I forgot to mention that the I/O pins only change state for a brief moment at first connection. When the debugger has initialized they work as expected. I have not had the time to measure how long the state change lasts. I have scoped the JTAG signalling though and there are differences between XDS200 and XDS110. Not being a JTAG expert I can't tell if it is significant in this case.

    The reason I found this is, I have designed a backplane system where the slave address is selected by a dip-switch connected to the MCU pins and the JTAG is routed accordingly by discrete logic. When the chain is initialized using XDS110, the MCU pins briefly changes the address and the chain breaks.

    Best regards

    Jens

  • I forgot to mention that the I/O pins only change state for a brief moment at first connection. When the debugger has initialized they work as expected. I have not had the time to measure how long the state change lasts. I have scoped the JTAG signalling though and there are differences between XDS200 and XDS110.

    Thank you for sharing this detail. It explains why I have not had any issues in my environment.

    If you bypass the first device in the scan chain, do you still see the same behavior?

    Can you also share the ccxmls for both the XDS110 and XDS200 setups?

    Thanks

    ki