CMSIS-pack update for STM32L-family #12163

JanneKiiskila · 2019-12-20T20:53:31Z

Updated CMSIS-pack for the STM32L-family (this is a very large
family, so the change is very large).

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

@ARMmbed/team-st-mcd @jeromecoutant @adbridge @0xc0170

Updated CMSIS-pack for the STM32L-family (this is a very large family, so the change is very large).

JanneKiiskila · 2019-12-20T20:54:19Z

No rainbow unicorns anymore? GitHub now says; "38,184 additions, 34,391 deletions not shown because the diff is too large. Please use a local Git client to view these changes."

ciarmcom · 2019-12-20T22:00:39Z

@JanneKiiskila, thank you for your changes.
@jeromecoutant @adbridge @0xc0170 @ARMmbed/mbed-os-tools @ARMmbed/mbed-os-maintainers please review.

JanneKiiskila · 2019-12-21T18:21:01Z

Seems we have some failure, but the error note is not very helpful, as it doesn't pinpoint any place in the actual index.json file.

=================================== FAILURES ===================================
_____________________________ test_bl_has_sectors ______________________________
    def test_bl_has_sectors():
        """Assert a bootloader supporting pack has sector information"""
        cache = Cache(True, True)
        named_targets = (
            target for target in TARGETS if
            (hasattr(target, "device_name") and getattr(target, "bootloader_supported", False))
        )
        for target in named_targets:
            assert target.device_name in cache.index,\
                ("Target %s contains invalid device_name %s" %
                 (target.name, target.device_name))
>           assert cache.index[target.device_name]["sectors"],\
                ("Device name %s is misssing sector information" %
                 (target.device_name))
E           KeyError: 'sectors'
tools/test/targets/target_test.py:51: KeyError

JanneKiiskila · 2019-12-22T15:49:30Z

I think we're hitting issue #11798

bulislaw · 2019-12-23T09:34:06Z

@JanneKiiskila I'm guessing that's pending the tools fix, so unlikely to happen before new years.

jeromecoutant · 2020-01-08T10:25:15Z

Could we start CI ?
Thx

0xc0170 · 2020-01-08T10:33:21Z

CI started

0xc0170 · 2020-01-08T10:34:11Z

I started our CI. Although it might show the same problem as Travis, failure with sectors

mbed-ci · 2020-01-08T11:28:06Z

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_cloud-client-pytest

JanneKiiskila · 2020-01-08T11:41:57Z

I'll likely patch it in manually to get this moving...

JanneKiiskila · 2020-01-08T12:59:44Z

Ok, turns out there is a bigger problem. With the latest toolchain - no sector info whatsoever is created. For example the target STM32L011D3Px had sector information:

        "name": "STM32L011D3Px",
        "processor": {
            "Symmetric": {
                "core": "CortexM0Plus", 
                "fpu": "None", 
                "mpu": "NotPresent", 
                "units": 1
            }
        }, 
        "sectors": [
            [
                134217728, 
                128
            ], 
            [
                134742016, 
                512
            ], 
            [
                536346624, 
                20
            ]
        ], 
        "sub_family": "STM32L011",
        "vendor": "STMicroelectronics:13"

if we look at the produced section for it - the whole sectors -keyword is missing completely. It's not even null.

  "STM32L011D3Px": {
    "name": "STM32L011D3Px",
    "memories": {
      "IROM1": {
        "access": {
          "read": true,
          "write": false,
          "execute": true,
          "peripheral": false,
          "secure": false,
          "non_secure": false,
          "non_secure_callable": false
        },
        "start": 134217728,
        "size": 8192,
        "startup": true,
        "default": true
      },
      "IRAM1": {
        "access": {
          "read": true,
          "write": true,
          "execute": false,
          "peripheral": false,
          "secure": false,
          "non_secure": false,
          "non_secure_callable": false
        },
        "start": 536870912,
        "size": 2048,
        "startup": false,
        "default": true
      }
    },
    "algorithms": [
      {
        "file_name": "CMSIS/Flash/STM32L0xx_8.FLM",
        "start": 134217728,
        "size": 8192,
        "default": true,
        "ram_start": null,
        "ram_size": null
      },
      {
        "file_name": "CMSIS/Flash/STM32L01_2x_EEPROM.FLM",
        "start": 134742016,
        "size": 512,
        "default": false,
        "ram_start": null,
        "ram_size": null
      },
      {
        "file_name": "CMSIS/Flash/STM32L0xx_OPT.FLM",
        "start": 536346624,
        "size": 20,
        "default": false,
        "ram_start": null,
        "ram_size": null
      }
    ],
    "processor": {
      "Symmetric": {
        "units": 1,
        "core": "CortexM0Plus",
        "fpu": "None",
        "mpu": "NotPresent"
      }
    },
    "from_pack": {
      "vendor": "Keil",
      "pack": "STM32L0xx_DFP",
      "version": "2.0.1",
      "url": "http://www.keil.com/pack/"
    },
    "vendor": "STMicroelectronics:13",
    "family": "STM32L0 Series",
    "sub_family": "STM32L011"
  },

JanneKiiskila · 2020-01-08T14:26:58Z

CMSIS-pack information itself has this information:

        <!-- *************************  Device 'STM32L011D3'  ***************************** -->

        <device Dname="STM32L011D3">
          <memory id="IROM1"                              start="0x08000000" size="0x00002000" startup="1" default="1"/>
          <memory id="IRAM1"                              start="0x20000000" size="0x00000800" init   ="0" default="1"/>
          <algorithm name="CMSIS/Flash/STM32L0xx_8.FLM"   start="0x08000000" size="0x00002000"             default="1"/>
          <variant Dvariant="STM32L011D3Px"> <feature type="SOP" n="14"/> </variant>

        </device>

So, the sector information actually is not there (as in the way that it would define the flash erase sectors).

The numbers in the sectors don't actually seem to match anything sensible to me, at least?
It's very painful that we are using different numeric formats in the different files, as that makes the comparisons manually (at least if you're not Matrix level guy at recognizing hex and decimal the same way, looking at @kjbracey-arm here) a bit tedious. Anyways, we have in the original 3 sector defines.

        "sectors": [
            [
                134217728, 
                128
            ], 
            [
                134742016, 
                512
            ], 
            [
                536346624, 
                20
            ]

Which, in hex would be:

sector #	address	size
1	0x8000000	0x80
2	0x8080000	0x200
3	0x1FF80000	0x14

Which quite does not compute for me. Seems to me the sector information is somehow manually maintained by digging the reference manual for that information (or in case of some of the STM chips, they have this information also in the .h-files).

jeromecoutant · 2020-01-09T12:44:13Z

Hi
Waiting for this PR before introducing new STM32L5 family
Thx
@MarceloSalazar

JanneKiiskila · 2020-01-09T12:49:33Z

I think I will re-do this PR with a smaller scope, i.e. bring in the L5 ONLY, rather than the whole thing.

jeromecoutant · 2020-01-20T10:03:44Z

Any update...
Sorry for pushing....

adbridge · 2020-01-20T13:13:32Z

Any update...
Sorry for pushing....

@JanneKiiskila ^^^^

mergify · 2020-02-03T16:35:45Z

This PR cannot be merged due to conflicts. Please rebase to resolve them.

JanneKiiskila · 2020-02-14T08:05:11Z

This one it now out of date/has merge conflict, closing it out -> needs to be re-started.

CMSIS-pack update for STM32L-family

51313c9

Updated CMSIS-pack for the STM32L-family (this is a very large family, so the change is very large).

ciarmcom requested review from 0xc0170, adbridge, jeromecoutant and a team December 20, 2019 22:00

ciarmcom added the needs: review label Dec 20, 2019

jeromecoutant approved these changes Jan 2, 2020

View reviewed changes

0xc0170 added needs: work and removed needs: review labels Jan 8, 2020

JanneKiiskila mentioned this pull request Jan 8, 2020

tools/target/target_test.py does not handle missing sector keyword correctly #12219

Closed

JanneKiiskila closed this Feb 14, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CMSIS-pack update for STM32L-family #12163

CMSIS-pack update for STM32L-family #12163

JanneKiiskila commented Dec 20, 2019 •

edited

Loading

JanneKiiskila commented Dec 20, 2019

ciarmcom commented Dec 20, 2019

JanneKiiskila commented Dec 21, 2019

JanneKiiskila commented Dec 22, 2019

bulislaw commented Dec 23, 2019

jeromecoutant commented Jan 8, 2020

0xc0170 commented Jan 8, 2020

0xc0170 commented Jan 8, 2020

mbed-ci commented Jan 8, 2020

JanneKiiskila commented Jan 8, 2020

JanneKiiskila commented Jan 8, 2020

JanneKiiskila commented Jan 8, 2020 •

edited

Loading

jeromecoutant commented Jan 9, 2020

JanneKiiskila commented Jan 9, 2020

jeromecoutant commented Jan 20, 2020

adbridge commented Jan 20, 2020

mergify bot commented Feb 3, 2020

JanneKiiskila commented Feb 14, 2020

CMSIS-pack update for STM32L-family #12163

CMSIS-pack update for STM32L-family #12163

Conversation

JanneKiiskila commented Dec 20, 2019 • edited Loading

Pull request type

Reviewers

JanneKiiskila commented Dec 20, 2019

ciarmcom commented Dec 20, 2019

JanneKiiskila commented Dec 21, 2019

JanneKiiskila commented Dec 22, 2019

bulislaw commented Dec 23, 2019

jeromecoutant commented Jan 8, 2020

0xc0170 commented Jan 8, 2020

0xc0170 commented Jan 8, 2020

mbed-ci commented Jan 8, 2020

Test run: FAILED

JanneKiiskila commented Jan 8, 2020

JanneKiiskila commented Jan 8, 2020

JanneKiiskila commented Jan 8, 2020 • edited Loading

jeromecoutant commented Jan 9, 2020

JanneKiiskila commented Jan 9, 2020

jeromecoutant commented Jan 20, 2020

adbridge commented Jan 20, 2020

mergify bot commented Feb 3, 2020

JanneKiiskila commented Feb 14, 2020

JanneKiiskila commented Dec 20, 2019 •

edited

Loading

JanneKiiskila commented Jan 8, 2020 •

edited

Loading