• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 438 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/TMS320F28069F: Microcontroller stops during debugging after a device reset occurred

Mathias Felix
Prodigy 172 points

Part Number: TMS320F28069F

Tool/software: Code Composer Studio

Hi there,

In connection with another thread we had the problem that the microcontroller stops during debugging after a device reset occured. Of course it's possible to (re)start the micro manually again. But in this particular case, the micro is the DUT in an automated test environment which performes a lot of reset sequences to put the device in a defined state. We want to stay conencted with the debugger during the whole test process like we do with ARM controllers.

I heard that can be achived with something called DSS scripting. What needs to be done and what are the requirements? Are there any examples?

Thanks and best regards,
Mathias

  • 0
    Guru 192875 points
    Hi Mathias,

    Did you already refer: software-dl.ti.com/.../sdto_dss_handbook.html

    Regards,
    Gautam
  • 0 in reply to Gautam Iyer
    Prodigy 172 points
    Hi Gautam,

    I have now watched the video and read the training presentation and I was looking at all the console commands. That's all very well and the possibilities seem to be very powerful. But all I want to do is prevent the processor from being halted by the debugger after a reset. And so far I have not found any clue how DSS could help me with this. Problably I have to understand first what's the reason for this behavior... Maybe you can give me some hints about the behavior of the debugger and how it's possible to control this out of a script.

    Thank you and best regards,
    Mathias
  • 0 in reply to Mathias Felix
    TI__Guru* 84230 points

    Mathias,

    I read through the post you had with Sal for the background.  DSS may indeed give us the right path, but I agree there are some specifics that need to be ironed out.  

    Some questions to get me up to speed:

    If you could reply with the Answers: A#) below inline it would help me keep things straight.  

    Q1) Would you be able to elaborate a bit on the way the C28x device gets the reset signal from the test infrastructure?  I beleive I saw that some signal was sent across the USB, but that it ultimately triggered a WD reset to the MCU.

     

    Q2) You mention that the emulator is connected to the MCU during this testing.  So far to work around the reset/halt you have to manually hit "run" from the debugger.  Can you elaborate on what other function the debugger/CCS is doing when connected, output graphs/realtime variable monitoring etc.  More to the point what functionality would you need replicated if we took the debugger/CCS out of the picture.

    Look forward to your reply.

    Best,

    Matthew

     

     

     

  • 0 in reply to MatthewPate
    Prodigy 172 points
    Hi Matthew,

    You will find my answers below inlined.

    Q1) Would you be able to elaborate a bit on the way the C28x device gets the reset signal from the test infrastructure? I beleive I saw that some signal was sent across the USB, but that it ultimately triggered a WD reset to the MCU.

    A1) Yes that's right. We use USB as an service interface on a CANopen device. The whole object dictionary is accessible over USB even the object to reset the device. Internally we the watchdog counter to do the reset cycle.

    Q2) You mention that the emulator is connected to the MCU during this testing. So far to work around the reset/halt you have to manually hit "run" from the debugger. Can you elaborate on what other function the debugger/CCS is doing when connected, output graphs/realtime variable monitoring etc. More to the point what functionality would you need replicated if we took the debugger/CCS out of the picture.

    A2) We would be happy if the device starts automatically and a breakpoint could be active after the jump to main() has been executed. Watching variables would be nice too.

    It does not have top priority because we could solve the USB thing otherwise. Nevertheless the boot up behavior restricts us from time to time also because we are used to it from other platforms.

    Thank you and best regards,
    Mathias
  • 0 in reply to Mathias Felix
    TI__Guru* 84230 points
    Mathias,
    Thanks for the answers, and yes I think using the DSS scripting is the right way to go. The info and examples are in the base CCS install here(using CCS v8) C:\ti\ccsv8\ccs_base\scripting\

    Using this with you CAN tool; you can add/remove breakpoints as well as run/halt. There is also the ability to restart/reset(basically all the CCS type actions) which may be a bit more orthogonal than issuing a WD reset. Meaning that based on the CAN status(or setting another BP) you could chose to halt/reset/restart the device rather than potentially issuing a reset in the middle of a operation if that matters.

    Let me know if I can be of more help.

    Best,
    Matthew