• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 222 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28032: The TRSTn pin resistance is 1Ohm (<2.2Ohm), what effect will this have? DSP TMS320F28032

Shaoxing Ke
Intellectual 2835 points
Part Number: TMS320F28032

Hi Every one,

    I know the for normal device operation(debugger not connected) TRSTn needs to remain "low", it recommend placing a 2.2kOhm pull-down on this pin hold the test logic in reset.

    But my customers' TRSTn pin resistance is 1Ohm , what effect will this have in the  DSP TMS320F28032?

    What effect will the difference in the size of the resistance have?

    What can happen if the TRSTn pin resistance is too small? and What happens if the TRSTn pin resistance is too large?

  • 0
    TI__Guru 71785 points

    Shaoxing,

    TRSTn pin is what keeps the emulation logic on the device in reset(active low).  When we want to connect the device to Code Composer/debugger this pin is pulled high by the debug pod attached to the JTAG pins.

    If the value is too low, as in this case, it means it is a very strong pulldown and likely when we try to connect with the emulator its internal drivers will not be able to pull it high, so we can not debug.

    If the value is too high, it means a very weak pulldown, so there is more chance that system noise could accidentally pull this high during operation which would be undesirable.  In addition to debugging JTAG out of reset can be used to activate boundary scan modes, etc.  So the device behavior would be non-deterministic if this happened.

    I'm assuming the reason customer did this, was that they were finished with development and wanted to make sure as possible that TRSTn did not get pulled high on accident.  If they want to connect a debugger, they will need to change this value back to 2.2k range.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2835 points

    Hi Matthew,

        The customer has completed development, which is a mature product  based on F28032. However, the product works with an emulator/JTAG, and does not work without an emulator/JTAG. So TRSTn pin is not the cause of its non-functioning, from your perspective, could it be caused by another cause?

  • 0 in reply to Shaoxing Ke
    TI__Guru 71785 points

    Shaoxing,

    Can you clarify the statement on working with the JTAG.  Does this mean the system will work if the JTAG is plugged into an emulator, or does CCS need be active, issue the run?

    Typically if code only works with CCS running, it has to do with initialization issues or the device is not booting properly(CCS takes care of alot of these in the background).

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2835 points

    Hi Matthew,

        Yeah, The system will work if the JTAG is plugged into an emulator, So What specifically does initialization issues refer to?

  • 0 in reply to Shaoxing Ke
    TI__Guru 71785 points

    Shaoxing,

    I'm going to re-state your response so I'm 100% sure we are on the same page:

    1)In the customer's system, in order to get the correct operation, the customer has to attach a debug probe(XDS1xx or other) to the JTAG header on the PCB.  However, Code Composer or other interface SW is NOT started.

    If this is accurate, then TRSTn pin should still be low, since to my knowledge only a command from CCS will cause it to drive high in order to connect the device.

    Assuming this to be true, I would question how well the TRSTn signal is driven w/o the emulator attached.  Has customer tried to place a scope probe on TRSTn and look for any high going glitches(without the debug probe connected)?  Does the system behave any differently with just a scope probe attached to the TRSTn pin?

    Going back to the earlier post, I'm very surprised that with 10 Ohm resistor on TRSTn that Code Composer could connect to the device.  I have seen the debug probes have issue with loads smaller than the 2.2kOhm we recommend, compared to this 10Ohm is almost a short to VSS.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2835 points

    Hi Matthew,

        I am sorry for the Inappropriate expression, the customer use the 1kOhm not 1 Ohm, And the signal of the TRSTn pin will be checked today.

  • 0 in reply to Shaoxing Ke
    TI__Guru 71785 points

    Thanks for the clarification Shaoxing, 1kOhm makes more sense.  It should still be strong PD for TRSTn.  Will see what customer observes.

    Best,
    Matthew

  • 0 in reply to MatthewPate
    TI__Intellectual 2835 points

    Hi Matthew,

    MatthewPate said:
    In addition to debugging JTAG out of reset can be used to activate boundary scan modes, etc.  So the device behavior would be non-deterministic if this happened.

     Can you give more explanation? My customer now encounters an illegal interrupt when he single-steps the code when connected to the emulator?

  • 0 in reply to MatthewPate
    TI__Intellectual 2835 points
    MatthewPate said:
    It should still be strong PD for TRSTn.  Will see what customer observes

    Hi Matthew,

         Customer observes the signal of TRSTn is normal, and then attach a debug probe to the JTAG header on the PCB, Run the Code it can work, But unplug the debug probe, it can not work. So I ask the customer  the emulator's initialization of the device from the debug probe. can you give me another way from your perspective?

  • +1 in reply to Shaoxing Ke
    TI__Guru 71785 points

    Shaoxing,

    When the emulator and CCS are connected there are some default settings in CCS that "help" the code to run.  For instance I think the default action of CCS after a program load is to run to main; but also it will begin from .cinit in the code vs the BootROM which would be the flow when the device is in standalone.

    What customer should do is flash the device, but then use CCS to do a Reset(Under the Run item in the menu ribbon).  This should emulate a reset condition and show if the code is OK in standalone mode.

    Have customer go to Tools->Debugger Options->Auto-Run and other Launch Options.  Make sure that the auto run to main, the "reset" box is unchecked.

    There could also be a case of memory that is not initialized in their code that after one run with CCS connected is loaded correctly and then the code runs.

    If they are getting an illegal instruction, I would also look to make sure that the memcpy function (copying code from flash to RAM for better speed) works correctly.  To do this I would run to after the copy and make sure the image in RAM matches the image in flash, etc.

    Best,

    Matthew