pyOCD cannot install packs if the Arm Pack Index version is different from the version listed in the vendor's .pdsc file.

[ryanstrace]

Hi! This is a follow-up to #1904, which was closed because the original problem could no longer be reproduced. I am encountering the same problem with the MIMXRT1171DVMAB device.

The problem appears to span both pyocd/pyOCD and pyocd/cmsis-pack-manager: the version mismatch is introduced while building the pack index, and it ultimately prevents pyocd pack install from installing the pack.

Steps to Reproduce

1. Run pyocd pack install MIMXRT1171DVMAB. This command silently fails:

   Downloading packs (press Control-C to cancel):
       NXP.MIMXRT1171_DFP.26.03.00
   

2. Check if it's installed with pyocd pack find MIMXRT1171DVMAB. Shows False.

   Part              Vendor   Pack                 Version    Installed
   ------------------------------------------------------------------------
   MIMXRT1171DVMAB   NXP      NXP.MIMXRT1171_DFP   26.03.00   False
   

3. Attempt to flash with pyocd flash --target=MIMXRT1171DVMAB "path/to/bin". Throws an error.

   Target type mimxrt1171dvmab not recognized. Use 'pyocd list --targets' to see currently available target types. See <https://pyocd.io/docs/target_support.html> for how to install additional target support.
   

Like @Vidpic, I notice that the version number seems to be ahead of the latest release. The command above lists 26.03.00, but the latest on Arm's Pack Index is 25.12.00.

Where does the discrepancy come from?

It looks like there are two sources of the version number, and they can sometimes conflict:

1. Arm's Pack Index
2. Vendor's .pdsc file

Running pyocd pack update calls cache.cache_descriptors(), which downloads Arm's remote Pack Index and any reference vendor indexes. A snippet of this file is below (full file here):

<pdsc
    url="https://mcuxpresso.nxp.com/cmsis_pack/repo/"
    vendor="NXP"
    name="MIMXRT1171_DFP"
    version="25.12.00"
/>

This is where the 25.12.00 number comes from.

This file is parsed into a PdscRef. Later, this PdscRef is used to construct a remote URL:

https://mcuxpresso.nxp.com/cmsis_pack/repo/NXP.MIMXRT1171_DFP.pdsc

This file gets saved in the local cmsis-pack-manager cache using the 25.12.00 version number: NXP.MIMXRT1171_DFP.25.12.00.pdsc.

This file has its own <releases> tag:

<releases>
    <release version="26.03.00" date="2026-03-24">NXP CMSIS Packs based on MCUXpresso SDK 26.03.00</release>
    <release version="25.12.00" date="2025-12-18">NXP CMSIS Packs based on MCUXpresso SDK 25.12.00</release>
    <release version="25.09.00" date="2025-09-19">NXP CMSIS Packs based on MCUXpresso SDK 25.09.00</release>
    ...
  </releases>

The latest_release() function reads the first release, which is 26.03.00.

// rust/cmsis-pack/src/pdsc/mod.rs

pub fn latest_release(&self) -> &Release {
    &self.0[0]
}

This is where the 26.03.00 version comes from.

This function is used when generating the index.json file, meaning it records 26.03.00

Running pyocd pack install MIMXRT1171DVMAB looks up the device in index.json. It finds it and creates a pack reference using the 26.03.00 version. This yields the string NXP.MIMXRT1171_DFP.26.03.00, which is what pyOCD prints:

Downloading packs (press Control-C to cancel):
    NXP.MIMXRT1171_DFP.26.03.00

That means that it's looking for NXP.MIMXRT1171_DFP.26.03.00.pdsc, but NXP.MIMXRT1171_DFP.25.12.00.pdsc is what's actually cached. Since the file doesn't exist, the actual .pack download never starts.

[RobertRostohar]

There is a known issue with several NXP packs (not compliant with the pack schema) which is causing this. NXP is aware of that and is fixing it. Should be resolved with the new 26.06.00 version.

In the meantime, I would suggest downloading the pack manually and specify it on the command line directly.

pyocd <subcommand> --target MIMXRT1171DVMAB --pack=NXP.MIMXRT1171_DFP.25.12.00.pack

[ryanstrace]

Thank you for the suggestion. That's exactly how I'm working around this for now.

Respectfully, I don't think this can be dismissed as "NXP's problem".

NXP (and other vendors) should definitely publish consistent metadata, but pyOCD currently consumes two separate sources of truth. When they inevitably diverge (even for a few days/weeks/months), pyocd pack install fails silently.

We also see that NXP is not the sole offender. @Vidpic reported this issue with a Holtek device (#1904). I'm sure many other users have experienced intermittent issues as a result of this as well.

This issue could be avoided by doing any of the following:

1. Choosing a single authoritative source of truth
2. Adding logic to reconcile any divergence
3. Allowing the user to download a specific pack version with a command-line argument