Trying to compile px4 fmu firmware in stm32f407 chinnese board

hello:

I´m playing with a destroyed jyu hornet S drone, the main board has:

STM32F407VG
MEAS MS560702BA03-50 barometer
MPU6000 invensese motion sensor 6 axis
Compass A983 very similar to this module (HMC5983)
T240 24Mhrz crystal
Usb port
2,4 ghz module with main chip CYRF6936
5 ports with 4 pins each

I´m trying to figured out if is compatible with fmu 1.7V, but im comfused, im truying to compile the version for discovery board but i dont understand wich files i need and were is the main file to edit the I/0. i allready downloaded PX4 toolchain but i can´t run PX4 software download.

If someone can help me to find these files to start to work in how configure inputs and out´s and then copile.

i have a STlink v2 and a FTDI232 and a lot of time jajaja

Thanks you for everything, i will be whaiting your help.
Nicolás from chile.

Porting a board is not a simple task for a beginner on the Px4 stack. However, I can give you an overview of where things are and what to start with.

What I would recommend that you do is create a copy of all of the px4-stm32f4discovery configs and put them into new directories for your new board - give it an appropriate name and see if that will compile (before you have made any modifications to the configs).

  • The main compilation cmakfile which defines what modules should be compiled, are located in Firmware/cmake/configs. Note that these cmake files have the following naming convention nuttx_<board-name>_default.cmake. The board name is the same name as the board config directories (as explained below)/ The must not have any underscores in its name, since the undescores are used as tokens to separate the from the name of the cmake file.
  • The NuttX (the RTOS) config files are stored in Firmware/platforms/nuttx/nuttx-configs. Within each of the these nuttx config directories there are the following directories
    • include: this contains board.h where you set the pin definitions for USART, SPI, I2C ports and also the clock configuration. You will need to change the clock config, because the F4Discovery uses an 8MHz crystal, but your board uses a 24MHz crystal. You can copy the clock config from the px4fmu-v3 board (that uses a 24 MHz cystal). You will also have to add the SPI config. Have a look at the config for the px4fmu-v3.
    • nsh: this contains defconfig which set all of the peripherals that need to be compiled into NuttX. Here you set which USARTs are available, what SPI buses are available, what I2C buses are available, what chip should be compiled for, e.g. stm32F407VG. Note, you will have to make a change to the configuration to make use of the SPI, since the default config for the F4Discovery board doesn’t have them activated. Have a look at the config for the px4fmu-v3.
    • scripts: this contains ld.script - the linker script. Here the flash and ram sizes need to be set correctly (although if you use the same config as for the F4Discovery board you shouldn’t need to make any changes)
  • The remaining pin definitions are defined in Firmware/src/drivers/boards. In each board config directory, there is a board_config.h file, where you define all of the remaining pin configs and pin definitions. The next thing that you will need to modify is the <board-name>_init.c script which contains the functions that configures the pins on startup. Note: you will have to add a <board-name>_spi.c file here to configure the SPI. Have a look at the file for the px4fmu-v3.
  • In Firmware/platforms/nuttx/Images there are the <board-name>.prototype files. These are the templates for generating the .px4 firmware file which is uploaded by the bootloader to the board. The important value is the “board_id” field. This number has to be the same as the id reported by the bootloader, otherwise the px_uploader.py script will not allow you to upload the firmware to the board. (It will complain that you are trying to upload a firmware that is not meant for that board.)

Once you have got this all to compile, you will want to upload the firmware to the board. But you will need to flash a bootloader for the board. If you want to do this, let me know and I can walk you through creating a new board config in the bootloader.

1 Like

This is a really great explanation of the porting process @ksschwabe , thank you!

I’m currently working through a PX4 board port myself (Cortex-R5F based, finishing up the NuttX portions now) and would greatly appreciate any insight you would have on setting up a new board config for the bootloader. Thank you for your time.

@joshuawhitehead: Here is a quick overview of the Bootloader. The bootloader repository is PX4/Bootloader on Github. The bootloader, broadly speaking, is broken into the following parts:

  • bl.c: This file contains the bootloader “logic” and implementation of the bootloader transfer protocol (over either USB or UART).
  • main_<f1,f3,f4,f7>.c: This file contains the main setup and configuration of the clocks and pins and also the initial “checking logic” as to whether the board should jump to the main app or remain in the bootloader and wait for communication/data transfer. If you are an MCU that isn’t STM32Fx based, you will probably have to provide your own setup and logic file.
  • hw_config.h: This file contains the pin definitions for each of the boards. The config for the correct board is determined by a precompiler #ifdefs which are define which are defined in the Makefile based on the name of the board
  • Makefiles
    • Makefile: this is the master makefile whose targets (the bootloaders for each board) call the appropriate board-specific makefile (specific to F1, F3, F4, or F7). This makefile also defines the board-specific precompiler define which is used in hw_config.h to select the appropriate pin configs for the board. This is the “TARGET_HW” variable that is defined. The LINKER_FILE variable defines thw linker script to use for the compilation.
    • Makefile.<f1,f3,f4,f7>: these are the MCU-specific make files for each STM32Fx family. They define the STM32Fx family specific compiler flags and includes.
    • rules.mk: this makefile is common to all of the targets. It defines the the build directory based on the board name, generates the dependency, object, elf and binary files. It is called in each of the Makefile.fx files.
  • libopencm3/: This directory (included as a submodule in the PX4/Bootloader repo) is the library used to communicate with the STM32Fx peripherals/GPIOs, etc. If you are using an MCU that isn’t STM32Fx based, you will probably have to provide your own low-level drivers/peripheral library.
    -stmfx.ld: These are the linker scripts specific to each MCU family (F1, F3, F4 and F7). If you have your own chip that isn’t part of the STM32 family, you will have to provide your own linker script here.
  • uart.c: Basic USART setup file for configuring a USART port for communication - sets baudrate, stop-bits, parity, flowcontrol, etc. If not using an STM32 MCU, you will probably have to provide your own file.
  • cdcacm: CDCACM (USB) config setup file for configuring the USB. If not using an STM32 MCU, you will probably have to provide your own file.

On the STM32F4 MCUs used in the Px4 project (Px4FMU-v1, Px4FMU-v2, Px4FMU-v3), the bootloader is flashed to address 0x08000000 (the default boot/load address for the STM32 MCUs). The main app (basically the PX4/Firmware) is uploaded to 0x08004000 (define APP_LOAD_ADDRESS in hw_config.h).

Wow! thanks! im working on it, I’ll let you know when I finish these editions.
You know if there is some document or image with a diagram o something for understand how firmware work in this chip. I can not imagine what ports he uses and how, somethig like architecture. im reading the datasheet, but maybe you have more information.
thanks again!!

@Nicomacoco: There are these diagrams: https://dev.px4.io/en/concept/architecture.html and https://dev.px4.io/en/flight_stack/controller_diagrams.html which give a high-level overview of how the firmware works.

If you want the actual pins used for USARTs, I2C, SPI, etc. you will have to consult the schematics for the particular board that you are interested in, see https://dev.px4.io/en/debug/reference-design.html.

Great information on the bootloader @ksschwabe, thank you for taking the time to explain the different pieces.

On the topic of the bootloader- is it strictly necessary to use the PX4 Bootloader? If I have a bootloader for my particular board that’s already able to set up all the device peripherals and jump to the main app, it doesn’t seem like it should be necessary? Though I’m guessing it would take some modification of the PX4 build system to skip the normal bootloader…

Please let me know if I should start a new thread on this, I don’t want to divert the topic too much from @Nicomacoco’s questions. Thanks!

(Edit: Started new topic for this discussion here)

@joshuawhitehead: It is best to open a new topic so that we don’t derail this one. Once you have opened it, I can answer the question there.