Where to start debugging?

Well, I got my tank rover tuned. skid steer tank, Kakute H743, 915 radios, Flysky RC, Sabertooth dual motor esc. CUAV C-RTK2 HP GPS working perfectly. Ran it for a bit, then manual return to my porch, parked it. Finally had a totally functional, working robot. But left power on until LIFEPO4 battery died. I recharged the battery and played with the simulator on another computer in meantime. When battery was charged, I went back to it and tank couldn’t find anything, not GPS, not compass. All the parameters seemed to have changed. GPS was not set, tuning parameters lost. I had saved the params on the PC right after the quiktune was successful, so reloaded those, and double checked GPS and tune settings were OK. Re-wrote to FC. It still wouldn’t work. Then it stopped connecting at all. Can someone help with a methodical approach to debugging this mess? I’m inclined to plug it into the PC via USB and start over. I was reluctant to even post this, but a friend reminded me that you all are the best resource to help me out of this hole. TIA.

the eprom corruption is caused by the h743 running on low voltage, it’s a common issue with that chip. flash the Ardupilot with bootloader firmware using the STMCube programmer application with the flight controller in DFU mode.

2 Likes

Dude, you have made my day!!! It wasn’t just me?!?!!! I know how to reflash the firmware from scratch, but I would need more clarification of “flash the Ardupilot with bootloader firmware using the STMCube programmer application with the flight controller in DFU mode.” I’m still a newbee at this stuff.

1 Like

This file: https://firmware.ardupilot.org/Rover/stable/KakuteH7/ardurover_with_bl.hex

This process. (Matek’s instructions work just as well for the Kakute series)

That battery might be trash. LiFePo cells really don’t do well when over discharged.

3 Likes

make sure to do a full chip erase in stm32 cube programmer before you flash the firmware, corrupted settings can persist if you don’t.

1 Like

You guys are awesome. Annoying problem, but more annoying if the root cause is unknown. I’ll have to spring for a better bms next time. I assume if I have the bms cutoff set to a higher value it will protect the chip. What cutoff voltage is safe? I was thinking of separate batteries for controls and drive motors anyway Common ground, but separate positives. On the controls, I have a 8S LIFEPO4 6AH battery that needs a good bms, probably set to cutoff at 2.5V/cell. From 2.5V to 2.0V is very little actual power anyway.

Guys, I wonder a little after thinking on it some more. I had a 6AH 8S LIFEPO4 pack on it with a cheap BMS. No specs on the bms. This was a test setup, so I didnt bother with a jbd high end bms. But the bms was a “balancing” bms and should have had a low voltage cutoff that would have reacted no different than cutting the power switch to the FC. The cutoff voltage is unknown, but typically is set for around 2V per cell, to protect the pack and the load. That would have shut it off with 16V going to the FC. All I know is it was totally dead when I got to it. I won’t have time to flush the FC and reload it for a week or more and I’ll certainly try that. But how do I keep it from happening again? And does this still sound like the root cause?

how fast the voltage comes up and drops can also make a difference so I have ended up adding another switch for the flight controller so i can connect the battery first and let all the capacitors charge then switch on the flight controller.

I found having high-load devices connected to the flight controller 5v supply can also cause problems causing the 5v to come up slowly. so I moved all my high-load devices to a separate 5v regulator.

I have an arduino relay board in my solar rover that is programmed to manage my rover so it switches devices in sequence when it starts up or if the voltage gets low. just cutting off the battery would cause a lot of problems for me since the motor controller capacitors would take a few seconds to discharge causing it to slowly drop the voltage rather than switching it off.

So, I wonder if having a separate battery for the FC and the motors would be a good idea? Fire up the motor battery first, then the FC. and power down the same way: FC down first and motors second?

I don’t think you need a separate battery, a switch would work to do the same thing, so the flight controller can be switched after the battery is connected, and switched off before its disconnected.

The LIFEPO4 needs a cutoff at 2.5V/cell or even higher. If you go to the limit 2.5V you have to monitor each single cell. For your 8S the cutoff 2.5V/cell is must be not equal 20V as the cells can be discharged different. Also the cutoff limit is depending to the current the system is taking at that time as the discharge curve is extremly rapid.