I’m having a very strange issue… If I use just a battery, I can’t get servo outputs. If I plug in a USB first, then a battery, everything works fine. I took a multimeter and all the voltage rails are showing the proper voltages. If I hook up a battery and then the USB it doesn’t work either. It has to be USB first, then battery. I can’t get any sort of logs out of the FC, is it dead?
I’ve tried reflashing firmware multiple times with full chip erase with the same issue.
judging by the fast flashing LED i’d say your board is hanging in bootloader when you power with batt only. what exact firmware did you flash?
one thing you might try is unplugging all devices connected to your board’s serial ports and see if it does boot to runtime then, if that works it might support the bootloader issue theory.
if it really is a bootloader / uart issue, which is just a wild guess so far, you‘d need to flash an older bootloader. theoretically any version prior to AP3.9.8 will do, as the bootloaders haven’t been updated for quite a while before this release. mind that it‘s important to flash the _with_bl.hex file in dfu mode though, so backup your params before flashing.
admittedly i‘m having a hard time to exactly retrace if the currently available prebuilt binaries of prior firmware versions are built with the corresponding bootloader version, or if it’s the respective firmware code version built with the current bootloader actually. in that case reflashing would‘t help obviously.
maybe someone with more insight on this will chime in, otherwise i‘ll try and reproduce the issue tomorrow.
@cyber_06_wolf i could confirm your issue and i could confirm too that AP3.9.7 does not have the UARTS defined in bootloader. so flashing http://firmware.ardupilot.org/Plane/stable-3.9.7/MatekF405-Wing/arduplane_with_bl.hex in DFU mode will fix the bootloader hangs once serial periphereals are connected and powered.
once you have “downgraded” your bootloader, you can go back to 3.9.8 firmware version by using mission planner’s standard firmware handling. it will update the firmware to 3.9.8. but leave the existent bootloader untouched.
I’ve had sporadic issues with UART defines in bootloaders on another boardtype, but considered it fixed by some register changes a couple of months ago. seems it’s actually not. i’ll try and get it fixed.
I have reproduced this issue on a Pixracer by adding the GPS UART4 to the bootloader. I think we will be able to fix this by ensuring the timeout in the bootloader works properly with a GPS attached
I was also having the same issue, and I can confirm that both the bootloader from 3.9.7 and from the latest ‘plane3.9’ git branch fix the problem. Thanks!
Maybe dumb question:
Instead of downgrading the bootloader, doesn’t it make more sense to upgrade to the bootloader version which is coming with current DEV as this one should contain the fastboot as well as the GPS timeout fix?
Once bootloader is upgraded, Arduplane stable can be flashed via Mission Planner, right?
Hi all,
I installed arduplane 3.9.10 on my f405 wing and uet still has this bootloader issue, same as stated. Do i need to do this procedure to overcome this issue.
One more question, is it mandatory to insert sdcard each flight…
Tq
I’m not sure if still relevant thread for this, but I just flashed 4.0.3 on a Matek F405 STD and experiencing the same exact issue as the video from OP.
Was this fixed in the latest firmware+BL, or do I still need to downgrade?
downgrading the BL was a temporary option only during that short period back in may 2019 when the root cause of the issue wasn‘t exactly clear. if your BL really gets stuck when powered periphereals are connected and disconnecting these during boot fixes the BL hangs, it might be an ancient BL version you‘re running which requires upgrading.
boot loaders getting stuck due to line noise issues has been fixed for quite a while now,
