Do we really need to provide a .pack in the debug task ?

[fred-r]

Arm.cmsis-csolution 0.17.0

        {
            "type": "embedded-debug.flash",
            "serialNumber": "${command:device-manager.getSerialNumber}",
            "program": "${command:cmsis-csolution.getBinaryFile}",
            "cmsisPack": "${workspaceFolder}/.vscode/my_dfp.pack",
            "problemMatcher": [],
            "verifyFlash": false,
            "label": "embedded-debug.flash: Flash Device",
            "group": {
                "kind": "build",
                "isDefault": true
            }
        },

==> as you can see we need to provide a path to a .pack file.

As this pack has been installed in opur system(for instance in CMSIS_PACK_ROOT), can't we specify where the pdsc is isntalled ?

[thegecko]

Yes, cmsisPack can be specified in the form <vendor>::<pack>@<version> and the CMSIS pack root will be checked for that pack.

For example:

{
    ...
    "cmsisPack": "Keil::STM32H7xx_DFP@3.0.0"
    ...
}

You are also able to specify a path to just the pdsc file (using the pdsc config key), but there are often dependent files (e.g. flm files) which need to be found in the pack aswell).

Finally, you can automatically determine the pack from the selected device in the device manager using:

{
    ...
    "cmsisPack": "${command:device-manager.getDevicePack}"
    ...
}

Hope this helps!

[fred-r]

Thanks, I tried the automatic one but there is a signeture check failure:

My DFP pack is not published, it is a local dev pack.

Same issue with the other method

[thegecko]

OK, there's a few things going here. We have an online cache of published packs which the tool tries to use if it can't find the pack locally.

It looks like there are certificate or proxy issues with using this service on from your machine.

However, it shouldn't be using the pack service if we get it to pick up your local cache.

Could you confirm the packCachePath setting in Settings>Extensions>CMSIS Csolution is set to your pack cache root?

[fred-r]

I am working with local packs so basically I do not use the structure of the CMSIS_PACK_ROOT folder.

For instance in the YML of my projects I indicate where to find the packs:

  packs:
    - pack: ARM::CMSIS
      path: ../../../../../../../cmsis

This is where the pdsc and installed pack is located.

[thegecko]

You have a few options.

1. If you only need the pdsc file (no flm files, etc.), you can specify that in the config instead of the cmsisPack:

{
    ...
    "pdsc": "<fully qualified path to your pdsc file>"
    ...
}

2. As long as your folder structure adheres to the cmsis pack structure of <vendor>/pack</version> you can set the packCachePath to be the parent of this and specify a pack triplet.

e.g. if your pack exists at /my_packs/my_vendor/my_pack/1.0.0, set packCachePath to /my_packs and set the cmsisPack to my_vendor::my_pack@1.0.0;

3. You can set cmsisPack to point at a fully qualified path to a pack file (how you seem to be using it today)
4. You can set cmsisPack to be the folder of an extracted (unpacked) pack.

This last option may be what you need

[fred-r]

Unfortunately we simplify the tree:

$ tree -L 2 cmsis/
cmsis/
|-- ARM.CMSIS.pdsc
|-- ARM.CMSIS.sha1
|-- CMSIS
|   |-- Core
|   |-- Core_A
|   |-- DAP
|   |-- DSP
|   |-- Documentation
|   |-- Driver
|   |-- NN
|   |-- RTOS
|   |-- RTOS2
|   `-- Utilities
|-- Device
|   |-- ARM
|   |-- _Template_Flash
|   `-- _Template_Vendor
`-- LICENSE.txt

If we give the pdsc, can't the tool just assume that the files are relative to this pdsc location ?

[thegecko]

If we give the pdsc, can't the tool just assume that the files are relative to this pdsc location ?

This is an untested scenario, would be interested to see if it works...

[jeromecoutant]

would be interested to see if it works...

It should work :-) As I suppose that VSC extension is first unzipping pack file before using files... So providing files should be even easier...?

[thegecko]

As I suppose that VSC extension is first unzipping pack file before using files... So providing files should be even easier...?

That's right, it's just untested :-)

Is there any more information needed to resolve this issue?

[jeromecoutant]

mcgordonite closed this as completed

So we can use a pdsc file now ?

[thegecko]

So we can use a pdsc file now ?

You can, it's just untested in the extension. Have you tried specifying a pdsc entry?

[VVESTM]

Hi, I have made some more tests on this subject.

If using "cmsisPack": "${workspaceFolder}/dfp/stm32u5xx/STMicroelectronics.stm32u5xx_dfp.pdsc", when flashing, I have this error : ENOENT: no such file or directory, open 'C:XXXXXXX/dfp/stm32u5xx/STMicroelectronics.stm32u5xx_dfp.pdsc/dfp.stm32u5xx.pdsc' => the filename is not the right one.

If using "pdsc": "${workspaceFolder}/dfp/stm32u5xx/STMicroelectronics.stm32u5xx_dfp.pdsc", as mentioned by @thegecko, the FLM files are missing. I don't understang why because those files are referrenced from the .pdsc...

[thegecko]

cmsisPack is designed to reference a pack. This can be one of the following:

• path or URL to a .pack file
• a pack reference (<vendor>::<pack>@<version>)
• a path to a folder containing an "unpacked" pack (e.g. a pack cache location)

In all cases, the pdsc file is then determined by the pack naming and structure. This is the preferred way of working which is how a user would consume existing packs

The pdsc file can be explicitly set, but infrastructure such as flm loading isnt currently supported because the location of the surrounding pack doesn't get set. We can look into adding this support.

In the meantime, this issue can be worked around in two ways:

Easiest is to se the cmsisPack entry to point at the folder containing the PDSC file and ensure the pdsc file is named correctly (the folder structure and filename need to match). e.g.:

/some/path/<vendor>/<pack>/<version>/<vendor>.<pack>.pdsc

then set the cmsisPack to:

{
    ...
    "cmsisPack": "/some/path/<vendor>/<pack>/<version>",
    ...
}

Alternatively, set the pdsc to the full path of the pdsc file and specify the flm path entry (or flm paths array) to point at the flm files you need to use (this is undocumented):

{
    ...
    "pdsc": "/full/path/to/file.pdsc",
    "flms": [
        "/full/path/to/file1.flm",
        "/full/path/to/file2.flm",
    ]
    ...
}

[VVESTM]

Ok, thanks @thegecko. I was able to test with "pdsc" and "flms".

[thegecko]

@VVESTM

We have just pushed out a new release of the debug extension which should mean you no longer have to specify the flm files and can just supply the pdsc file as expected.

Please let us know if his helped.

[VVESTM]

Just tested with ARM CMSIS Csolution v1.0.1. For now, it is still failing on my side.

I have, in tasks.json:

        {
            "type": "embedded-debug.flash",
            "serialNumber": "${command:device-manager.getSerialNumber}",
            "program": "${command:cmsis-csolution.getBinaryFile}",

            "pdsc": "${workspaceFolder}/dfp/stm32u5xx/STMicroelectronics.stm32u5xx_dfp.pdsc",
            "problemMatcher": [],
            "verifyFlash" : false,
            "label": "embedded-debug.flash: Flash Device",
            "group": {
                "kind": "build",
                "isDefault": true
             }
        }

Building is OK. When trying to flash my board with RUN command, I have :

  *  Executing task: embedded-debug.flash: Flash Device 

  Device Selected: 001A00094D46501120383832
  Parse debug description...
  Create system description...
  Connect to debug unit (ST-Link)...
  Configure debug unit (SWD @ 10000000 Hz)...
  Create device map...
  Add Flash Algorithm...
  First argument to DataView constructor must be an ArrayBuffer
  Flash failed

  *  The terminal process terminated with exit code: 1. 
  *  Terminal will be reused by tasks, press any key to close it. 

If I add again the .flm, I am able to flash.

[thegecko]

OK, thanks for the feedback. Does your pdsc file have the flm files referenced in it?

[VVESTM]

Yes, here is an extract of the .pdsc file :

        <device Dname="STM32U585AI">
          <compile header="Include/stm32u5xx.h" define="STM32U585xx"/>
          <memory name="FLASH" access="rx" start="0x08000000" size="0x200000" default="1"/>
          <memory name="FLASH_S" access="rx" start="0x0C000000" size="0x200000" alias="FLASH"/>
          <algorithm name="Flash/STM32U5xx_2M_0800.FLM" start="0x08000000" size="0x00200000" default="1"/>

[thegecko]

Thanks, we can look into this as it should work