I see there's a stand-alone C++ app to upload images, a java one would be nice.

Currently we can't effectively distinguish between different boards attached to the same host, however, e.g. the safety testing does depend on this. We should expose the serial via the boatloader / USB descriptor.

Seems like the latest commit (3c43ab7) / PR #147 breaks the FW upgrade with QGC on RDDRONE-FMUK66.

I tried a few builds, everything was working with ddf1d9d but I now get this with the latest commit:

FYI @davids5 @igalloway

I'm getting the following error message while running the make command.
make (e=2): "Can't find the file".
make[1]: *** [build/nxphlitev3_bl/bl.o] Error 2
make: *** [nxphlitev3_bl] Error 2

I have noticed that when rebooting into the bootloader from the main application, the bootloader seems to get stuck in the blocking_handler(), which is called by the usb_fs_wkup_isr. Only unplugging and replugging the USB cable seems to solve the problem.

Here is the typical scenario that I experience:

1. Using the NSH console on USB. Board registered on /dev/ttyACM0
2. Board powered separately from USB
3. Run the px_uploader.py script with the port as /dev/ttyACM0
4. Board reboots into bootloader (as evidenced by the flashing bootloader LED)
5. Board is reregistered on USB as /dev/ttyACM1
6. The board doesn't respond if try and run px_uploader.py with the port as /dev/ttyACM1
7. Only unplugging and replugging the USB solves the problem.

Any ideas why the bootloader seems to get stuck here? Could it have something to do with an interrupt not being handled correctly?

The BOARD_FORCE_BL_PORT and PIN is PORTE GPIO14. This is GPIO_GPIO0_INPUT in board_config.h, so it maps to PWM1. That means we get a bunch of pulsed on PWM1 in the bootloader.
These pulses cause ESCs to initialise, which means you can't do proper ESC calibration.
We need to move this functionality to another pin for FMUv4. The only real question is which pin.

Add ability to perform Pixhawk firmware update via UART without USB.

First requested by ArduPilot/ardupilot#1938

BUG

I have an mRo X-2.1 which is connected on TELEM 1 (UART-2) to a 433MHz Radio. When the Flight Controller is only USB Powered, the Radio does not get any Power, so the RX Line of UART-2 will be LOW. This causes the X-2.1 to stay in Bootloader Mode. As soon as the Connection to the Radio is removed or a Battery is connected - even only for less than a second - the Device will Boot. I have seen that the configuration in hwconfig.h is identical to FMUv2 Devices but I tried to Short UART 2 (Serial 1) RX - GND on a AUAV-X2 as well as on a Dropix v2.1 Controller and they do both boot.

there is a sentence :
RCC_AHB1ENR = 0x00100000; // XXX Magic reset number from STM32F4x reference manual
in the board_init() In the main_f4.c.
However ,i found it is wrong after look up the stm32F4xx refence manual.

per (https://pixhawk.org/dev/bootloader_update) the current release is 2014-02-03 / rev 4.0. Per this commit (a909811) the version was bumped from v4 to v5. If we consider this stable can we get a v5 release please?

@davids5 We should work out if we can support boot loading first via USB, then via CAN, then go to the app.

Hi!
When I try to build Bootloader through the PX4 Toolchain on the command line through the 'make' or "make px4fmuv5_bl" commands, the compiler throws an error "cannot find -lopencm3_stm32f4"

I put the log below

$ make px4fmuv5_bl
(./Tools/check_submodules.sh)
Checked libopencm3 submodule, correct version found
Checked lib/kinetis/NXP_Kinetis_Bootloader_2_0_0 submodule, correct version found
make -C libopencm3 lib
make[1]: вход в каталог «/cygdrive/c/PX4/home/Bootloader/libopencm3»
  GENHDR  include/libopencm3/stm32/f0/irq.json
  GENHDR  include/libopencm3/stm32/f1/irq.json
  GENHDR  include/libopencm3/stm32/f2/irq.json
  GENHDR  include/libopencm3/stm32/f3/irq.json
  GENHDR  include/libopencm3/stm32/f4/irq.json
  GENHDR  include/libopencm3/stm32/f7/irq.json
  GENHDR  include/libopencm3/stm32/l0/irq.json
  GENHDR  include/libopencm3/stm32/l1/irq.json
  GENHDR  include/libopencm3/stm32/l4/irq.json
  GENHDR  include/libopencm3/lpc13xx/irq.json
  GENHDR  include/libopencm3/lpc17xx/irq.json
  GENHDR  include/libopencm3/lpc43xx/m4/irq.json
  GENHDR  include/libopencm3/lpc43xx/m0/irq.json
  GENHDR  include/libopencm3/lm3s/irq.json
  GENHDR  include/libopencm3/efm32/tg/irq.json
  GENHDR  include/libopencm3/efm32/g/irq.json
  GENHDR  include/libopencm3/efm32/lg/irq.json
  GENHDR  include/libopencm3/efm32/gg/irq.json
  GENHDR  include/libopencm3/efm32/hg/irq.json
  GENHDR  include/libopencm3/efm32/wg/irq.json
  GENHDR  include/libopencm3/efm32/ezr32wg/irq.json
  GENHDR  include/libopencm3/sam/3a/irq.json
  GENHDR  include/libopencm3/sam/3n/irq.json
  GENHDR  include/libopencm3/sam/3s/irq.json
  GENHDR  include/libopencm3/sam/3u/irq.json
  GENHDR  include/libopencm3/sam/3x/irq.json
  GENHDR  include/libopencm3/sam/4l/irq.json
  GENHDR  include/libopencm3/sam/d/irq.json
  GENHDR  include/libopencm3/vf6xx/irq.json
  BUILD   lib/stm32/f0
  AR      libopencm3_stm32f0.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f0.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f0.a] Error 1
  BUILD   lib/stm32/f1
  AR      libopencm3_stm32f1.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f1.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f1.a] Error 1
  BUILD   lib/stm32/f2
  AR      libopencm3_stm32f2.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f2.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f2.a] Error 1
  BUILD   lib/stm32/f3
  AR      libopencm3_stm32f3.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f3.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f3.a] Error 1
  BUILD   lib/stm32/f4
  AR      libopencm3_stm32f4.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f4.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f4.a] Error 1
  BUILD   lib/stm32/f7
  AR      libopencm3_stm32f7.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f7.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32f7.a] Error 1
  BUILD   lib/stm32/l0
  AR      libopencm3_stm32l0.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32l0.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32l0.a] Error 1
  BUILD   lib/stm32/l1
  AR      libopencm3_stm32l1.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32l1.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32l1.a] Error 1
  BUILD   lib/stm32/l4
  AR      libopencm3_stm32l4.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32l4.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_stm32l4.a] Error 1
  BUILD   lib/lpc13xx
  AR      libopencm3_lpc13xx.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lpc13xx.a: No such file or directory
make[2]: *** [../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lpc13xx.a] Error 1
  BUILD   lib/lpc17xx
  AR      libopencm3_lpc17xx.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lpc17xx.a: No such file or directory
make[2]: *** [../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lpc17xx.a] Error 1
  BUILD   lib/lpc43xx/m4
  AR      libopencm3_lpc43xx.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lpc43xx.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lpc43xx.a] Error 1
  BUILD   lib/lpc43xx/m0
  AR      libopencm3_lpc43xx_m0.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lpc43xx_m0.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lpc43xx_m0.a] Error 1
  BUILD   lib/lm3s
  AR      libopencm3_lm3s.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lm3s.a: No such file or directory
make[2]: *** [../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lm3s.a] Error 1
  BUILD   lib/lm4f
  AR      libopencm3_lm4f.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lm4f.a: No such file or directory
make[2]: *** [../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_lm4f.a] Error 1
  BUILD   lib/efm32/tg
  AR      libopencm3_efm32tg.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32tg.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32tg.a] Error 1
  BUILD   lib/efm32/g
  AR      libopencm3_efm32g.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32g.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32g.a] Error 1
  BUILD   lib/efm32/lg
  AR      libopencm3_efm32lg.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32lg.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32lg.a] Error 1
  BUILD   lib/efm32/gg
  AR      libopencm3_efm32gg.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32gg.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32gg.a] Error 1
  BUILD   lib/efm32/hg
  AR      libopencm3_efm32hg.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32hg.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32hg.a] Error 1
  BUILD   lib/efm32/wg
  AR      libopencm3_efm32wg.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32wg.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_efm32wg.a] Error 1
  BUILD   lib/efm32/ezr32wg
  AR      libopencm3_ezr32wg.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_ezr32wg.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_ezr32wg.a] Error 1
  BUILD   lib/sam/3a
  AR      libopencm3_sam3a.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3a.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3a.a] Error 1
  BUILD   lib/sam/3n
  AR      libopencm3_sam3n.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3n.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3n.a] Error 1
  BUILD   lib/sam/3s
  AR      libopencm3_sam3s.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3s.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3s.a] Error 1
  BUILD   lib/sam/3u
  AR      libopencm3_sam3u.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3u.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3u.a] Ошибка 1
  BUILD   lib/sam/3x
  AR      libopencm3_sam3x.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3x.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam3x.a] Ошибка 1
  BUILD   lib/sam/4l
  AR      libopencm3_sam4l.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam4l.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_sam4l.a] Error 1
  BUILD   lib/sam/d
  AR      libopencm3_samd.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_samd.a: No such file or directory
make[2]: *** [../../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_samd.a] Error 1
  BUILD   lib/vf6xx
  AR      libopencm3_vf6xx.a
C:\PX4\toolchain\gcc-arm\bin\arm-none-eabi-ar.exe: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_vf6xx.a: No such file or directory
make[2]: *** [../Makefile.include:37: /cygdrive/c/PX4/home/Bootloader/libopencm3/lib/libopencm3_vf6xx.a] Error 1
/bin/sh: line 0: [: too many arguments
make [1]: exit the directory «/cygdrive/c/PX4/home/Bootloader/libopencm3»
make --no-print-directory -f  Makefile.f7 TARGET_HW=PX4_FMU_V5 LINKER_FILE=stm32f7.ld TARGET_FILE_NAME=px4fmuv5_bl
arm-none-eabi-gcc -o build/px4fmuv5_bl/px4fmuv5_bl.elf build/px4fmuv5_bl/bl.o build/px4fmuv5_bl/stm32/cdcacm.o build/px4fmuv5_bl/stm32/usart.o build/px4fmuv5_bl/main_f7.o  -std=gnu99 -Os -g -Wundef -Wall -fno-builtin -I./libopencm3/include -I./. -ffunction-sections -nostartfiles -lnosys -Wl,-gc-sections -Wl,-g -Werror -g -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -DTARGET_HW_PX4_FMU_V5 -Tstm32f7.ld -Llibopencm3/lib -lopencm3_stm32f7 -lopencm3_stm32f4 -DSTM32F7
c:/px4/toolchain/gcc-arm/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lopencm3_stm32f7
c:/px4/toolchain/gcc-arm/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lopencm3_stm32f4
collect2.exe: error: ld returned 1 exit status
make[1]: *** [rules.mk:41: build/px4fmuv5_bl/px4fmuv5_bl.elf] Error 1
make: *** [Makefile:116: px4fmuv5_bl] Error 2

For FMUv6 let's use ITCM (flash accelerator) from the beginning.

#126
https://github.com/PX4/Bootloader/tree/pr-itcm_hacks

If open the Mission Planner Firmware Window on PC, then plug a FMUv5 hardware(Pixhawk4, Pixhawk4Mini) on USB port, PWR LED will keep blink, not boot up firmware whether PX4 or Ardupilot.

In FMUv3, it have 5 seconds delay, then will successful boot up.

Current statue makes lots of users very confuse.

Turns out this is actually more an FMU item, the bootloader is fine, just too new:

PX4/PX4-Autopilot#140

In some cases, the verify phase of the firmware update is very slow (takes more than a minute).

If you are reporting an instance of this problem, please include:

• Uploader being used (python or Windows native)
• Operating system version (and 32/64-bit)
• Is the operation always slow, or only sometimes?
• Any other issues (verify failures, timeouts, etc) that you see as well.

From inside nsh when using the reboot -b command once entering the bootloader on f7 it does not stay in it when an application is already present. On f4 on the other hand it does stop in the bootloader until it does not get flashed or re-powered which is the expected behavior.

Tested on FMU v5 powered over USB.

FYI: @davids5 @bkueng

@davids5 I can't seem to be able to power on via the button only and it feels generally confusing from an user perspective.

There is check in jump_to_app() here:
https://github.com/PX4/Bootloader/blob/master/bl.c#L269

That checks if start address of outside of flash (<0x08008000 for FMUv5) and breaks jumping.
But when using ITCM on PX4FMUv5 with STM32F7 this address is at alias address 0x00208000.

Workaround is dirty hack in vector table (not PX4 firmware):

_vectors:
        .long       __main_stack_end__
        .long       Reset_Handler + 0x08000000 - 0x00200000  // <-- to pass check in PX4 bootloader

Not sure if it works 100% correct, but app starts (not PX4 firmware).

Probably that was a reason why ITCM is not used here?
https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v5/nuttx-config/scripts/ld.script#L121

Newer Macs is firstly subjective but in the tests I did, as I rolled back the hardware and software of the Mac computers being used it started working again.

Problem: The V5 bootloader doesn't recognize the board from QGC when trying to flash PX4 (or Ardupilot) firmware. I tried with 2x MRO Pixhawk 1, 1x Generic Pixhawk 1, 5+ cables, 3x computers and several USB-C adapters.

When on bootloader v4 there were no problems on any of the machines. The issue becomes that you can't upload fmu_v3 firmware unless upgrading the bootloader (unless doing it manually) so when flashing the bootloader (all done via QGC 4.0.11 and PX4 v1.11.2), the ability to upgrade the firmware afterwards from QGC is no longer possible. It does not recognize the chip size, just hangs at Found Device: PX4 FMU V2 9 (see image). It also doesn't give the connected to boot loader on the next line (I tried QGC daily as of today and it also did not work).

Building and uploading the firmware from command line does work but it does ask 5-7 times to remove the USB (which I didn't do, just left it) and then it will flash without issue.

If I load the Chibios boot loader on the Pixhawks any of the computers will pick them up instantly for upgrading the firmware (PX4 works fine this way), only when putting the v5 firmware back does it stop working.

This is where the newer Macs get to be part of the problem. On macOS Big Sur and Catalina (and usb-c) Macs, the problem above is present 99% of the time. It's not 100% because after repeatedly doing it, occasionally (rarely) I could get it to show up but this was 1-2%.

Going back to an older Mac with High Sierra and Mojave and all worked (or something to do with USB-C?)

The current fix for the time being is to get the Chibios loaded up and just leave it on there. No issues with that on any machines but obviously not ideal.

It's strange and I don't have it nailed down to something exact but it is somewhere lurking in the above but I would imagine it will start to effect more people.

I'd rule out hardware as I did this across multiple machines and units and cables (and versions of QGC) and making the switch to a different bootloader does fix it.

Boards that are using STM32F7 MCUs have the wrong definition BOOT_DELAY_ADDRESS inside hw_config.h
https://github.com/PX4/PX4-Bootloader/blob/master/hw_config.h#L345

Also, other MCUs should be check because this is probably a copy/paste error from F4 MCUs.
The problem is happening because of the different vector table sizes for different MCUs.

Let's discuss here how it should be solved.

I feel like my px4 is bricked. Dfu can't see my device, but dmesg see:

[64435.467919] usb 1-1: new full-speed USB device number 38 using xhci_hcd
[64435.616742] usb 1-1: New USB device found, idVendor=26ac, idProduct=0011
[64435.616746] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[64435.616748] usb 1-1: Product: PX4 BL FMU v3.x
[64435.616749] usb 1-1: Manufacturer: 3D Robotics
[64435.616751] usb 1-1: SerialNumber: 0
[64435.617376] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[64440.171525] usb 1-1: USB disconnect, device number 38
[64441.607822] usb 1-1: new full-speed USB device number 39 using xhci_hcd
[64441.756909] usb 1-1: New USB device found, idVendor=26ac, idProduct=0011
[64441.756914] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[64441.756917] usb 1-1: Product: PX4 FMU v2.x
[64441.756920] usb 1-1: Manufacturer: 3D Robotics
[64441.756922] usb 1-1: SerialNumber: 0
[64441.757674] cdc_acm 1-1:1.0: ttyACM0: USB ACM device

$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

However, I can flash firmware via QGC. It flashes, but after reboot PX4 doesn't accept any command fro QGC

Bootloader code configures vbus pin with pulldown enabled.

#ifdef INTERFACE_USB
/* enable GPIO9 with a pulldown to sniff VBUS */
rcc_peripheral_enable_clock(&RCC_AHB1ENR, RCC_AHB1ENR_IOPAEN);
gpio_mode_setup(GPIOA, GPIO_MODE_INPUT, GPIO_PUPD_PULLDOWN, GPIO9);
#endif

According to stmf40x manual pullup/pulldowns must not be enabled for 5v pins.
6. To sustain a voltage higher than V DD +0.3, the internal pull-up and pull-down resistors must be disabled.
The documentation mentions 1k1 pulldown for VBUS (which obviously has to handle 5v), but it may be totally separate from normal GPIO pulldown.

In contrast to that, PX4Firmware doesn't enable pulldown. OTGFS vbus sensing configuration is also different. I see OTGFS_GCCFG_NOVBUSSENS bit set in px4firmware. OTG_FS_GCCFG_NOVBUSSENS is not set in libopencm3.

The symptoms of this problem are that the uploader is started, but sits at the 'waiting' stage forever, even when the board is booted. Causes include:

• The COM port that the bootloader is attached to is outside the range that the uploader is checking for.
• The Windows driver is not attaching to the bootloader (e.g. driver is not installed correctly)
• Another serial device in the search list is too slow, and the uploader misses the bootloader sometimes.

If you are reporting an instance of this problem, please include:

• Which uploader(s) you have tried (python or native .exe version)
• Version of Windows (include 32 or 64-bit configuration)
• Is there COM port assigned to the PX4FMU after the firmware has loaded? If so, what number?
• If you have tried the steps in http://answers.px4.ethz.ch/question/76/how-do-i-force-update-the-firmware-on-px4fmu/ did this help?

Since updating to the latest bootloader, I have the problem that the board always waits in the bootloader until the timeout has elapsed, even if the USB cable is not connected - the board is powered separately.

It seems that this behaviour was introduced in commit 1770cfd.
I understand that we should not be pulling the Vbus sense line low using the internal pull downs. But leaving it floating seems to result in the check for whether the Vbus is connected to be always true.
The check if (gpio_get(GPIOA, GPIO9) != 0) in main_f4.c always returns true.

I think if we are supposed to be using the hardware detection of the VBUS sensing, then we should probably be setting the VBUSBSEN bit in the OTG_FS_GCCFG register. But I haven't worked out how we are supposed to then use this to detect the USB.

OTG_FS_GCCFG |= OTG_GCCFG_VBUSBSEN;

The other option is to always disable the hardware VBUS sensing (always set the NOVBUSSENS bit) and then just read the PA9 pin as usual.

@ksschwabe This is to track wireless boot loading. Are you aware about this board with Wifi?
https://pixhawk.org/modules/pixracer

Its working now really well with UDP / Wifi, much easier than Bluetooth and it has 100m range with just the very basic PCB antenna. Also note the huge cost reduction and state of the art sensors.

It that of interest to you? What about wireless boot loading and the re-try logic?

px4pipbl.pdf

There is an issue with the PX4MiniAIO (and other PX4-V1 boards) where the bootup can get stuck when a receiver connected to the SBUS/PPM-IN pin (PA10) is not receiving data from a transmitter. If that PA10 pin is pulled low at startup, the bootloader code goes into a "wait" mode and stays there until the pin goes high. It seems that only some receivers work this way. When I tested with an OpenLRSng-DTFUHF receiver, its PPM output was not pulled low when not receiving data. Others, however, have reported the issue where the PX4MiniAIO board will not boot up when the transmitter is not turned on.

In the bootloader code, this functionality is described in the comments as "forcing the bootloader." Interestingly, there is a similar functionality for the PX4-V2 (Pixhawk) boards, but it was disabled in response to PX4-Bootloader issue #46. It seems reasonable, then, that this functionality should also be disabled in the PX4-V1 code. This is accomblished by commenting out the "#BOARD_FORCE_BL..." lines in the "hw_config.h" file, as shown here:

/*
 * Uncommenting this allows to force the bootloader through
 * the PPM-in pin. Some receivers pull their PPM output low
 * when the transmitter is off, resulting in a stuck bootup,
 * so this feature is best disabled.
 *
 * # define BOARD_FORCE_BL_PIN             GPIO10
 * # define BOARD_FORCE_BL_PORT            GPIOA
 * # define BOARD_FORCE_BL_CLOCK_REGISTER  RCC_AHB1ENR
 * # define BOARD_FORCE_BL_CLOCK_BIT       RCC_AHB1ENR_IOPAEN
 * # define BOARD_FORCE_BL_PULL            GPIO_PUPD_PULLUP
 * # define BOARD_FORCE_BL_STATE           0
 */

I have a branch with this modification posted here. I can post it as a PR if this change is wanted.

I also have information posted here: http://www.etheli.com/APM/PX4MiniAIO

--ET

This might also be the right occasion to register an USB ID ourselves. The goal is to make "fixed" hardware easily identifiable and allow the use of the full flash space for new boards without jumping through hoops.

hello ,davids5 !
I used STLINK-V2 full chip erase px4flow board and build px4 Bootloader file (2015-03-27 Bootloader-master)
, make all Bootloader for px4flow_bl.elf and px4flow-bl.bin , build Successful and connect STLINK-V2 ,then STLINK-V2 program px4flow_bl.bin to px4flow board in Bootloader(c/px4/Bootloader).restart the board show "USB device not recognized" . the pxflow board
didn't communicated with PC USB, The three LED is lit.
is the problem Bootloader of code jump to app?Ho to process the problem?

Thank you very much for your help!

Email:[email protected]
2015-4-1

Hi!
I am trying to flash the STM32F427 with the px4fmuv2_bl.bin which has worked flaless before.
But with the latest version from github something goes wrong.
The board turns up as PX4v3 in MP but is should be PX4v2.
And when I flash the STM32F100 the heartbeat-led doesnt start to blink blue.

This all ends upp with problems loading the FW via MP and a board with non function IO ports.

If I use old bootloaders everything works fine!
I am using ST-linkv2 via JTAG to flash the MCU:s

Does enyone know if something has changed in the code or am I missing something

Kind regards!

Paul

I built px4fmuv5_bl for my STM32F765VI but it did not works.

Then I have found that the bootloader uses the library for STM32F4 instead of STM23F7.

With a few modification (some register addresses and bit masks) I can run the bootloader and flash the firmware via UART, but USB is more complicated than UART and I haven't solved the problem yet.

Have you guys tested on an F7 board yet?

Problem:
Currently, when data from the px_uploader to the bootloader is not transmitted correctly the crc check in the bootloader fails and the firmware update therefore fails as well. This basically never happens when using the USB interface but it happens frequently when using the UART interface with relatively high baudrates.
When using a baudrate of 921600 we frequently see this problem and updating firmware via this interface is therefore very unreliable.

We were thinking about making the protocol between the bootloader and the px_uploader more robust so that we don't need to rely on 100% correct data transmission in order to update the firmware. Mostly it's just a few bytes which are not transmitted correctly but that is enough to make the update fail in the current state. We were thinking of adding at least a couple of retries.

@davids5 What do you think about this?

Add ability to perform Pixhawk firmware update via UART. I hear this is possible already with a UART-only build version but we need a USB+Serial single image. This assumes it's possible to squeeze both into the constrained size.

@davids5 A firmware update resets the RTC. Just starting the bootloader does not. It would be great if we could retain the RTC, unless there is a functionality / safety issue associated.

This is below the importance of the SD write performance though, so should come after.

FMUv5 bootloader used the wrong status LED signaling bootloader activity as marked on the case.
Blue s/b activity and Amber in bootloader.

The current situation is that flashing via QGroundControl and/or the PX4 build system is not possible.

The architecture of flight controllers that use the H750 (or other ST value-line) MCU's is different, the value-line CPUs have limited flash for a vendor specific, and often secure, bootloader that provide functionality for exposing the external flash that is connected via QSPI. The PX4 code runs directly from external flash when the CPU is in memory mapped mode. Bootloaders often provide other functionality, such as USB Mass-Storage or USB-DFU support for firmware updates, methods to boot from SD cards, dual boot functionality, diagnostics, methods to erase/reset config/firmware/entire external flash, etc. Vendors also may use 'Option bytes' that enable ST's secure boot functionality.

I propose that support for the H750 with external QSPI flash is added to the PX4 bootloader codebase, and that it's build-scripts are updated so that it can build an EXST format images.

== Background ==
The H750 has a single 128k page of flash which contains the vendor's bootloader.

In the case of the H7EXTREME the PX4 firmware has to be updated using DFU mode of the SPRacing bootloader. The vendor bootloader is non-upgradable and is write protected. It should not be erased.

== Boot process ==

The PX4 boot process is currently:

1. power on
2. run vendor bootloader code
3. vendor bootloader code looks for external flash chip and 'loadable firmware', copies it to ram and executes it.
4. For PX4 the 'loadable firmware' the SPRacing SSBL is used, which enables memory mapped mode and jumps to whatever code is on the flash chip at the 'correct location'. The 'correct location' was as-defined by the PR for PX4 that added support for the SPRacingH7EXTREME - PX4/PX4-Autopilot#15385 and implemented in the SSBL code and the PX4 linker scripts.

The SSBL is here:

https://github.com/spracing/ssbl

The SSBL, when built, generates a binary image with an EXST block which contains an MD5 hash for firmware image for validation (validation only, no crypto keys involved).

The details of the EXST format are here:

https://github.com/betaflight/betaflight/blob/master/docs/EXST%20bootloader.md

The code/build steps for getting from a .elf to a .bin with EXST block is here:

linker script: https://github.com/spracing/ssbl/blob/master/src/main/link/stm32_ram_h750_exst_post.ld#L3-L28

makefile: https://github.com/spracing/ssbl/blob/master/Makefile#L434-L479

The definition of the 'correct address' is here:

https://github.com/spracing/ssbl/blob/master/src/main/main.c#L67-L68

i.e 0x90100000.

The PX4 firmware address is influenced by the flash chip's page and block erase boundaries and the MCU's MPU granularity and the desire to reserve so space at the start of the flash chip for future use, such as partitioning information, etc.

== Key Implementation points ==

• Add SPRacingH7EXTREME target (just so it builds).
• Add support for building EXST firmware image.
• Add support for reading/writing the PX4 firmware to QSPI external flash instead of internal flash
• Add support for enabling memory mapped mode and jumping to PX4 firmware from external flash instead of internal flash.

"build instructions" link is broken/ not set properly

Hello,
We are planning to use this on one of our drones (fmuv5x). I can see that the last release was 6 years ago. Since then some important features like secure boot have been implemented. Therefore, I wanted to know if the master build of the bootloader is working stably for fmuv5x.

PS.
Please provide any documentation on how to use this.

There is a problem in the current bootloader logic (at least on the Px4FMU board) where it will not boot. I have found the problem and put in a fix in my pull request for parallel USB and USART bootload ability. If you don't merge that in soon, perhaps just make patch based on my comments below and push that so that if someone does update their bootloader off the master branch they don't have a problem.

The problem is in cdcam.c and looks as if it was introduced on 2nd February 2015. The offending line of code is this:
static void cdc_disconnect(void)
{
usbd_disconnect(usbd_dev, true);
usbd_dev = NULL;
}

Previously, it just called usbd_disconnect(true);

The problem is that this cdc_disconnect(void) function is called in cfini which is called in jump_to_app(). When jump_to_app() is called in the if(try_boot) section of code, the usbd_dev has not yet been assigned. It is assigned only by cinit().

To fix this error I have just moved the following code to be above the if(try_boot) code section.

/* configure the clock for bootloader activity */
rcc_clock_setup_hse_3v3(&clock_setup);

cinit(BOARD_INTERFACE_CONFIG_USB);

Hello everyone,

some of the supported platforms are relatively close to their maximum sizes, for example, PX4_PIO_V2 with 3484 bytes (85% of 4096). If been added new features this can become a problem. One way of reducing the program size is to use the option "flto" the GCC.

Below follows some results:

personal project

This option "flto" could be used in the future if the sizes of the programs become a problem.

when i use dfu tools to update bootloader ,it's not work

1. GENERATE a DFU file from BIN files,Version ID confused me,In dfu Demo my board Version ID is 2200,so whitch id I generate a DFU file with version id 2100 or 2200 is correct.
   2.Etheir Version id 2100 or 2200 have used,replug in after update successful,device as "PX4 FMU" shows in serial port ,then suddenly unshown forever......
   3.I have tried Qground to download firmware , qg can found px4 board , but it cann't found bootloader,after i plug in server times,it finally found and download successful,but still show in serial port a few seconds.

No servo outputs and Starting PX4IO beep continously while flashing pixhawk v1.9.0.

Tried using V1.11 which works perfectly.
Since I am working on fixed wings and also need a HiL environment for the same, I have to stick on to V1.9.0.

Could someone help me ASAP.

my mail id is [email protected].

Its bugging my head for a long time now

I am relatively new to pixhawk.

Need to add auto dependencies on header files.

for instance `touch hw_config.h' should cause a rebuild as should editing any other h file in the build.

hi, when i use usb to update nuttx, it's ok,
but when i use uart to update nuttx, it's not ok, so i debug the bootloader, i find that the function uart_cout() can't output anything, may be there is somewrong with this serial port 2.

Just a note to document that a vendor is using Board ID 66. It’s a closed PX4 fork, and for some reason they don’t want to PR, but ideally we need to document that the ID is in use.

@davids5: I noticed that the clock setup for the FMUV5_bl is not using the OSC_FREQ define in the clock config.

/* standard clocking for all F7 boards */
static const struct rcc_clock_scale clock_setup = {
	.pllm = 8,
	.plln = 216,
	.pllp = 2,
	.pllq = 9,
	.pllr = 2,
	.hpre = RCC_CFGR_HPRE_DIV_NONE,
	.ppre1 = RCC_CFGR_PPRE_DIV_4,
	.ppre2 = RCC_CFGR_PPRE_DIV_2,
	.power_save = 0,
	.flash_config = FLASH_ACR_ICE | FLASH_ACR_DCE | FLASH_ACR_LATENCY_5WS,
	.apb1_frequency = 54000000,
	.apb2_frequency = 108000000,
};

Going through the calculation it looks like the OSC_FREQ is indeed 16MHz (as defined in hw_config.h) - this would mean that pllm should be OSC_FREQ and plln should be 432. Is this correct?

I am surprised that the OSC_FREQ is 16MHz. Is it not using the standard 24MHz crystal that we use on the other boards?

hi，I am fresher of px4，and now I have a board（stm32h7），but I didn't find any bootloader file suite this kind of board? So, can you tell me which file I could down for my stm32h
7 board?
Thank's a lot!

This would be helpful to flash QA information by the host.