I’m trying to upload the PX4 F/W on STM32F446 board. (Nucleo-F446)
I uploaded the bootloader and can check the device recognition on the device manager. (PX4 FMU4)
However, a problem occurred when I upload the F/W on my board. I attached the screenshot.
The flash memory of STM32F446 is consist of 8 sectors (0~7) and 512 KB, so I revised the bootloader source codes(hw_config.h, main_f4.c), but it was not solved.
When I read the memory, it was erased. so, I think it cannot send the return signal correctly since memory configuration.
I don’t know what should I do.
In addition, what is the board type? how do I set it up?
BOARD_TYPE is simply a number used to identify the type of the board. When you upload a .px4 firmware file to a board, a check is done to ensure that the “board_id” in the .px4 file matches the
BOARD_TYPE of the bootloader that is flashed on that particular board.
When you compile a firmware, the .px4 file is created from a “prototype” JSON file. These are found in the
Firmware/Images/ directory of the Px4/Firmware repo. As an example, here are the contents of the px4fmu-v2.prototype file
"description": "Firmware for the PX4FMUv2 board",
I do not know whether there is any particular format or scheme that is used to assign a type number to a board, or whether it is completely random. Perhaps @dagar might know more about the assigning of board IDs?
Regarding why you might have a problem with your USB timeout, you might need to add the compilation flag for using the STM32F446 chip. I know there are differences between the standard F4 USB peripheral device and the USB peripheral used on the STM32F446. Have a look at the example of adding the extra compilation define for the STM32F469 chip on the PX4_FMU_V4_PRO in the Makefile. You will probably have to add this define for your bootloader as well (but for the STM32F446 instead).
make -f Makefile.f4 TARGET_HW=PX4_FMU_V4_PRO LINKER_FILE=stm32f4.ld TARGET_FILE_NAME=$@ EXTRAFLAGS=-DSTM32F469
If the extra define doesn’t solve your problem, then you will have to dig deeper into the issue to find out what the undelying problem is.
It uploaded successfully.
I just downloaded the bootloader source code again and change the flash memory configuration (sector, size).
I don’t know what was the problem exactly.
Anyway, thanks for your help !
I have the same problem in downloading firmware. I use STM32F427IIH6, also the QGC instructs that erase failure you mentioned. Could you tell me how to set the sectors and flash size accordingly? Thanks.
There is a source code for flash memory configuration. (Bootloader - hw_config.h)
As you can see blow, you have to change the suitable value.
In my case (STM32F446), the flash size is 512KB (0x200) and sector is 7.
You can read flash memory size with related register and there is 0x1fff7a22 address. (FLASH_KBYTES)
Good luck !
(Copied from my reply to you on the other thread, so that others can find the reply here as well)
You have a older version of the STM32F427 chip (Revision Y). With this version of the silicon, you are unable to reliably access the second 1MB bank of the flash and use the USB at the same time. See more about this error here. Hence if you are using a revision Y silicon chip, you can only use the first 1MB of flash, hence why it your bootloader returns with the flash size being 1032192 bytes instead of 2080768 bytes.
Are you using a normal Pixhawk board?
Thanks for the reply. I am still a little bit confused that why the bootloader is designed to check the revision of the chip. I think for cortex M4 processor, the bootloader should treat them in a uniform way.
@doctorluhang: Sorry, I forgot to link to the errata sheet that explains this error. This page from Px4, explains the silicon error on the STM32F427 Revision Y chips. In summary, STM32F427 chips up to and including Revision 1 can produce errors when accessing the second flash bank when there is activity on the USB.
You are correct that (in theory) the bootloader should treat all cortex M4 chips the same, but because of this error where one is unable to use the the second MB of flash reliably when also using the USB connection, it was decided by Px4 to disallow use of the second bank of flash on the chips that have the silicon error, to prevent “mysterious errors” from occurring that could not be debugged.
The description of the silicon error can be found in section 2.1.10, pg. 16 in the errata sheet.
I think the simplest work around for you, is to not compile in some modules in your compilation so that the maximum size of the firmware is below 1MB in size.
I have a nucleo f446re card. I can’t compile the Pixhawk c: / px4 / bootloader code. unrecognized command line option gives ‘-mthumb’ error. I would be very happy if you could send me your compiled f446re bootloader.bin file.
@DoEon_Lee I have tried installing the
px4fmuv4_bl.elf on to the Nucleo F446RE board using a black magic probe. But, after flashing the boot loader, when I’m trying to upload the firmware I get
waiting for boot loader message on the terminal. I have used
make px4_fmu_v4 upload. The device manager isn’t able to recognize the Nucleo board as PX4 FMU4 after flashing the boot loader. Can you help me on this ?