Has anyone tried MCUBoot on STM32 MCUs?

Hi,

So far I was able to get the demo project to run DISCO-F746NG board. The bootloader can start primary application image without problem, but when I tried to initiate firmware upgrade by calling the following function:

    ret = boot_set_pending(false);
    if(ret == 0) {
        printf("%d: press system reset button to reboot and upgrade firmware\r\n", time(nullptr));
    } else {
        printf("%d: failed to notify bootloader, something went wrong, code = %d\r\n", time(nullptr), ret);
    }

I got the following errors:

e[2Ke[90m[DBG ][MCUb]: flash area 1 open count: 1 (+)e[0m

e[2Ke[90m[DBG ][MCUb]: initializing flash area 1...e[0m

e[2Ke[90m[DBG ][MCUb]: flash area 1 open count: 0 (-)e[0m

e[2Ke[90m[DBG ][MCUb]: deinitializing flash area block device 1...e[0m
48554: failed to notify bootloader, something went wrong, code = 3

This seems to indicate something went wrong when bootloader tried write something into the secondary block device. I used the external QSPI Flash either as a whole or a slice like this :

mbed::BlockDevice* get_secondary_bd(void)
{
    static QSPIFBlockDevice bd(QSPI_FLASH1_IO0, QSPI_FLASH1_IO1, QSPI_FLASH1_IO2, QSPI_FLASH1_IO3, QSPI_FLASH1_SCK, QSPI_FLASH1_CSN, QSPIF_POLARITY_MODE_0, MBED_CONF_QSPIF_QSPI_FREQ);

    //static mbed::SlicingBlockDevice sliced_bd(&bd, 0x0, MCUBOOT_SLOT_SIZE);

    return &bd;
}

The primary application can write into/read from the QSPI flash through, but somehow bootloader part of code seems having trouble with secondary_bd.

Did I do something wrong here? Please advise.

Thanks,
ZL

The problem seems to be lack of proper support for the QSPI flash on DISCO-F746NG board as of mbed-os-6.4.0. Once I upgraded to mbed-os-6.17.0, I was able to get pass this and trigger firmware upgrade.

Also there seem to be some breaking changes since mcuboot v1.9. The following version combinations have been tested working on DISCO-F746NG and by extension other STM32F7 series MCU.

Bootloader: Mbed-OS v6.17.0 + mcuboot v1.8.0

Primary/user application: Mbed-OS-v6.17.0 + mcuboot v1.8/v1.7/TF-Mv1.4-integ-rc1~49(the version referenced in the demo project). MCUboot v1.4, v1.5 and v1.6 cannot be compiled with mbed-os-6.17. MCUboot v1.9, v1.10, v2.0, v2.1 can be compiled, boot_set_pending() seems able to run without error, but upon system reboot, bootloader (mcuboot v2.1) will ignore the firmware image stored in secondardy slot.

We were able to build a FOTA system with Mbed-OS and MCUboot in about two weeks, including several days spent on studying Pelion. Several days were spent on designing and implementing server side facilities to receive and distribute firmware images, and another several days on implementing embedded code to download firmware over HTTP/HTTPS, and two day on final integration and test. The process worked out more or less as expected.

I post this to prove that FOTA can still be done with Mbed relatively quickly, not as quick and easy as with ESP32, but quick enough.

Hope this helps someone.

1 Like