[solution] Several DFP packs in generated CPRJ

[fred-r]

Hin

I have a cproject.yml like this:

  components:
    - component: STMicroelectronics::Application:Example&HAL_GPIO_Toggle
...
    - component: STMicroelectronics::Device:Startup

I converted it to cprj:

frq09468@LMECWL0888  /c/Cube20/stm32cube_fw_u5/examples/hal/gpio/toggle/projects
$ csolution.exe -s gpio-toggle.csolution.yml convert
C:/Cube20/stm32cube_fw_u5/examples/hal/gpio/toggle/projects/gpio-toggle.csolution.yml - warning csolution: yaml schemas were not found, file cannot be validated
C:/Cube20/stm32cube_fw_u5/examples/hal/gpio/toggle/projects/gpio-toggle.cproject.yml - warning csolution: yaml schemas were not found, file cannot be validated
C:/Cube20/stm32cube_fw_u5/examples/hal/gpio/toggle/projects/gpio-toggle+STM32U585I-IOT02A.cprj - info csolution: file generated successfully

But then I can see 2 DFP packs being referenced for the U5:

  <packages>
    <package name="CMSIS" vendor="ARM" version="5.8.0"/>
    <package name="STM32U5xx_DFP" vendor="Keil" version="1.1.0"/>
    <package name="Example_HAL_GPIO_Toggle" vendor="STMicroelectronics" version="0.0.1"/>
    <package name="STM32U5xx_DFP" vendor="STMicroelectronics" version="0.0.1"/>
    <package name="STM32U5xx_Drivers" vendor="STMicroelectronics" version="0.0.1"/>
    <package name="board_resources_B-U585I-IOT02A" vendor="STMicroelectronics" version="0.0.1"/>
  </packages>

Why is the DFP from Keil referenced here ?

[brondani]

Probably the selected device or a component or an API was found in that pack. Can you please share the project so we can debug it?

[fred-r]

Hi Daniel,

please find the project enclosed. Do you need the pdsc of the packs ? projects.zip

[brondani]

Thanks Fred! The selected device is indeed in the Keil::STM32U5xx_DFP:

$ csolution.exe list packs -f STM32U5
Keil::STM32U5xx_DFP@1.1.1
$ csolution.exe list devices -f STM32U585AIIx
STM32U585AIIx

Are you providing the same device in the STMicroelectronics::STM32U5xx_DFP? How do you intend to differentiate them?

[fred-r]

Interesting case...the device is present in both packs. I have also this:

                <!-- *************************  Device 'STM32U585AI'   ***************************** -->
                <device Dname="STM32U585AIIx">      
                    <memory id="IROM1" start="0x08000000" size="0x00200000"      startup="1" default="1" /> 
                    <memory id="IROM2" start="0x0C000000" size="0x00200000"      startup="1" default="0" /> 
                    <memory id="IRAM1" start="0x20000000" size="0x030000"        init="0" default="1" />
                    <memory id="IRAM2" start="0x30000000" size="0x030000"        init="0" default="0" />
                    <algorithm name="Flash/STM32U5xx_2M_0800.FLM"          start="0x08000000" size="0x00200000" default="1" />
                    <algorithm name="Flash/STM32U5xx_2M_0C00.FLM"          start="0x0C000000" size="0x00200000" default="1" />
                    <feature type="BGA" n="169"/> 
                </device>   

in STMicroelectronics.STM32U5xx_DFP.pdsc

I guess that such a situation may happen where several "vendors" provide a device or component description ?

I guess the proper solution is to use the vendor ? [Dvendor:: [device_name] ] [:Pname]

Or shall we let the end-user decide where he wants the definition to come from?

[brondani]

In this case it seems both devices have the same Dvendor and Dname. It could be resolved by reducing the pack repository scope, for example by installing only the relevant packs or by using the pack selection mechanism (under development). But the device vendor should ensure their device names uniqueness so the problem does not persist.

[fred-r]

But the device vendor should ensure their device names uniqueness so the problem does not persist.

How to be sure that somebody else will not publish a pack with the same device ? I mean we can have the "official" ST pack for describing a device but also "unofficial" packs from other people ?

Probably specifying the pack as you indicate is the best option?

[brondani]

Yes in case of "unofficial" packs I guess the best option is to reduce the scope.

[fred-r]

Looks like it is not supported by csolution 0.9.2 ?

Leading to further errors:

$ cube cmsis:csolution -s gpio-toggle.csolution.yml convert
C:/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/projects/gpio-toggle.csolution.yml - warning csolution: yaml schemas were not found, file cannot be validated
C:/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/projects/gpio-toggle.csolution.yml:29:7 - warning csolution: key 'pack' was not recognized
C:/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/projects/gpio-toggle.cproject.yml - warning csolution: yaml schemas were not found, file cannot be validated
error csolution: compiler: value not set
error csolution: processing context 'gpio-toggle+B-U585I-IOT02A' failed

[VGRSTM]

@fred-r yes @ReinhardKeil proposal about scope Handling of packs (Filter, Repositories, Local packs, etc.) is not related to any PR yet.

Such said not sure if pack usage may help fixing your trouble. I foresee pack usage as a way to force a pack being added ... not fully clear to me if it may as side effect preventing duplicates doing conditions resolution ... @ReinhardKeil @brondani @jkrech could you share your view about ?

[jkrech]

I think we need to address this situation with some rules, coupled with validation steps. Rule a) A device must not be described by anyone but the vendor. Unfortunately we had to start somewhere and therefore you find packs from vendor Keil describing devices e.g. from STMicroelectronics. This means that these Keil packs will be set to "deprecated" once STMicroelectronics is maintaining the devices respective DFPs. We executed this transition successfully with other vendors before. b) Each vendor is responsible to ensure that each of their devices is only described in one DFP.

I do agree with @VGRSTM that pack filtering/selection may impact the set of selectable components. Therefore duplicate device descriptions must be avoided.

So my question to @fred-r really is, why he decided to add device descriptions to his pack in the first place.

Please note that the same is true for board descriptions.

Prior to adding a new DFP to the index, a check shall be performed that any deviceID or boardID is not present in any of the public pdsc files already. Ideally the Dvendor and Bvendor match the tag in the pack.

[ReinhardKeil]

@fred-r Is this a problem that we should still address? Are the hints provided by Joachim enough?