does the H743 have internal brownout detection? I used to have a similar problem with AVR328p chips corrupting memory if they brown out, but you could set an internal fuse that would hold it in reset if the voltage was too low to avoid the problem. I wonder if matek is just not setting this fuse on the chips.
I know esp32 chips can do it
shoulnd’t the motor controler just send back current to the battery and not to the whole system ?
My consern there is that those caps can hold up any peripherals that need low current and left them in unkown state. On Ublox 6-7 it could happens a lot and need cold start to clear up.
When I was first testing I didn’t have any relays so everything was just wired on like an aircraft, so when the battery ran out the BMS would cut it off, but that would leave power in the capacitors with nowhere to go and would power it for another few seconds causing a lot of problems.
Now I don’t use the BMS cut off, I have a main relay that cuts power to the 48v regulator and a second that cuts power to the flight controller directly so it can get shut down in stages with the main 48v last. Then the companion controller goes to sleep, at 17uA it will last forever so I don’t need to switch it off. It has a second small 48v>5v regulator to keep it going when the main 48v is turned off and a backup battery so even if I loose main power it should still be able to navigate and communicate.
yes and no, the STM32H743 is part of the STM32H7xx family and this is Part of the STM CORTEX M7 core family. All these have also a POR (power on reset) and a BOR (brown out reset) which can be enabled and disabled by a so called option bytes.
On H743/753 the BOR is disabled by default.
But the option bits and bytes can be enabled, disabled, changed by the STM32cubeprogrammer.
At least this is what the general description of the features of this STM software claims
I just can’t check this as I don’t have any real STM32 board only ESP32
It probably wouldn’t be a good idea to enable that feature on everything, having an aircraft reset due to a power glitch would be bad . But this would be a good feature to add to rover if it can be selectively enabled.
It can’t be changed on runtime of the system only during the system flashing prozess. But it can be done by any user at any time and don’t need it to be done on the first time of the system setup.
So it is not done by Matek but it can be done by yourself.
Yes it might be problematic on a plane but it is also problematic if it is not done and afterwards the memmory is corrupted. Both can result in a crash.
But the first failure is the power glitch itself. So the best is first to ensure that power glitches will not reach the controller.
But all this depends to the use case. While a plane can secure land without engines a quad will fall down like a stone and a helicopter is some where in between if it can manage autorotation landing.
It would be interesting to see if all manufacturers set them the same way. It’s worth experimenting with it to see if it can help with reliability.
I wonder if @CraigElder might have some insight on the STM32 brownout protection feature or circuit design(s) to prevent such issues.
The option is here, looks like the matek is set to level 0.
https://www.st.com/resource/en/datasheet/stm32h743vi.pdf
level 3 would probably be safe enough to set, 2.6v is pretty low, I can’t imagine any scenario where I would need it to operate lower than that.
It would be interesting to see what the cubes are set to.
I’ve ping’d Mateksys (an AP Partner) about this and pointed them at this thread
