Using "managed bootloader" with custom target?

[DrynnBavis]

Description

Struggling to compile my bootloader for a custom MCU.
This MCU uses an STM32F413RH core M4F processor and I've got the following target definition filled out in targets.json:

    "MY_CUSTOM_MCU": {
        "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"
        ],
        "mbed_rom_start": "0x08000000",
        "mbed_rom_size" : "0x00180000",
        "device_has_add": [
            "ANALOGOUT",
            "CAN",
            "SERIAL_ASYNCH",
            "TRNG",
            "FLASH",
            "MPU"
        ],
        "bootloader_supported": true,
        "release_versions": [
            "5"
        ],
        "device_name": "STM32F413RH"
    }

Unfortunately, when trying to use this target in my bootloader, I find that POST_APPLICATION_ADDR is undefined and it seems that "target.restrict_size" was ignored completely in my mbed_app.json.

Is this intended behaviour? Am I forced to use an "unmanaged bootloader" with the mbed_app_start and mbed_app_size settings? Or is there something I'm missing in my target definition above? I really thought bootloader_supported would be all I needed..

EDIT: I've also tried to build my main application (the one the bootloader will boot into) and after trying to build it with specifying my bootloader in target.bootloader_imh I get this error:

Link: master
Elf2Bin: master
[ERROR] Bootloader not supported on this target: targets.json `device_name` not found in arm_pack_manager index.

Issue request type

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

[x] Question
[ ] Enhancement
[ ] Bug

[40Grit]

@AGlass0fMilk

[DrynnBavis]

@theotherjimmy Saw you in some other issues relating to bootloaders in mbed, hoping you can help me out with some advice here!

[40Grit]

@DrynnBavis Jimmy has moved to a different team within arm.

Embedded Planet recently went through this process with our Agora target but the resource that did it just went on vacation. @AGlass0fMilk also had interest in the mbed bootloader porting process and may or may not have time to look onto your issue as part of that effort.

[AGlass0fMilk]

Looks like it's using CMSIS packs to look up memory layout of the target. The python tools are using this library: https://github.com/ARMmbed/cmsis-pack-manager to look up cached targets.

I went through the index.json file here: https://github.com/ARMmbed/mbed-os/blob/master/tools/arm_pack_manager/index.json

@DrynnBavis And found a similar target name -- try using STM32F413RHTx instead. The tools seem to be expecting an exact name to look up this part's flash layout... kind of an opaque process but I guess you only have to set it up once.

[DrynnBavis]

STM32F413RHTx

@AGlass0fMilk Where do I put this exactly? It's not recognising this as a default_target within mbed_app.json, nor is it accepting it as something to inherit from or as the device_name from the targets.json file. Trying to change this to be the target results in this error:

argument -m/--mcu: STM32F413RHTx is not a supported MCU. Supported MCUs are:

EDIT: I'm guessing here that the specification of mbed_rom_start and mbed_rom_size aren't sufficient for flash layout description. What I need is a .FLM driver for a processor that has the same onboard flash layout as mine, and you're saying that STM32F413RHTx is the best match. Either that or I'd have to write my own .FLM file, but I'd rather use existing work.

Could you please explicitly describe what I need to do here to use STM32F413RHTx as a reference for my custom target's flash layout? I believe I'm meant to keep my default_target as my custom target, but I'll need to make edits in my target json description (the one posted above) in targets.json? Thanks!

EDIT2: After changing the device_name to the one you recommended, I'm now getting a different error. I still can't build the bootloader as a "managed bootloader" (same behaviour as before, restrict_size seems to be getting ignored still), but if I build the bootloader using the mbed_app_size AKA "unamanaged bootloader" method, and then use the binary of that with my master project that has target.bootloader_img pointing the aforementioned binary path, I get this error:

[ERROR] No sector info available

EDIT3: poking around in index.json I found that the JSON of STM32F413RHTx contained a null definition for the sectors field. In a different target (that was previously working for us) I found that this field should be populated with an array. The following is from a different target STM32F429ZITx:

        "sectors": [
            [
                134217728, 
                16384
            ], 
            [
                134283264, 
                65536
            ], 
            [
                134348800, 
                131072
            ], 
            [
                135266304, 
                16384
            ], 
            [
                135331840, 
                65536
            ], 
            [
                135397376, 
                131072
            ], 
            [
                536836096, 
                528
            ], 
            [
                536854528, 
                8
            ]
        ], 

If I can figure out what these arrays are for maybe I can use the data sheet to fill this in. Or maybe this was left null for a good reason.

Regardless, I still don't see how this will solve the issue of target.restrict_size from not working. Seems like I've got two different problems here possibly.

[DrynnBavis]

Update time,

I found a target with sectors defined that comes from the same family of processor called STM32F413ZHTx. This is the sector definition:

"sectors": [
            [
                134217728, 
                16384
            ], 
            [
                134283264, 
                65536
            ], 
            [
                134348800, 
                131072
            ], 
            [
                536854528, 
                4
            ]
        ], 

Cross referencing this with the F413/23 family data sheet (see page 67-68), I now believe that the first number here is a ROM address and the second is the sector size starting at that address. If so, this is consistent with what the data sheet says for the first 3 entries, but the fourth remains a mystery to me. According to the data sheet, does this look like the right definition? Can anyone tell me what the 4th entry is supposed be doing? Is it correct?

Anyway, I've changed my device_name field of my custom target in custom_targets.json to point at this definition with the sectors pasted above, STM32F413ZHTx. Now I am finally able to compile my bootloader and link it to my master using the "managed bootloader" method!

But unfortunately, one problem persists. After flashing the main project binary to my device, I successfully run through the bootloader, and after booting to the main app space I get this hard fault error:

++ MbedOS Error Info ++
Error Status: 0x8001011D Code: 285 Module: 1
Error Message: Failed to start RTOS
Location: 0x802E511
File: mbed_rtos_rtx.c+117
Error Value: 0x0
Current Thread: �0�  Id: 0x0 Entry: 0x80043FD StackSize: 0x0 StackMem: 0x8005BF1 SP: 0x2004FF8C 
For more info, visit: https://mbed.com/s/error?error=0x8001011D&tgt=<name_of_target>
-- MbedOS Error Info --

Does this look familiar @AGlass0fMilk ? I have no clue where to start debugging this one...

[DrynnBavis]

@loverdeg-ep tagging you here for better context. But this is what I found in the data sheet of my specific processor was this for the memory mapping:

This seems to suggest that from 0x08000000 -> 0x08180000 the flash is continuous? And within the STM32F413/23 family data sheet the sectors are described as such:

So referring back to the sectors definition of the target I'm using, the only entry that doesn't seem to make sense is the 4th one here:

"sectors": [
            [
                134217728, 
                16384
            ], 
            [
                134283264, 
                65536
            ], 
            [
                134348800, 
                131072
            ], 
            [
                536854528, 
                4
            ]
        ],

I think the first three are saying, at 134217728 (aka 0x0800000), sector sizes are 16k large. This continues until 134283264 (aka 0x08010000) where sectors are now 64k large. Finally, the third entry says at 134348800 (aka 0x08020000) sectors are 128k large onward until end of ROM.

That last entry though of 536854528 (aka 0x1FFFC000) is a mystery to me. Does my understanding make sense?

[40Grit]

is your bootloader based in mbed os?

is your bootloader relocating the vector table?

mbed as i recall relocates the vector by default.

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.

[DrynnBavis]

is your bootloader based in mbed os?

yes

is your bootloader relocating the vector table?

I don't know how to do this so probably not.

mbed as i recall relocates the vector by default.

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.

What's the actionable item on my end here? How do I check the value of vtor, and what value am I expecting to be there?

Pretty new to this so if you wouldn't mind being as verbose as possible, it'd be appreciated.

[0xc0170]

1. What documentation did you follow? The issues above look to me like they should be addressed in the docs - how to add custom MCU, define sectors, add to cmsis pack and be able to enable and build the bootloader. If there are not, please provide a list of what you have followed and what is missing. we should fix these

cc @ARMmbed/team-st-mcd (for checking the above sectors)

2. What does Kernel start return? It might be a different problem than your bootloader config, I would check why you get that 117 line MBED_ERROR.

[DrynnBavis]

@0xc0170 Bit of an update from my work in another thread...
I've been able to have the bootloader work when it's stripped back to do nothing but print "booting to main app space" and then actually calling mbed_app_start(). Then I can actually do what I want in the main app.

Once I add my block device constructor call back to the bootloader like this:

BlockDevice *bd = BlockDevice::get_default_instance();

then I'm unable to successfully initalise the kernel for the new app. While initalising, an SVC handler call within irq_cm4f.S returns a hard fault from within except.S. Not sure how to debug any further without giving gdb context of these assembly source files (if that's possible). You mentioned:

What does Kernel start return?

How would I check this?

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.

[40Grit]

The end of an era.

Long live questions.

[0Grit]

@adbridge @0xc0170 Is there an Mbed Blog in the works announcing the new community policies?

[adbridge]

@loverdeg-ep yes there should be one coming soon.

[adbridge]

The end of an era.

Long live questions.

Questions and enhancements will still be welcomed but should go to the forum going forward. This allows us to concentrate on the real bugs on GitHub whilst the forums can be more of an open discussion area.

[40Grit]

Tottaly agree with the change. Brings a tear to my eye seeing the project growing up, Founders moving on etc...

I think the policy change is a significant step forward, both for image, accessibility, and maintenance of the project.