mbed toolchain emits broken elf file for STM32H743ZI2

[rotu]

Description of defect

Mbed Studio generates an elf file that unpredictably hard-faults (usually with a segfault) when you try to debug it (with Mbed Studio, or any other elf debugger)

This is because it creates <mytarget>_application.elf and <mytarget>.bin file but no self-contained <mytarget>.elf file. When Mbed Studio loads the <mytarget>_application.elf for debug, it is missing the bootloader, which performs necessary initialization. This is true even if the target does not have the BOOTLOADER feature, for the STM_H743ZI2 chip because it has multiple ROM regions.

Target(s) affected by this defect ?

NUCLEO_H743ZI2. Probably many others.

Toolchain(s) (name and version) displaying this defect ?

ARMC6

What version of Mbed-os are you using (tag or sha) ?

14e5d30

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio 1.6.1

How is this defect reproduced ?

Build blinky on a NUCLEO-H743ZI2 and deploy it with the debug button.

[rotu]

I think this is also responsible for the NOCP crash seen in #13050

[0xc0170]

cc @ARMmbed/team-st-mcd

[0xc0170]

This is true even if the target does not have the BOOTLOADER feature, for the STM_H743ZI2 chip because it has multiple ROM regions.

@ARMmbed/team-st-mcd Is this correct? We got targets that have multiple ROM and I do not recall having issues with them.

This is because it creates _application.elf and .bin file but no self-contained .elf file. When Mbed Studio loads the _application.elf for debug, it is missing the bootloader, which performs necessary initialization.

Reading the guide, https://os.mbed.com/docs/mbed-os/v6.10/program-setup/creating-and-using-a-bootloader.html#unmanaged-bootloader - are you using managed or unmanaged bootloader?

[rotu]

Reading the guide, https://os.mbed.com/docs/mbed-os/v6.10/program-setup/creating-and-using-a-bootloader.html#unmanaged-bootloader - are you using managed or unmanaged bootloader?

I don’t know how to answer that. If it’s using a bootloader at all is a surprise based on that documentation. Setting "target.features_remove": ["BOOTLOADER"] seems to make no difference.

[rotu]

My inference that this is because of the multiple ROM regions is based on

mbed-os/tools/toolchains/mbed_toolchain.py

Lines 742 to 748 in a3be10c

	# Absolute path of the final linked file
	if self.config.has_regions:
	elf = join(new_path, tail + '_application.elf')
	mapfile = join(new_path, tail + '_application.map')
	else:
	elf = join(new_path, tail + '.elf')
	mapfile = join(new_path, tail + '.map')

I could be misunderstanding the cause

[jeromecoutant]

This is true even if the target does not have the BOOTLOADER feature, for the STM_H743ZI2 chip because it has multiple ROM regions.

@ARMmbed/team-st-mcd Is this correct? We got targets that have multiple ROM and I do not recall having issues with them.

Hi

From CMSIS pack (input for pyOCD), STM32H743ZITx may be considered as multiple ROM regions:

          <memory name="FLASH_Bank1" access="rx" start="0x08000000" size="0x00100000" default="1" startup="1"/>
          <memory name="FLASH_Bank2" access="rx" start="0x08100000" size="0x00100000" default="1" startup="1"/>

But it is the same FLASH with 2 banks. In Mbed configuration, we squash it:
https://github.com/ARMmbed/mbed-os/blob/master/targets/targets.json#L2947-L2948

[rotu]

But it is the same FLASH with 2 banks. In Mbed configuration, we squash it:

Here's the BUILD directory
BUILD.zip

I don't think they're getting squashed. In BUILD/NUCLEO_H743ZI2/ARMC6/.link_options, I see two distinct ROM regions --predefine="-DMBED_ROM_START=0x8000000" --predefine="-DMBED_ROM_SIZE=0x200000" --predefine="-DMBED_ROM1_START=0x8100000" --predefine="-DMBED_ROM1_SIZE=0x100000"

[jeromecoutant]

I don't think they're getting squashed. In BUILD/NUCLEO_H743ZI2/ARMC6/.link_options, I see two distinct ROM regions --predefine="-DMBED_ROM_START=0x8000000" --predefine="-DMBED_ROM_SIZE=0x200000" --predefine="-DMBED_ROM1_START=0x8100000" --predefine="-DMBED_ROM1_SIZE=0x100000"

"-DMBED_ROM_SIZE=0x200000" => this is the size of full flash (squashed)

"-DMBED_ROM1_SIZE=0x100000" => MBED_ROM1_SIZE is not used at all in linker scripts

[rotu]

I don't think they're getting squashed. In BUILD/NUCLEO_H743ZI2/ARMC6/.link_options, I see two distinct ROM regions --predefine="-DMBED_ROM_START=0x8000000" --predefine="-DMBED_ROM_SIZE=0x200000" --predefine="-DMBED_ROM1_START=0x8100000" --predefine="-DMBED_ROM1_SIZE=0x100000"

"-DMBED_ROM_SIZE=0x200000" => this is the size of full flash (squashed)

"-DMBED_ROM1_SIZE=0x100000" => MBED_ROM1_SIZE is not used at all in linker scripts

I guess I can't blame those defines, then. I mis-assumed has_regions actually means "does the target have multiple ROM regions?".

If I hack Config.has_regions to print before it returns, I can see that the mbed_rom_size, mbed_rom_start properties are causing the toolchain to act like I've requested a bootloader.

To confirm, removing these two properties from the MCU_STM32H743xI target and then building produces an elf file not ending in _application.elf (yay!). I haven't yet verified that this elf file runs, but I suspect it does. So maybe this "squashing" is doing more harm than good.

from pprint import pprint
attrs = {o.split(".")[1] for o in ROM_OVERRIDES}
pprint({
    k:v for (k,v) in self.target.__dict__.items() if k in attrs
})

{'app_offset': None,
'bootloader_img': None,
'header_format': None,
'header_offset': None,
'mbed_app_size': None,
'mbed_app_start': None,
'mbed_rom_size': '0x200000',
'mbed_rom_start': '0x08000000',
'restrict_size': None}

[0xc0170]

@rotu Please close if this is not an issue anymore

[rotu]

@0xc0170 It's still an issue and I have no idea how to fix it.

1. After editing targets.json, the .elf file is still crashing pretty early, so a missing bootloader was not the [only?] issue
2. Editing the targets.json should not be necessary to get blinky to build on an unmodified board
3. Presumably that mbed_rom_size/mbed_rom_start in targets.json served some purpose which may or may not be related to the crashing

[jeromecoutant]

@rotu
FYI: jeromecoutant@e91da09