Bootloader on NUCLEO L476

[Kormoran86]

Hi,

I've been trying to run the bootloader demo code on a NUCLEO-L476 board with no succes...

After building and flashing the bootloader this is the result

Which should be expected as the primary slot is still empty, but after flashing the demo application I get this output:

It just gets stuck in that point without booting from the first slot.

I used the following slot configutation:

I also modified the stm32l476xg.ld linker script (only de ROM part) to use memory banks like so:

MEMORY
{
  FLASH (rx)   : ORIGIN = MBED_CONFIGURED_ROM_BANK_IROM1_START, LENGTH = MBED_CONFIGURED_ROM_BANK_IROM1_SIZE
  SRAM2 (rwx)  : ORIGIN = MBED_RAM1_START + VECTORS_SIZE, LENGTH = MBED_RAM1_SIZE - VECTORS_SIZE
  SRAM1 (rwx)  : ORIGIN = MBED_RAM_START, LENGTH = MBED_RAM_SIZE
}

The mbed_app.json file for the bootloader:

{
  config: {
    "serial-bootloader-enable": {
      help: "Build bootloader with serial update support",
      value: 0,
    },
    "secondary-slot-in-flash": {
      help: "If enabled, store the secondary slot in the application flash immediately after the primary slot.",
      value: false,
    },
    "secondary-slot-flash-start-addr": {
      help: "If secondary-slot-in-flash is enabled, this sets the start address of the secondary slot.",
      value: null,
    },
  },

  target_overrides: {
    "*": {
      "platform.stdio-baud-rate": 115200,
      "target.c_lib": "small",
      "mcuboot.log-enable": true,
      "mcuboot.log-level": "MCUBOOT_LOG_LEVEL_DEBUG", // Change DEBUG to INFO for debug prints
      "mbed-trace.enable": true,
      "mbed-trace.max-level": "TRACE_LEVEL_DEBUG",
      "mbed-trace.fea-ipv6": false,
    },

    NUCLEO_L476RG: {
      // Configure bootloader to live in the first sector of flash
      "target.memory_bank_config": {
        IROM1: {
          size: 0x30000,
        },
      },

      // Summary of available memory banks (project config output):
      // Target RAM banks: -----------------------------------------------------------
      // 0. IRAM1, start addr 0x20000000, size 96.0 KiB
      // 1. IRAM2, start addr 0x10000000, size 32.0 KiB

      // Target ROM banks: -----------------------------------------------------------
      // 0. IROM1, start addr 0x08000000, size 1.0 MiB (configured to 192.0 KiB)

      "target.components_add": ["SPIF", "FLASHIAP"],

      "mcuboot.primary-slot-address": "0x8030000",
      "mcuboot.slot-size": "0x30000",

      "app.secondary-slot-in-flash": true,
      "app.secondary-slot-flash-start-addr": "0x8060000",

      "mcuboot.scratch-address": "0x8090000",
      "mcuboot.scratch-size": "0x30000",

      "mcuboot.max-img-sectors": "96", // Maximum flash sectors per slot. 192kiB/2kiB = 96.
      "mcuboot.read-granularity": 1,

      "spif-driver.SPI_MOSI": "PC_3",
      "spif-driver.SPI_MISO": "PC_2",
      "spif-driver.SPI_CLK": "PB_13",
      "spif-driver.SPI_CS": "PB_9",
      "spif-driver.SPI_FREQ": "80000000",
      "spif-driver.debug": 1,
    }
}

And the mbed_app.json for the demo application:

{
  config: {
    "demo-button": {
      macro_name: "DEMO_BUTTON",
      required: true,
      value: "BUTTON1",
    },
    "demo-button-active-low": {
      help: "true if the button state is low when pressed, high when released",
      macro_name: "DEMO_BUTTON_ACTIVE_LOW",
      required: false,
    },
    "secondary-slot-in-flash": {
      help: "If enabled, store the secondary slot in the application flash immediately after the primary slot.",
      value: false,
    },
    "secondary-slot-flash-start-addr": {
      help: "If secondary-slot-in-flash is enabled, this sets the start address of the secondary slot.",
      value: null,
    },
  },

  target_overrides: {
    "*": {
      "mcuboot.bootloader-build": 0,
      "target.c_lib": "small",
      "mcuboot.log-level": "MCUBOOT_LOG_LEVEL_DEBUG",
      "mbed-trace.enable": true,
    },

    NUCLEO_L476RG: {
      "target.memory_bank_config": {
        IROM1: {
          start: 0x8031000, //mcuboot.primary-slot-address + mcuboot.header-size
          size: 0x2f000, // mcuboot.slot-size - mcuboot.header-size
        },
      },

      // Summary of available memory banks (project config output):
      // Target RAM banks: -----------------------------------------------------------
      // 0. IRAM1, start addr 0x20000000, size 96.0 KiB
      // 1. IRAM2, start addr 0x10000000, size 32.0 KiB

      // Target ROM banks: -----------------------------------------------------------
      // 0. IROM1, start addr 0x08000000 (configured to 0x08031000), size 1.0 MiB (configured to 188.0 KiB)

      "demo-button": "PC_13",
      "demo-button-active-low": true,

      "target.components_add": ["SPIF", "FLASHIAP"],

      "mcuboot.primary-slot-address": "0x8030000",
      "mcuboot.slot-size": "0x30000",

      "app.secondary-slot-in-flash": true,
      "app.secondary-slot-flash-start-addr": "0x8060000",

      "mcuboot.scratch-address": "0x8090000",
      "mcuboot.scratch-size": "0x30000",

      "mcuboot.max-img-sectors": "96", // Maximum flash sectors per slot. 192kiB/2kiB = 96.
      "mcuboot.read-granularity": 1,

      "spif-driver.SPI_MOSI": "PC_3",
      "spif-driver.SPI_MISO": "PC_2",
      "spif-driver.SPI_CLK": "PB_13",
      "spif-driver.SPI_CS": "PB_9",
      "spif-driver.SPI_FREQ": "80000000",
      "spif-driver.debug": 1,
    },

I've spent the past week trying to solve this but I'm getting the same result, I tested using an external flash for the secondary slot (hence the spif-driver config section in mbed_app.json) and also used another NUCLEO-L496 board with the same slot configuration but still no luck...

Any hints as to what I might be doing wrong are more than appreciated 😄

Best regards,

Lalo

[JohnK1987]

Guys (@multiplemonomials @zhiyong-ft @lefebvresam ), do you find few minutes to look on this?

[zhiyong-ft]

@Kormoran86 could you elaborate on how you flashed primary application into NULCEO-L476RG board? Try to manually sign the original hex file with imgtool and then flash it.

The other thing to look into is secondary_bd.cpp file and see what is actually passed to bootloader as secondary block device. I believe the default is SPIF if it exists, but I saw this:

"app.secondary-slot-in-flash": true,
 "app.secondary-slot-flash-start-addr": "0x8060000",

If SPIF is passed as secondary bd we need to make sure the SPIF chip is compatible with SPIF driver, this needs to be tested out.

[Kormoran86]

Hi @zhiyong-ft ,

I used pyocd to flash the primary app, this is the output from pyocd:

I tried your suggestion and signed SimpleApp.hex with this parameters:

imgtool sign -k .\signing-keys.pem --align 4 -v 1.0.0+1 --header-size 4096 --pad-header -S 0x30000 --pad .\SimpleApp.hex SimpleApp_signed.hex

Then converted the .hex to .bin with:

arm-none-eabi-objcopy -I ihex -O binary .\SimpleApp_signed.hex .\SimpleApp_signed.bin

And flashed it using pyocd:

pyocd flash -v --no-wait -f 4000k -t stm32l476rgtx --base-address 0x08030000 "path/to/SimpleApp_signed.bin"

But i'm getting the same behavior as before...

I signed and flashed SimpleApp.hex and not the full UpdaterApp+SimpleApp to keep things simple and to see if the bootloader would start SimpleApp.

Regarding the signing process in the demo, where can one set the version number of the application?

I also checked secondary_bd.cpp and can confirm that get_secondary_bd returns the internal flash of the chip as set by "app.secondary-slot-in-flash": true, which is the correct configuration.

[multiplemonomials]

Apologies, I didn't see this until now, GitHub doesn't notify me unless someone mentions me specifically... So sorry that you are having a tough time getting this to work!

For starters, go ahead and try this branch of Mbed: #440 . I converted the linker script to support memory banks on your target (though it looks like the way you set it up is correct, this is just to check).

From what you described, it sounds like something is going wrong when the bootloader jumps to the application, and we'll need to dig into why that is. I checked over your configuration, and it looks OK, all the addresses seem to match what I'd expect.

To analyze this issue, you may need to be a bit creative with the debugger. I'd recommend:

• Start the gdb server (e.g. openocd or STM32Cube) using the command that Mbed uses
• Start gdb on the elf file for the application
• Connect to the gdb server (e.g. target remote localhost:23331)
• Break on the application reset handler, and then reset the device and let it run through the bootloader and jump to the application:

  (gdb) break Reset_Handler
  (gdb) monitor reset
  

Then ideally it should break right when the bootloader jumps to the application, and then you can step through and work out what's going on. I had to use this procedure at times when testing mcuboot, and it usually helps find the issue (after some messing around).

[Kormoran86]

Hi @multiplemonomials ,

No need to apologize 😊

I followed @zhiyong-ft suggestions in my reply above and got the same results, which leads me to believe that as you pointed there is something wrong with the bootloader.

I don't have a lot of experience with openocd (or any debugger, shame on me I know...), in fact I'm still using mbed CLI 1 so the switch to CMake has been a little overwhelming.

I will try to set up openocd on my machine and will report back with the results!

[multiplemonomials]

Good news! I tried to set up my own configuration on my NUCLEO_L452RE_P board, and I was able to replicate the hang you were getting. I did some debugging, and determined the cause. This doesn't have anything to do with the mbed_app.json configuration at all. It's crashing in the bootloader because it's running out of stack!

It turns out that mcuboot requires more than 1k of stack space to do its stuff, and the linker script for STM32L4 only allocates exactly target.boot-stack-size (0x400 bytes) of stack, and if the application uses more than that, it will crash, HARD (can't even get to the fault handler to print the crash details).

I have created this PR which both combines together the linker scripts, and updates them to use a more conventional stack setup where the stack and heap can grow into the same area.

[multiplemonomials]

I have updated mbed-os and the demo bootloader/application projects to use the new version and support NUCLEO_452RE_P. With the changes I made there, things seem to work!

[zhiyong-ft]

@Kormoran86 Could you double check if the signing-keys.pem passed to bootloader and primary application are the same? The other thing you can try might be to read the flash content with STM32CubeProgrammer and see if they match expectation.

I attached the missing portion of your bootloader log below:

�[2K�[39m[INFO][MCUb]: Image index: 0, Swap type: none�[0m

�[2K�[94m[DBG ][MCUb]: flash area 0 open count: 2 (+)�[0m

�[2K�[94m[DBG ][MCUb]: flash area 0 open count: 3 (+)�[0m

�[2K�[94m[DBG ][MCUb]: flash area 0 open count: 2 (-)�[0m
// Your are missing debug output from the following line
�[2K�[94m[DBG ][MCUb]: flash area 0 open count: 1 (-)�[0m

�[2K�[94m[DBG ][MCUb]: flash area 2 open count: 0 (-)�[0m

�[2K�[94m[DBG ][MCUb]: deinitializing flash area block device 2...�[0m

�[2K�[94m[DBG ][MCUb]: flash area 1 open count: 0 (-)�[0m

�[2K�[94m[DBG ][MCUb]: deinitializing flash area block device 1...�[0m

�[2K�[94m[DBG ][MCUb]: flash area 0 open count: 0 (-)�[0m

�[2K�[94m[DBG ][MCUb]: deinitializing flash area block device 0...�[0m

�[2K�[39m[INFO][BL]: Booting firmware image at 0x8018400
�[0m

It seems your bootloader stuck when/after doing something with flash area 0 and before opening flash area 2(scratch area). Go back to MUCboot source code and see what is happening there. My hunch is this have something to do with configuration of scratch area, image sectors? I don't know this part of code enough to make a call.

[Kormoran86]

@multiplemonomials @zhiyong-ft

I tested the latest mbed-os ce and bootloader example version on the NUCLEO-L476RG both with internal flash and external flash for the secondaty slot and it's working!

I'm using this board based on the SST26VF064B 8Mb serial flash chip.

For reference, this is the mbed_app.json:

NUCLEO_L476RG: {
      // Configure bootloader to live in the first sector of flash
      "target.memory_bank_config": {
        IROM1: {
          size: 0x30000,
        },
      },

      "target.components_add": ["SPIF", "FLASHIAP"],

      "mcuboot.primary-slot-address": "0x8030000",
      "mcuboot.slot-size": "0x30000",

      "app.secondary-slot-in-flash": false,
      "app.secondary-slot-flash-start-addr": "0x8060000",

      "mcuboot.scratch-address": "0x8090000",
      "mcuboot.scratch-size": "0x30000",

      "mcuboot.max-img-sectors": "96",
      "mcuboot.read-granularity": 1,

      "spif-driver.SPI_MOSI": "PC_3",
      "spif-driver.SPI_MISO": "PC_2",
      "spif-driver.SPI_CLK": "PB_13",
      "spif-driver.SPI_CS": "PB_9",
      "spif-driver.SPI_FREQ": "80000000",
      "spif-driver.debug": 1,
    },

Thank you so much @multiplemonomials @zhiyong-ft for your help!

[zhiyong-ft]

@Kormoran86 I'm glad you got it to work. If you plan to encrypt firmware images, please either manually sign/encrypt them, or use/test my fork for the time being until my PR is approved.