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.

CC2642R-Q1: JTAG pin configuration in production

Part Number: CC2642R-Q1

Team,

Is it true that the JTAG pins can be left floating as if they are unused GPIOs? On our reference designs, we tend to do this with the JTAG pins being left floating until the XDS programmer is connected. We say in the TRM that unused GPIOs can be left floating as they are in tri-state. However two of the four JTAG pins do not have GPIO functionality. 

1. Can the JTAG pins be left floating in production? If so where is this documented?

2. If a designer is not comfortable leaving the pins floating due to a potential for TCK or another input to be oscillating in a noisy environment, is this a warranted concern for CC2642-Q1? Why or why not?

3. Relevant to #2 - can we tie any JTAG pins low or high due to internal pull-up or pull-down as we would do with GPIOs? (TRM seems to suggest we don't have manual control over JTAG pin registers, but we could have two of the pins turn to GPIO then control them as needed without JTAG)

  • We're taking this internal with the tools team. We will update when we learn more.

  • Hi,

    I will update the information once i receive confirmation from tools team.

    Regards,

  • We're still waiting to hear from the tools team, but something Farrukh and I think could work to be to populate the board as described before (TMS pulled up, TCK pulled down, and leave the other two floating), then if we learn that it's not necessary after the fact, to simply not populate those resistors and keep them floating. How does that sound?

  • I had a thought on this - what if the customer decides to lock the JTAG port? would this remove the possibility of activity on JTAG inputs such as TCK, etc?

    Nathan Block said:

    We're still waiting to hear from the tools team, but something Farrukh and I think could work to be to populate the board as described before (TMS pulled up, TCK pulled down, and leave the other two floating), then if we learn that it's not necessary after the fact, to simply not populate those resistors and keep them floating. How does that sound?

    EDIT: to answer your question, Nathan, the customer has already manufactured their PCBs. I am checking to see if there is another revision that will take place, but either way this is an urgent request and we really want to get the definitive answer to them. I will check and update you if this method will be OK but I presume it will not. thanks

  • I think so. I found this other E2E post that indicates so.

    e2e.ti.com/.../419332

  • Nathan,

    Quick update from my side:

    1. Customer is going to fabricate new PCBs, and are going to implement the plan you mentioned above (TCK pulled down, TMS pulled up)

    2. I recommended locking the JTAG and that is also a viable option

    Still would like the hardware teams final word on all of this, and might be a good addition to swra640 and/or our TRM.

    Thank you for your help

  • Agreed - this is something that could be documented more clearly. I'm asking internally if we can consider an app note or a revision. Thank you for the recommendation. We're still working on generating a consensus, and when we do, I'll post it here.

  • Have you reviewed the ICEMelter chapter in the TRM?

    On CC26x2 additional logic was added to make the device more robust against unintentional TCK toggling. It also mentions that the TCK pin has an internal pull-up, so an external pull-resistor should also be to VDD.

    Further, the chapter says that TCK input driver can be disabled from SW. 

  • Hi Fredrik, great to hear from you. So to be on the safe side a strong pull-up on TCK is all that's needed? No passives on other JTAG lines? I appreciate there is a register to disable the TCK pin, but it seems from the language that an external pull-up may be needed. 

    Another question for you - when globally disabling the JTAG port via CCFG - will this also be sufficient to resolve the issue such that no pull-up/pull-downs will be needed on any JTAG pins? 

  • Hi Brandon,

    I hope all is well with you!

    Yes and no. A stronger pull-up on TCK will make it less susceptible to unintentional toggling, but it cannot be guaranteed. I have only seen this happen on a few designs with quite long JTAG traces though, and the added timing requirements in CC26x2 from CC26x0 makes it much less likely to happen. The probability of having a problem with TCK toggling is thus very small to begin with, and I do not think an external pull-up actually reduces it. 

    Disabling JTAG in CCFG just blocks TAP (or is it DAP) access, it does not disconnect the HW, so it is still possible to (unintentionally) wake the JTAG domain. 

    Disabling the TCK input driver through [AON_IOC:TCKCTL] is the absolute best way to block any unintentional activity on the JTAG port as this physically disconnects the pin. This feature was introduced on CC26x2 just for this purpose and does not require any other modification or circuitry.