TMS320F28335: Emulator, debug, watch window, IGBT explosion

Thank you, Mr.Mark.

Hi Dear specialists of E2E,

The inquiry posted by Mr.Mark comes from me. I'd like to supplement some information about this inquiry,

The bus voltage of this high voltage system is 540V, and there are some isolation circuit between high voltage circuit and low voltage circuit(control circuit).Will the program halt when emulator is disconnected?

BTW, I have to correct a mistake, the MCU I used is F28035, not F28335.

Thank you very much.

If the device is running, I don't beleive that the CPU will halt if the debug probe is disconnected.  However, I would recommend using the COMP module to detect an overvoltage condition and connect the COMPOUT to the ePWM TripZone that corresponds to the ePWM you have controlling the FETs.  During normal operation this can be used to asynchronusly put the ePWM in high Z if there is an over-voltage event.  This can also be used to protect the FETs while you are debugging either with a connection or not.

I'll look more into the exact behaivor of disconnecting the emulator during debug and reply back tomm with any new information.

Best,
Matthew

Hi, Mr.Matthew, thank you for your quick reply.

Instead of using the COMP module to detect an overvoltage condition or overcurrent condition, we creat a hardware circuit on PCB to judge and generate a overvoltage or overcurrent output signal, and the output signal is connected to the ePWM TripZone that corresponds to the ePWM we have controlling the IGBTs. Will we get the same protection effect in this way?

There's a statement going around, if using emulator to connect DSP(F28035) when the whole system is running, the DSP will work abnormally due to electromagnetic interference of large current, once DSP work abnormally, there will be a high probability of IGBT explosion. Do you think this statement is reasonable?

Thank you very much.

Best regards,

Taler

Taler,

Yes, if you have supplied an externally generated signal to the TZ pin(or TZ muxed pin) that will have the same benefit as the internal comparator signal.

In terms of you second question regarding noise interference on the JTAG lines during debug I have seen this be highly dependant on the length of the JTAG connection, both trace and any external wires.  I beleive we recommend that the trace length from the device to the JTAG header be no longer than 6 inches to avoid the need for buffering.  Obviously the closer to the C2000 the better in this regard to avoid antennae effects and coupling with the switching noise from your FETs. 

The next thing to consider is the length of the cable from the JTAG debug probe to the header.  If you are able to use the included cabling that should be fine; any longer routes from the PC host to the debug probe should be done on the USB cable, vs the individual signal traces.

Finally, please also follow the termination guidelines for the signals as spelled out in the device DS to keep the JTAG signals in a known state when the debug probe is not plugged in.

Let me know if you have any concerns with the above to how you have implemented the JTAG connection in your system and we can see if there are any specific concerns.

Best,
Matthew

Matthew,

The wire length from DSP to the JTAG header on the emulator is about 10 inches, and the wire lenght from USB header on the emulator to the USB header on the PC is about 4 feet, in our system.

Even if the emulator or DSP sufferred from electromagnetic interference, will DSP work abnormally or PWM pin output be uncontrolled? Could electromagnetic interference to the emulator be the cause of FETs' explosion?

Taler,

I think the USB length is not a concern, since that cable is shielded, differential pair, etc.  10in vs 6in recommendation is most likely not too big a concern, the emulator speeds we typically see with and XDS100 or 110 should be alright.

The risk with noise on the JTAG signals should only be while you have the emulator connected; assuming that there is an adequate pull down on TRSTn pin to keep the test port held in reset.  Can you confirm the resistor value as well as the location relative to the MCU.

Now, we just need to concern ourselves with noise while we are debugging, but if we have the the TZ pin configured as you suggest even if there is a bad instruction pushed in from the emulation side the worst case should be that the over voltage is tripped, shutting down the FET.  I beleive that most of these registers are EALLOW protected, so as long as that bit is cleared, any write to those registers will not change anything.

In terms of EM effect on the rest of the device, the biggest issues I have seen are noise coupling on the ADC input channels, effecting what the MCU "knows" about the system.  If there is good buffering or decap near the device this can help.  Again, if there are the proper safeguards in place this shouldn't cause a catastrophic issue, just poor system performance.

Best,

Matthew

Matthew,

Thank you for your professional and clear answer.

The schematic and PCB are as follows,

This point confused me, technical reference manual says there is a Internal pull-down resistance inside the DSP TRST pin, so the TRST is alway keep low level  (Reset status) when we don't connect emulater? Obviously not.

Best,

Taler