• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 560 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.

CCS/TMS320F28035: cannot connect the debugger

Viktorija Cecil
Mastermind 18501 points

Part Number: TMS320F28035
Other Parts Discussed in Thread: C2000WARE

Tool/software: Code Composer Studio

Team, 

My customer is using TMS320F28035 device on his board, and cannot connect the debugger. Details:

I tried two XDS200 and XDS510 both cannot connect. My CCS is in 7.2.0.00013 version.

This is the error message from XDS510:

And XDS200:

I checked the crystal oscillator signal at X2 and it seems to be good:

The same with power supply I have very stable 3.34V and 1.9V.

I have my suspicious on the reset signal XRS. I have it pulled up by 10k resistor to 3.3V with 1nF capacitor so it should be at high state but I see some internal resets on the XRS by the micro. It is at about 74kHz frequency with duration about 50us see below this is the power up XRS signal:

Why I see the internal reset any idea?

I use the DSP2803x_CSMPasswords.asm routine but with password set to all FFFFs. Is it possible that during the internal resets on XRS the erasing crushed and wrote some random number or zeros locking the device?

 

The JTAG signals seems to be good as well I am getting the clock and TRST signal is going up when trying to connect.

JTAG clock TCK 12MHz (XDS510 usb):

I would really apricate your quick help with my issue.

P.S. I use 7.2 CCS due to some problems with installation of any newer version. I think my corporate computer setting does not let for installing the new Code Composers. The 7.2 or order are the only version I can install the newer ones are not possible to install.

Thanks

Viktorija

  • 0
    TI__Guru* 84340 points

    Viktorija,

    The pulsing signal on the XRSn pin is indication that the internal WatchDog circuit is firing since it is not serviced by the FW(or lack of FW) that is on the device when it comes out of reset.

    We have an app note that documents common JTAG connection problems and how to solve them here: http://www.ti.com/lit/spracf0 

    If possible I would also put the device in Wait Boot Mode, which will prevent it from executing code (and potentially locking and terminating the JTAG connection) as well as the WatchDog toggling XRSn.  The Wait Boot mode setting can be found in the datasheet here: http://www.ti.com/document-viewer/TMS320F28035/datasheet/boot-rom-litsprs230-0453#litSPRS230-0453 

    Best,
    Matthew

  • 0 in reply to MatthewPate
    TI__Mastermind 18501 points

    Mathew, 

    Follow up question from customer:

    1) I think I know what is my problem but would like to confirm it. I have an external watchdog connected to the XRS rest pin and I think it was not deactivated when I was erasing the Flash by CCS and XDS510 debugger. This means the XRS pin was pulled down by the external watchdog circuit when erasing the micro flash. Can this effect in permanently locking the microcontroller by setting zeros or random password in PWL of CSM?

     2) It looks that in the locked board even after setting the wait mode by external pull up/down resistors I still see the XRS toggled by the internal watchdog. How it is possible? Do you think that something else is still triggering the internal watchdog (for example brownout even if the micro is in the wait mode?

    Thanks

    Viktorija

  • 0 in reply to Viktorija Cecil
    TI__Guru* 84340 points

    Viktorija,

    1)I agree that this could have caused unexpected outcomes when programming the flash, and ultimately locking the device.  While the TRSTn signal will allow for the core to be kept out of reset, the physical XRSn signal goes to alot of other logic that TRSTn would not be able to bypass like the core.

    2)I looked at the source code for the BROM here C:\ti\c2000\C2000Ware_2_00_00_02\libraries\boot_rom\f2803x\v1_0\rom_sources\source and while Wait Boot will loop outside of a secure zone(which should allow the emulator to connect) the WatchDog is left on.  I was incorrect in my previous statement on this point.  However, this shouldn't keep the user from connecting through JTAG, only accesses into a secure zone can do that, and this cannot happen in this mode.

    Customer should be able to connect, and then looking at the CSM password locations in a memory window confirm that the device is locked.

    Best,

    Matthew