The px_uploader.py has historically been finicky with catching the bootloader (rev 4), it seems to be a slot machine with odds, and especially affects certain builds, maybe due to power, throttling or something. With bootloader revision 5 (in BROV production since last winter), it fails to catch the bootloader 100% of the time.
The newer uploader.py tool from ardupilot is 100% successful in my experience with catching the bootloader r4 or r5 (chibios or px4)
Fix #397
Fix #396
Fix #393
Before:
Stopping mavproxy
Flashing Pixhawk...
Loaded firmware for 9,0, size: 994256 bytes, waiting for the bootloader...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
attempting reboot on /dev/autopilot...
Timed out trying to catch bootloader!
Please try again.
Waiting to restart mavproxy...
After:
Attempting upload from file /home/pi/companion/fw/ardusub.apj
Stopping mavproxy
Flashing Pixhawk...
Loaded firmware for 9,0, size: 994256 bytes, waiting for the bootloader...
If the board does not respond within 1-2 seconds, unplug and re-plug the USB connector.
Attempting reboot on /dev/serial/by-id/usb-ArduPilot_Pixhawk1_39004B000751393032353736-if00 with baudrate=57600...
If the board does not respond, unplug and re-plug the USB connector.
Found board 9,0 bootloader rev 5 on /dev/serial/by-id/usb-ArduPilot_Pixhawk1-BL_39004B000751393032353736-if00
Bootloader Protocol: 5
OTP:
ChipDes:
family: STM32F42x
revision: 3
Chip:
20016419 STM32F42x_43x rev3 (no 1M flaw)
Info:
flash size: 2080768
board_type: 9 (fmuv3)
board_rev: 0
Identification complete
Erase : [====================] 100.0%
Program: [====================] 100.0%
Verify : [====================] 100.0%
Rebooting.
Waiting to restart mavproxy...
Restarting mavproxy
Complete!
The
px_uploader.py
has historically been finicky with catching the bootloader (rev 4), it seems to be a slot machine with odds, and especially affects certain builds, maybe due to power, throttling or something. With bootloader revision 5 (in BROV production since last winter), it fails to catch the bootloader 100% of the time.The newer
uploader.py
tool from ardupilot is 100% successful in my experience with catching the bootloader r4 or r5 (chibios or px4)Fix #397 Fix #396 Fix #393
Before:
After: