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.

TMS320F28069: C2000 halts when there is high noise, causing catastrophic failure in power converters

Part Number: TMS320F28069

Hi

I am debugging a high-power grid tied inverter. When i debugging, sometimes ccs forcefully halt the CPU, possibly due to switching noise. 
Inverter has some PWM states which directly short Live and neutral lines. This is fine as long as the c2000 runs as it supposed to be. But when debugger do the unnecessary and dangerous halt in the middle of the grid connection, this causes a catastrophic failure and possible fire hazard. Now i cannot understand why these TI MCUs which are advertised to use in power converters, do such halting in the middle of debugging. Imagine this happens to a high-power boost converter when the PWM is high. 
Free-soft bits doesn't help. It doesn't run the whole algorithm which is needed to exactly match the inverter output with the grid voltage waveform. this is very dangerous. How can i turn off this so-called genius "debugger feature".  

Regards
Damith

  • Hi Damith,

    The debugger should not be halting a CPU on its own - it will halt only if user hits halt button or a breakpoint is triggered, are you seeing debug connection being unstable in your setup and error messages showing up on the console?

    Can you describe your setup? Are you using a control card/ launchpad and what debug probe are you using?

    Thanks,

    Ashwini

  • Some follow up questions:

    - What type of isolation are you providing between your PC (running CCS) and high-voltage system?

    - You mentioned the problem happens when you are debugging, can you describe the steps that lead the problem? 

  • Hi Ashwini and Gus

    I am testing an inverter in 400V DC and 230V ac domain. So the noise is high. I observed this phenomenon in my previous project which was a dc dc converter. In that case, i enabled Free-soft bits to run the PWM even in these halting events. Because of the topology i used in that converter, PWM running is enough to operate without a failure. 
    But for this inverter case, it is not enough. Whole code needs to be run to operate without a fault. 

    I think this is happening due to high noise. No error messages in the console. Just the PC halted at random points. If i click the run button again, it runs from that point forward.  
    I'm using a custom-made PCB with custom made j tag probe with digital isolation.
    Isolator ICs are same ICs used i the 28069 launchpad.

    Im also using a Shielded USB cable covered with several ferrite cores along the cable. 

    Let's say TRSTN pin somehow get low because of the noise. If that happens, is it possible that the CPU get paused due to this? 

    Thank you

  • Hi Damith,

    I would expecte errors being reported in CCS if TRSTn pin was being asserted as this would result in JTAG state machine being out of sync with the debug state in CCS.

    There is an option in CCS to FreeRun (run with debug disabled), this option is located in Run menu. If you are trying to run without wanting to halt at a breakpoint, this may be an option to use. Could you give this a try and see if the system works as expected?

    Here is some info.

    https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_faqs.html#what-is-the-difference-between-run-resume-and-free-run

    Thanks,

    Ashwini

  • Hi Ashwini

    Free run is not suitable as i want to monitor the system closely. It runs without a problem when operating without debug connection. Is there a way to disable the cpu halting when TRSTn pin got a false trigger?


    Thank you. 

  • Hi Damith, 

    As per my understanding, the debugger will not halt the CPU on its own, it will report status as halted if the target is halted as indicated by the status from the hardware. The only time debugger does halt the CPU is the first time the target is connected. If TRSTn was being asserted CCS would report some error. I will reach out to the CCS experts as well to get their inputs.

    In the meanwhile: 

    1. Is there an option to disconnect the TRSTn pin from JTAG debug probe header to confirm if the TRSTn is the reason for this issue?

    2. When CCS shows that the CPU is halted, where is it halted? Is it in somewhere in the application or is it somewhere in boot? Also, when CCS reports target as halted, is the CPU truly halted - do you have anything on the hardware like blinking LED or something else that you can use to confirm this?

    Thanks,
    Ashwini

  • Hi Damith,

    I have not heard of such an issue in the past. Can you provide some more details about yoru environment? Specifically what exact version of CCS you are using and which debug probe connection?

    If the issue is fairly reproducible, it would be very helpful to get a debug server log. We may be able to identify the source of the halt request from that. Please see the below link for more details on the log:

    https://software-dl.ti.com/ccs/esd/documents/ccs_diagnostic-logs.html

    Thanks

    ki