Mbed-os: How to enable pretty bars on targets where they don't actually work?

[MikeDK]

Description

• Type: Question
• Related issue: #5929
• Priority: Minor

---

Question

I was surprised about those new pretty bars (and the fact that they are the standard compile output now unless --stats-depth is given).

I have observed that they are not working for all targets ... for example, for my EFM32PG12 board they are working - but not for NUCLEO_L432KC and NUCLEO_F746ZG.

I read something about cmsis packs in the pull request, so I searched for something like that in the mbed-os dir ... I found mbed-os/tools/arm_pack_manager/index.json where I can see a big list of targets ... but both nucleo target cpus I wrote above are present in that file.... so I guess this is not what I need ;)

So, the question is: where to add yet unsupported targets to get the pretty bars?

[geky]

@theotherjimmy, @AnotherButler, is there documentation over cmsis-packs? Seems important if the tools are going to start taking advantage of the information there.

I'm not that familiar with cmsis-packs, but it looks like the STM32L432KC and STM32F746ZG are both missing IRAM regions. I believe it's optional for cmsis-packs, but without RAM info we can't really render how much memory is being used.

It should still be showing a oneline summary of the memory sections. Does this still show up for you?

$ mbed compile -m ARM_BEETLE_SOC -t GCC_ARM
Building project mbed-os-prettyoutput (ARM_BEETLE_SOC, GCC_ARM)
Scan: .                                                        
Scan: env                                                      
Scan: mbed                                                     
Scan: FEATURE_BLE                                              
Text 99KB Data 2.84KB BSS 13KB ROM 102KB RAM 15.8KB            <-------------
Image: BUILD/ARM_BEETLE_SOC/GCC_ARM/mbed-os-prettyoutput.bin   

The logic is here if you think it needs to be changed:
https://github.com/ARMmbed/mbed-os/blob/master/tools/memap.py#L648-L655

[Mirrored to Jira]

[geky]

Sorry, wrong button
[Mirrored to Jira]

[AnotherButler]

We have some documentation in these two locations:
https://os.mbed.com/docs/v5.7/tools/adding-and-configuring-targets.html and https://os.mbed.com/docs/v5.7/reference/contributing-target.html
[Mirrored to Jira]

[MikeDK]

@geky yes it is showing the oneline summary, but no bars...

is it possible to check whether all information necessary for the bars is present, and if not, fall back to the table style?
[Mirrored to Jira]

[jeromecoutant]

Hi
I made some quick check about this feature.
Information comes from tools/arm_pack_manager/index.json, right ?

I checked for ex NUCLEO_L432KC, and it is true that STM32L432KC doesn't provide any RAM indication.

If we check in http://www.keil.com/pack/Keil.STM32L4xx_DFP.pdsc
it seems that IRAM information is present but at Subfamily level, not at Device level...

So for me, issue should be corrected tools/arm_pack_manager/index.json
Information extraction is not complete ?

Thx

[Mirrored to Jira]

[theotherjimmy]

@jeromecoutant That's correct. We would need to update the extraction mechanism and re-run it to get that info.
[Mirrored to Jira]

[geky]

is it possible to check whether all information necessary for the bars is present, and if not, fall back to the table style?

@theotherjimmy what are your thoughts on this?
[Mirrored to Jira]

[theotherjimmy]

@geky That sounds do-able. I would personally prefer the simplified output, as I already specify --stats-depth 0 to minimize visual clutter on compile.
[Mirrored to Jira]

[jeromecoutant]

@theotherjimmy does someone try to update the extraction mechanism ?

@0xc0170 you should update the question label as it is a bug ?

Thx

[Mirrored to Jira]

[theotherjimmy]

@jeromecoutant Update on that extraction mechanism: I was able to get a prototype working.
This is the equivalent entry:

 "STM32L432KCUx": {
    "name": "STM32L432KCUx",
    "memories": {
      "IROM1": {
        "access": {
          "read": true,
          "write": false,
          "execute": true
        },
        "start": 134217728,
        "size": 262144,
        "startup": false
      },
      "IRAM1": {
        "access": {
          "read": true,
          "write": true,
          "execute": false
        },
        "start": 536870912,
        "size": 49152,
        "startup": false
      },
      "IRAM2": {
        "access": {
          "read": true,
          "write": true,
          "execute": false
        },
        "start": 268435456,
        "size": 16384,
        "startup": false
      }
    },
    "algorithms": [
      {
        "file_name": "CMSIS/Flash/STM32L4xx_256.FLM",
        "start": 134217728,
        "size": 262144,
        "default": false
      },
      {
        "file_name": "CMSIS/Flash/STM32L4xx_SB_OPT.FLM",
        "start": 536836096,
        "size": 20,
        "default": false
      },
      {
        "file_name": "CMSIS/Flash/STM32L4R9I_EVAL.FLM",
        "start": 2415919104,
        "size": 67108864,
        "default": false
      }
    ]
  },

Which uses the variant present in the CMSIS packs. I think it got the memories correctly.
[Mirrored to Jira]

[jeromecoutant]

Hi
Good!
Note after some check I noticed that RAM part was missing for some L4 and F7, and ROM part was missing for F756
Thx
[Mirrored to Jira]

[theotherjimmy]

@jeromecoutant Yeah, it's going to be a bit before we get this new parser in. OTOH, the new parser is a 60-180x speedup! (it takes 400ms to parse __every__ CMSIS pack)
[Mirrored to Jira]

[jeromecoutant]

Hi

I didn't see any updates on arm_pack_manager file ?

Thx

[Mirrored to Jira]

[theotherjimmy]

Yeah, it's going to be a bit before we get this new parser in.

This is still true. I'm working on it.
[Mirrored to Jira]

[jeromecoutant]

Hi @theotherjimmy

No update on arm_pack_manager file ? :-)

Regards,

[Mirrored to Jira]

[theotherjimmy]

I'm gearing up for release. It'll be a bit though, I have many things on my plate right now.
[Mirrored to Jira]

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/IOTCORE-135

[jeromecoutant]

Hi
Maybe you can deliver the current work?
as it seems useful for #8607 ?
Thx

[cmonr]

@jeromecoutant Question. Why is this still needed since the pretty bars commit was reverted?

I haven't heard of any internal activity around this, and I suspect @theotherjimmy is swamped with other fixes, so I'm wondering if this should even still be open.

[theotherjimmy]

@cmonr Not to be too contradictory, but I'm working on this issue right now by using cmsis-pack-manager 0.2.2 as the backend for the tools/arm_pack_manager module. It's been working well so far.

[cmonr]

@theotherjimmy Fine by me. I just happened to come across this in an old list while doing some pruning.

[jeromecoutant]

Why is this still needed since the pretty bars commit was reverted?

I agree that we could close this pretty bars issue,
and open an new one to correct the arm_pack_manager file.

[mark-edgeworth]

Looks like this issue should have closed a while back :-)