• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 1289 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.

RM48L952 nTRST

Martin Beakes
Intellectual 325 points

Other Parts Discussed in Thread: RM48L952

Hi, 

I'm currently designing the nTRST section of the RM48L952 CPU. 

Based on some research that I did (see link below from e2e forum), it seems that the nTRST line needs to be Low on boot to avoid unwanted situation (see TMS570 forum).  Now I'm a bit confused about how to drive this line.  

Is the nTRST line needs to be Low on Boot ?  

I'm asking this question because we were planning on driver the nTRST line as follow using an open collector buffer (74LVC2G07).

- Buffer inputs 1:  TPS65381 nRES

- Buffer Input 2:  MIPI-nTRST  

-Buffer Output : Both tied together with a PU to 3.3V. 

In this case on the TPS will reset the nTRST and if when required, the MIPI can also control the line. 

Please note that our circuit contains the following:

- Standard 20 pins JTAG connector (refered as Cortex-M connector). This is the small header without the nTRST line. 

- MIPI-60 pins

-TPS65381 

I noticed that the nTRST line is no longer part of the new ARM JTAG connector. From what I understood,, this line is optional and in most cases not required. 

Is the nTRST line required on RM48L952 when using JTAG ? 

  • 0
    TI__Guru 69070 points
    Martin,

    There really isn't one standard JTAG header - there are many variants. A nice summary is processors.wiki.ti.com/.../JTAG_Connectors

    At the core of this question is the desire / need to have a separate nTRST from the device reset.

    The nTRST resets the TAP and the debug logic on the chip. This is logic that you *really* want under control when you deploy your application. You don't want to have the device power up with this logic uninitialized and then sometimes have the CPU enter the debug state.

    Because we have an nTRST pin, you can protect yourself from this problem by pulling nTRST low on your PCB when there isn't a JTAG debugger attached. For that reason it is useful to have nTRST separate from the other device resets, the other resets can be released but with nTRST low you will never enter the debug state.

    Now note that the nTRST pin also has a weak internal pulldown resistor. Again this is defensive - if the pin develops an open in the deployed system - the pulldown again makes sure that nTRST is asserted and the device will never enter debug in error.

    Now on this particular device the 'uninitialized debug logic' factor isn't really a problem because nPORRST always causes nTRST to be asserted inside the device. So just coming through a power on reset you will reset the debug logic and TAP. So having that external nTRST pin in addition means only an added layer of protection... some bit flip(s) would not cause you to enter debug because nTRST=0 prevents that.

    That much said - it does mean that you need to *drive* nTRST high when you do want to debug.

    Honestly I would recommend that you *NOT* drive this signal high on your PCB that way when you deploy your system you retain the benefits of having nTRST low and having peace of mind that something else is preventing the device from 'halting' in error. One less failure mode to worry about.

    I would recommend driving this signal from an external JTAG pod. I believe all of the TI pods can drive it actively.
    Otherwise if you are using a non-TI (non Spectrum Digital, Blackhawk version of a TI XDS pod).. and your JTAG pod drives nTRST with an open drain ouptut consider building an adapter between your pod and the PCB and just put a strong pullup resistor on this adapter on nTRST .. enough to override the pulldown internally.

    But this way, when you disconnect that pod and adapter - you wind up with just the internal pulldown on nTRST and you've got the protection of nTRST low blocking entry into the halted / suspended state.

    That's my 2 cents on this topic. There is another school of thought regarding the importance of debugging through a reset .. which we can do for a warm reset but cannot do through a power on reset .. But I think with an MCU designed for automotive you err on the side of making it robust on startup at the expense of a debug feature. Again my two cents.

    -Anthony