ROM Region Merging is not padding correctly

[DrynnBavis]

Description

I've got a managed bootloader application of which I've set the target.restrict_size to a value of 0x40000. When I use this binary as a bootloader for my main application, I get the following in my build logs:

Using ROM regions bootloader, application in this build.
  Region bootloader: size 0x10000, offset 0x8000000
  Region application: size 0x170000, offset 0x8010000
Compile [100.0%]: mbed_application.c

This is problematic because the bootloader calls mbed_app_start(POST_APPLICATION_ADDR) which has a value of 0x8040000. Essentially, the linker is placing my main program at 0x8010000 while the bootloader is actually booting into 0x8040000. The behaviour of this is my application just "hangs" after the bootloader completes.

Note that I've also printed the address, sp, and pc, before booting the assembly code within start_new_application() is called, and I got the following results:

calling start_new_application
address -> 0x08040000
sp ------> 0xFFFFFFFF
pc ------> 0xFFFFFFFF

and after I set target.restrict_size back down to something smaller like 0x1000, I see something of more expected behaviour (but still seems to hang):

calling start_new_application
address -> 0x08010000
sp ------> 0x20050000
pc ------> 0x080132DD

Is this a bug on mbed's side? Or do I need to do something in my main program's config to pad out until 0x8040000?

As requested these are contents of your requested files @AGlass0fMilk
bootloader's mbed_app.json:

{
    "config": {
        "default_target" : {
            "value": "TRACK_PILOT2"
        }
    },
    "target_overrides": {
        "*": {
            "mbed-trace.enable": 1,
            "platform.stdio-baud-rate": 115200,
            "platform.stdio-convert-newlines": true
        },
        "MY_CUSTOM_TARGET": {
            "target.restrict_size": "0x00020000"
        }
    }
}

main app's mbed_app.json:

"MY_CUSTOM_TARGET": {
    "enable-swo": "0",
    "spif-driver.SPI_MOSI": "FLASH_SPI_MOSI",
    "spif-driver.SPI_MISO": "FLASH_SPI_MISO",
    "spif-driver.SPI_CLK": "FLASH_SPI_SCK",
    "spif-driver.SPI_CS": "FLASH_SPI_CS",
    "spif-driver.SPI_FREQ": 40000000,
    "target.features_add": ["STORAGE"],
    "target.components_add": ["SPIF"],
    "target.bootloader_img": "../bootloader/build/develop/bootloader.bin"
}

target definition:

"MY_CUSTOM_TARGET": {
    "inherits": ["FAMILY_STM32"],
    "core": "Cortex-M4F",
    "extra_labels_add": [
        "STM32F4",
        "STM32F413xx",
        "STM32F413RH",
        "STM32F413xH",
        "STM32F413ZH"
    ],
    "config": {
        "clock_source": {
            "help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
            "value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
            "macro_name": "CLOCK_SOURCE"
        },
        "lpticker_lptim": {
            "help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
            "value": 1
        }
    },
    "overrides": {
        "lpticker_delay_ticks": 4
    },
    "macros_add": [
        "MBED_TICKLESS",
        "USB_STM_HAL"
    ],
    "device_has_add": [
        "ANALOGOUT",
        "CAN",
        "SERIAL_ASYNCH",
        "TRNG",
        "FLASH",
        "MPU"
    ],
    "bootloader_supported": true,
    "release_versions": [
        "5"
    ],
    "device_name": "STM32F413ZHTx"
}

Issue request type

Target: custom MCU with STM32F413RH processor
Toolchain: GCC_ARM 8.2.1
Tool: mbed-cli
Vers: cfa7938 (HEAD, tag: mbed-os-5.12.2)

[x] Question
[ ] Enhancement
[ ] Bug

[AGlass0fMilk]

I can't comment on the padding issue at the moment -- can you post both of your 'mbed_app.json' files for the bootloader and the application? Also post the 'custom_target.json' if you have one.

As for sp and pc, the first one is the initial stack pointer and the second one is the initial program counter (address of next instruction to be executed). In this case, it's pointing to the Reset Vector of your application. This is the real entry point of your application and does all the hardware/system/RTOS initialization before jumping to your main function.

See this diagram below showing the reset vector format on Cortex M4 devices:

(Page 37 of this file)

So in your second case, the bootloader/application merging seems to be working -- the sp and pc values are reasonable, indicating it really is the vector table of your application binary. However, there is a problem!

The reason your program is hanging is because the initial program counter pointer is unaligned -- that is the value 0x080132DD is not word-aligned (since it's a 32-bit processor, must be divisible by 4). 0x080132DD is an odd number. Attempting to execute an unaligned instruction is illegal in CM4 processors and will cause a HardFault/MemoryManagement Fault.

Unfortunately this kind of bug pops up from time to time, so it's good to know the root cause of this issue.

This is certainly a problem with the online compiler tools...

Until someone from Mbed addresses this issue I would recommend trying to get set up with Mbed-CLI and building offline, that way you have a lot more control over the build and various tool/software versions.

[DrynnBavis]

can you post both of your 'mbed_app.json' files for the bootloader and the application? Also post the 'custom_target.json' if you have one.

@AGlass0fMilk I've edited my OP to include the 3 files you asked for. Just as a reminder, the device_name listed in my target definition isn't the processor I'm actually using (since my processor - STM32F413RH - doesn't seem to have support from mbed), so instead I'm using STM32F413ZHTx since it has sectors defined in arm_pack_manager/index.json that seem to be similar to my processor's ROM mapping. Please see #11120 for more info on that.

I had a feeling that 0x080132DD wasn't a valid address. I don't see what I'm doing on my end wrong that's causing this though. Recall from mbed_start_application() from mbed_application.c that the definition of pc is

pc = *((void **)address + 1);

To print this, I was c-style casting it to a char pointer like so

printf("pc ------> 0x%08X\r\n", (char*)pc);

Maybe I'm just printing this wrong? Or does the logic for pc make sense? My interpretation is, we're casting address to a double void pointer, incrementing the address of this pointer by 1 (whatever that means, please enlighten me here!) and then finally de referencing it back to a single star void pointer.

This is certainly a problem with the online compiler tools...

Until someone from Mbed addresses this issue I would recommend trying to get set up with Mbed-CLI and building offline, that way you have a lot more control over the build and various tool/software versions.

I am indeed using Mbed-CLI and building offline. What do you recommend I do to fix this?

[0Grit]

I recall ST parts having memory regions all over the place versus 1 contiguous flash region.

Gut feel is you should confirm those sectors that seem to be similar.

[DrynnBavis]

Gut feel is you should confirm those sectors that seem to be similar.

@loverdeg-ep tagged you on the other issue with an update to my understanding of the sectors for this chip.

[AGlass0fMilk]

To verify the actual value programmed into the device for the initial program counter/reset vector you can use a hex editor to view the binary.

I recently had a situation where the build tools were putting an illegal address in the reset vector location...

Try opening the binary up with something like https://hexed.it/?hl=en and take a screenshot.

[DrynnBavis]

To verify the actual value programmed into the device for the initial program counter/reset vector you can use a hex editor to view the binary.

What address is this exactly? Sorry. I've got the file open in HexEd.it just not sure what address you want to see.

[AGlass0fMilk]

The beginning of the application. So whatever that address is that the bootloader jumps to.

[DrynnBavis]

The beginning of the application. So whatever that address is that the bootloader jumps to.

The first image above is the hex at the offset of `0x00020000`, the expected offset of the main program from the `main.bin` compiled file of the master application with the merged bootloader in it.

This second image here is from `main_application.bin` notice the content that started at 0x00020000 in `main.bin` is starting here in application at 0x000210C0. Does this seem suspicious too?

[DrynnBavis]

@AGlass0fMilk Something else interesting, I've changed the target on my bootloader and main application to an older MCU I had on hand that I previously had success with, and this was the sp and pc print:

calling start_new_application
address -> 0x08020000
sp ------> 0x20030000
pc ------> 0x08024DC5

Again, here the program counter is pointing to an odd number, and thus seemingly unaligned. However the program does seem to be working fine. My blinky application successfully booted from the bootloader. Nothing changed but the target.

So my hypothesis is that these addresses might just be random garbage at the point of time when I'm printing them.

This odd pc value might be a dead end.

[DrynnBavis]

Just a bump for the new week
@AGlass0fMilk what do you think of this from @40Grit:

In the past @AGlass0fMilk was getting a hardfault after booting mcuboot. i beleive it was due to an invalid vector table relocation?
vtor is the register to confirm.

How would I go about confirming that vtor is indeed pointing to the correct address of the vector table? I guess I'm asking how would I check the value in vtor after the bootloader boots, and then where would I find what the expected address of the vector table should be?

[0Grit]

@DrynnBavis
@AGlass0fMilk is travelling currently.

The vector table is at address 0 by default. Where it gets relocated to must be aligned correctly.
The first thing the processor does after power on reset is load the value contained at the 0th entry of the table into the stack pointer and then executes the reset vector.

As I recall Mbed OS 5 generally ends up relocating the vector table to somewhere in SRAM

See the following from http://infocenter.arm.com/help/topic/com.arm.doc.dui0553b/DUI0553.pdf

[0Grit]

@kjbracey-arm may or may not be able to cut to the heart of the topic for you, upon returning from leave.

[DrynnBavis]

@loverdeg-ep thanks for the response. I was looking at this datasheet yesterday, and I'm pretty convinced it is indeed being relocated to SRAM. I'm just frustrated in trying to figure out how to debug this properly.

What I've learned is that the bootloader has it's own v table and after finishing (i.e. I call mbed_app_start(POST_APPLICATION_ADDR);, something happens and I think the sp is supposed to point at the vector table of my new application where it's now been offset to some place in SRAM. Ideally at this point a reset will occur and initialisation work the processor needs to do will be performed to configure RTOS and such before the application starts.

What exactly is expected to happen between my calling of mbed_app_start(POST_APPLICATION_ADDR); from the bootloader and the start of my main application? Knowing this would help a lot, if anyone knows.