Open chuckhacker opened 2 years ago
I'd love to know this too, so pinging some contributors who might know, @osresearch, @wormyrocks, @colinoflynn.
Well presumably the digital electronics are just sending PWM signals to the blower motor, so I would expect it to ether stop entirely or just keep sending the same signal. It might cause the blower to go high as a fail safe condition, as more air is better than no air, but I can't think of any obvious way that you could damage the blower, it won't spin faster than it's designed to go.
I can't comment on impact on the device long-term, but I did set tons of break-points live with no obvious damage (smoking electronics).
Thank you both for the replies :)
@colinoflynn, what was the behavior of the device while the execution was stopped? Did it keep blowing air at a constant speed? What happened after resuming execution?
It's been a while, IIRC yes it just got stuck at some constant speed. The PWM etc is all running as a peripheral, so when the CPU core is stopped that is just going to be left at the last value.
So I can confirm that no harm is done to the device by halting execution, the blower stops during it, and if you stop and resume it while it's idling it'll halt again in an error function but after resuming from that it's fine.
That said, I cannot recommend trying to debug it- it seems obvious in retrospect, but debugging decompiled firmware is ridiculously tough, and I am in awe that anyone is capable of it.
I tried to disable backup rate(machine-initiated breaths if you pause breathing) in ASV mode, and/or add the EasyBreathe exhale slope to S mode with EasyBreathe off, but I only managed to identify where the target pressure values are written, without figuring out where they're computed or how to alter any of the behavior. Ugh.
Is it safe to set a breakpoint in the breath control loop while the device is running live? Worried about damaging my device, thanks.