Padded files are currently required for Seriously Pro H7 Extreme (SPRacingH7Extreme) board

[zedthirteen]

It is not possible to load the released builds .px4 format files to the SPRacingH7Extreme board. Developer tells me they need to be padded binary files and not the encoded .px4 format.

I propose that padded binary files are provided for the SPRacingH7Extrmeme until .px4 loading support has been incorporated into QGroundControl/main code for this board

At present the only alternatives are end users to install a build environment to build the required file and then pad the binary to the required length (multiple of DFU transfer size) or contact Dominic (developer) for a the required file and then flash with DFU-Util.

DFU-Util and build environments are not ideal for many end users

[dagar]

@Igor-Misic any comment here?

I'm happy to add whatever's needed to the build system (both cmake and CI) and uploaded artifacts.

[Igor-Misic]

I am flashing .bin created by building a PX4 project (no padded needed) with my own tools.
With it, I can flash the board and run inline debugging without disconnecting or pressing any button on the boards.

For users binary, I think it is best to see with Dominic what he thinks about it. Probably this padding could be added to the project so binary could be flashed with dfu-util.

I am willing to share my tools with developers. The tool requires key and each board has a different key. The idea with the key is to support Dominic and his efforts to protect the board from cloners.

More about my development tools:
https://igor-misic.blogspot.com/2020/10/sp-racing-h7-extreme-imssbl.html
contact me at email igy1000mb@gmail.com for the key.

[hydra]

a zero-padded binary is probably best, likely the best way to achieve this is to update the PX4 linker scripts and use the FILL linker script commands to pad the binary to the desired size.

We allocated 2MB of the flash for PX4 firmware use in the memory map when the initial PR for SPRacingH7EXTREME support was added.

The dfu-util transfer size, the sp racing bootloader dfu implementation and the flash chip minimum block erase size are all factors. The binary size must be a factor of dfu-util trasfer size (1024 bytes) and ideally also of the flash chip's block erase size, whichever of the two is larger. The sp racing bootloader uses the 64KB block erase command on the W25Q128 flash chips. So the PX4 binary should thus be a multiple of 64KB. 2MB is a multiple of 64KB.

Note: The SSBL does no hash checking of the flashed binary so verification has to be done client-size (i.e.
upload the code and download it, then compare). However this isn't as robust as having the FC (SSBL) verify the flash content on every boot, but since that's not implemented in the SSBL we can leave that as room for future improvement. For any such hash checking in the SSBL, it would need to know where the hash is, or how to recognize one for variable length binary files, so co-ordination between PX4 devs and SSBL devs would be needed.

[hydra]

As this hasn't been addressed yet I've provided an interim solution for SPRacingH7EXTREME customers.

Pre-padded binary files can be downloaded here:

https://github.com/spracing/px4_firmware/releases

https://github.com/spracing/px4_firmware/releases/tag/v1.11.3

If the version you need isn't available you can use this how-to to make one.

https://github.com/spracing/ssbl/wiki/HOWTO-Extract-a-binary-image-from-a-PX4-release-file

See also:

https://github.com/spracing/ssbl#px4-installation-to-external-flash