
I got the plastic and goo off, but can't figure out how to get past to the power stage.
I fried two legs.
http://www-personal.umich.edu/~siegeljb ... 223414.jpg
I'm afraid I don't know how to disassemble the power stage, but I'm interested to know - how did you damage it?
Makes sense, thanks, definitely something to be careful of! By the way you've marked this thread as resolved (you ticked my reply), you should probably undo that since nobody has answered your question.
Pictures would help massively...
I've been doing some testing and I now believe this is an issue with the design of the openinverter SDU board. When the board is booting or programming, it doesn't output any PWM to the inverter, it just leaves these outputs floating. Ideally this should result in all the IGBTs being switched off, but instead, it results in all the IGBTs being simultaneously switched on, basically guaranteeing destruction if HV is applied!
I'm not sure if this is correct.catphish wrote: ↑Wed Apr 06, 2022 9:16 pmI've been doing some testing and I now believe this is an issue with the design of the openinverter SDU board. When the board is booting or programming, it doesn't output any PWM to the inverter, it just leaves these outputs floating. Ideally this should result in all the IGBTs being switched off, but instead, it results in all the IGBTs being simultaneously switched on, basically guaranteeing destruction if HV is applied!
Obviously, in normal operation this isn't a problem, but I have opened an issue on Github to suggest the addition of pull-down resistors. This would protect the inverter from destruction in a few cases, most notably if the STM32 is reset or programmed while HV is applied.
You're right, the openinverter bootloader does set these pins early in the boot cycle, and hopefully persists this during the rest of the boot, or during a firmware update, which should significantly mitigate the problem. Unfortunately, even if it never happens at any other time, resetting the chip will causes at least some period of time when the outputs are in an undefined state and *could* activate all the IGBTs. I would assume this is what happened to js1tr3. Despite the bootloader protection, I still believe it would be prudent to add hardware pull-downs to cover any period when (for any reason) the MCU isn't driving the pins. Doing it in the bootloader seems like more of a workaround in my opinion.EV_Builder wrote: ↑Wed Apr 06, 2022 10:51 pm In the sense of the bootloader checks if there is a pin image in flash if it is it is applied.
The current firmware only instructs the boot loader to pull low precharge and dc switch pins. For the IGBT outputs it depends whether you're using active high or low configuration. In the latter case they need to be pulled high explicitly (maybe not pulled anywhere in active low case, as this mostly drives low impedance optos anyway).catphish wrote: ↑Wed Apr 06, 2022 11:33 pm You're right, the openinverter bootloader does set these pins early in the boot cycle, and hopefully persists this during the rest of the boot, or during a firmware update, which should significantly mitigate the problem. Unfortunately, even if it never happens at any other time, resetting the chip will causes at least some period of time when the outputs are in an undefined state and *could* activate all the IGBTs. I would assume this is what happened to js1tr3. Despite the bootloader protection, I still believe it would be prudent to add hardware pull-downs to cover any period when (for any reason) the MCU isn't driving the pins. Doing it in the bootloader seems like more of a workaround in my opinion.
I believe these 6 vias are the MCU side of the PWM buffer chip, so yes, you should be able to add the resistors there, but do double check. I would normally default to 10k for pull-downs, which should be low enough to prevent the floating, but high enough not to slow down the switching. Sorry for the slightly non-committal reply - I've not tested this myself so caution and testing is advised.
Thank you very much - this should definitely mitigate the problem with accidents during firmware upgrades.
They should be pull-downs (probably 10k) on the lines between the STM32 and the 74HC buffer.EV_Builder wrote: ↑Tue Apr 12, 2022 6:35 pm What is the answer for the SDU? We need pull ups or pull downs?
And do we place them on the inputs of the 74HC or on those outputs...