Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

66%
+2 −0
Q&A Disabling breakpoints in real-time section of firmware

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...

posted 9mo ago by Olin Lathrop‭

Answer
#1: Initial revision by user avatar Olin Lathrop‭ · 2023-08-16T16:39:22Z (9 months ago)
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.