Mbed-os: Over-specific STM32F targets

[tbe]

Description of defect

The STM32F Targets are far more specific then required. This leads to confusion during the implementation of custom targets.

For example the STM32F429 Family includes:
STM32F429VG, STM32F429ZG, STM32F429IG, STM32F429BG, STM32F429NG,
STM32F429AG, STM32F429VI, STM32F429ZI, STM32F429II,, STM32F429BI,
STM32F429NI,STM32F429AI, STM32F429VE, STM32F429ZE, STM32F429IE, STM32F429BE,
STM32F429NE

But the target is STM32F429xI

Target(s) affected by this defect ?

For example all STM32F429 MCU's not ending on I

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

all

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

e642a7d8b3609a7c903e042cd772f00a5d299088

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

mbed-cli 1.10.2

How is this defect reproduced ?

Example for a custom target for Core429i with STM32F429GT does not compile, as long as the extra_label "STM32F429xI",is missing.

{ "Core429I": { "inherits": [ "FAMILY_STM32" ], "core": "Cortex-M4F", "extra_labels_add": [ "STM32F4", "STM32F429", "STM32F429GT", "STM32F429xT", "STM32F429xx" ], "config": { "usb_speed": { "help": "USE_USB_OTG_FS or USE_USB_OTG_HS or USE_USB_HS_IN_FS", "value": "USE_USB_HS_IN_FS" } }, "device_has_add": [ "ANALOGOUT", "CAN", "SERIAL_ASYNCH", "TRNG", "MPU" ], "device_name": "STM32F429GTx", "bootloader_supported": false, "mbed_rom_start": "0x08000000", "mbed_rom_size": "0x800000", "mbed_ram_start": "0x20000000", "mbed_ram_size": "0x180000" } }

[jeromecoutant]

Hi @tbe

Note that MBED compilation script way of working is to compile all except targets directory.
In this targets directory, you have to specify manually the path.

So as all the MCU, you have indicated, share the same CMSIS information, we create a sub level between STMF4 family and STMF429xx chip:
Path: targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F429xI
So, have to be in the extra labels:

• STM: set as you inherit from FAMILY_STM32
• STM32F4
• STM32F429xI
  The other can be removed...

[tbe]

So as all the MCU, you have indicated, share the same CMSIS information, we create a sub level between STMF4 family and STMF429xx chip:
Path: targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F429xI

Yes, but the sublevel naming does not correspond with the chipnames. ( not ending on I). Another example are the target directories for TARGET_STM32F303x8, TARGET_STM32F303xC and TARGET_STM32F303xE. They use all the same CMSIS information and linker scripts. The only difference is in the copyright header, as the CMSIS files are copied in different years.

Why is there not just TARGET_STM32F303xx ?

[jeromecoutant]

Why is there not just TARGET_STM32F303xx ?

You-re right.
In the STM32 naming rules, this 2nd letter (8, C, E in F303 case), indicates FLASH size.
So, as all targets in the same sub-family share the same linker scripts, we have grouped the targets like this.
This is quite "historical"...
Now, as mbed compilation scripts provide mbed_rom_start and mbed_rom_size values, we could change some directory names in group targets in a different way.

[jeromecoutant]

Example for a custom target for Core429i with STM32F429GT does not compile

Note that STM32F429GT doesn't exist...?

[tbe]

Note that STM32F429GT doesn't exist...?

Typo. STM32F492IGT6 is the MCU.

Am 31. März 2020 09:33:53 MESZ schrieb Jerome Coutant [e-mail]:

Example for a custom target for Core429i with STM32F429GT does not
compile

Note that STM32F429GT doesn't exist...?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/ARMmbed/mbed-os/issues/12713#issuecomment-606453377

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[0xc0170]

Please update the issue header with the missing information.

I already did, should be OK now.

@jeromecoutant Let us know what shall be done for this ticket - any refactor ?

[jeromecoutant]

No... I don't plan to change these families.
Note I don't understand there is some issue.

[ciarmcom]

@tbe thank you for the update.It appears however that there is still some missing information:

We cannot automatically identify a release based on the version of Mbed OS that you have provided.
Please provide either a single valid sha of the form #abcde12 or #3b8265d70af32261311a06e423ca33434d8d80de
or a single valid release tag of the form mbed-os-x.y.z .

Please update the issue header with the missing information.
NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.

[ciarmcom]

@tbe thank you for the update.It appears however that there is still some missing information:

We cannot automatically identify a release based on the version of Mbed OS that you have provided.
Please provide either a single valid sha of the form #abcde12 or #3b8265d70af32261311a06e423ca33434d8d80de
or a single valid release tag of the form mbed-os-x.y.z .

Please update the issue header with the missing information.
NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.

[ciarmcom]

@tbe thank you for raising this issue.Please take a look at the following comments:

We cannot automatically identify a release based on the version of Mbed OS that you have provided.
Please provide either a single valid sha of the form #abcde12 or #3b8265d70af32261311a06e423ca33434d8d80de
or a single valid release tag of the form mbed-os-x.y.z .

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

[0xc0170]

I also do not understand what shall be fixed, @tbe have you fixed it locally for your custom target? Something you can share how it shall look like?

Isn't this an issue with a target naming, as defined above STM32F429xI its too generic in this sense? I used to have a problem similar to this in exporters (debugger would need more specific target rather than xxxL for instance). a custom target should be more specific in this case than just STM32F429xI (I don't recall what x letter stands for , if different pin layout/flash memory etc).

[0xc0170]

I read the issue again. To fix, we could have STM32F429xx instead of STM32F429xI as not all 429 have xl.
@jeromecoutant Does that make sense to rename and provide more generic boilerplate code in the target tree?

[jeromecoutant]

Waiting for #12801 discussion conclusion

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2435