Post History
I have a similar problem when debugging firmware on a dsPIC that drives a flyback power supply. The switch isn't designed to be on for very long, as eventually the inductor saturates. Usually the...
Answer
#1: Initial revision
I have a similar problem when debugging firmware on a dsPIC that drives a flyback power supply. The switch isn't designed to be on for very long, as eventually the inductor saturates. Usually the transistor blows out when it is left on too long. In normal operation, the PWM hardware in the micro guarantees the switch will be on for only a specified amount of time each pulse. My solution for debugging is to disable the flyback power supply altogether. I have a build-time switch that causes the project to be built for single stepping with an ICD. That switch causes the flyback power supply module to be disabled. That method allows debugging everything except the flyback power supply itself. Debugging the flyback supply is more tricky, but it's just one module. In your case, you can do something similar so that you can debug everything except the LED driver. If you really need to debug that, then unsolder the LED, or input to the LED driver, and watch it on a scope instead. If you need to do this often, modify your engineering unit with a jumper or something to disconnect the LED from the drive signal. Another possibility is to use a current-limited power supply for the LED section during debugging. Set the current limit so that the LEDs can be left on indefinitely without harm. If you're debugging the firmware logic, you probably don't need the full brightness from the LEDs.