pyocd
[PackTarget] Automaticlly select target type instead of using generic cortex_m
pyocd always use generic cortex_m when board id is not defined in board_ids.py. This make pyocd cannot works for new board with a DFP pack. This PR could make pyocd default select the first target in CMSIS-Pack, or user can pass an exists target in DFP pack with option "-t".
Signed-off-by: Haley Guo [email protected]
Apologies for taking a month to review this. I've also been thinking about adding a similar feature for a while.
Unfortunately, I think the concept needs some more work. That's primarily because it's really only the DFPs from NXP that contain a single MCU definition—pretty much every other silicon vendor includes more than one MCU device definition per DFP. With more than one MCU in a DFP, automatically selecting the first device in the selected DFP isn't particularly helpful and may even be more confusing.
To start with, we could consider controlling this feature with a user option such as enable_auto_dfp_target, which would default to disabled. Such a user option is definitely required regardless what the default is set to; any automatic behaviour like this needs to be controllable.
A really interesting solution would be to attempt to determine the target type automatically by scanning registers. The result could then be used with either manually-provided DFPs or managed ones. The difficult part that has so far prevented any real development of this idea is that there is no reliable way (that we know of) to determine the MCU vendor. Once the vendor is known, it's much easier (fewer registers to read).
I do want to continue down this path, but let's continue working on making it reliable and predictable for all MCUs.
Darn. I thought the vendor ID was somewhere in the core registers amd was hoping this would eventually be used to auto identify an MCU.
Was thinking DAPLink itself could present the target MCU and also allow for a particular board tp identify itself somehow.
@Flit CPUID does not encode implementation specific details of the MCU as a whole?
(@40Grit Sorry I missed your comments!)
The CPUID register only indicates the core type (M0+, M4, etc) and revision. (It does have the JEDEC ID of the core vendor, but that's always Arm.)
The top level ROM table does, in some cases, indicate the vendor's JEDEC ID. But not all silicon vendors customize this field, for instance neither LPC nor Kinetis devices have the ROM table vendor field changed from the default of Arm, except in cases where they are using a non-default ROM table (usually an extra one in addition to the ROM table built into the Cortex-M core complex).
Right now DAPLink presents a single "board ID" that is unique for every board. From that, we derive the target type via the lookup table in pyocd.board.board_ids. We could conceivably make DAPLink report the full part number for the target, as well as the full board name (either through a vendor-specific CMSIS-DAP command or non-standard DAP_Info command info ID). One probably minor issue is that you can't report this info in the USB serial number, so you'd have to connect and send CMSIS-DAP commands. That would mean that devices already opened would show as generic DAPLink devices. (I guess we could add extra USB strings, though.)
@flit Thanks for the info.
My current particular interest in this is obviously for Embedded Planet's "Flidor" development adapter.
It would be an obviously nice feature if the target mcu/board were able to provide identity to daplink and or pyocd.
We have many more boards on the way that will be using Flidor and it's successors.
(@40Grit Sorry I missed your comments!)
The CPUID register only indicates the core type (M0+, M4, etc) and revision. (It does have the JEDEC ID of the core vendor, but that's always Arm.)
The top level ROM table does, in some cases, indicate the vendor's JEDEC ID. But not all silicon vendors customize this field, for instance neither LPC nor Kinetis devices have the ROM table vendor field changed from the default of Arm, except in cases where they are using a non-default ROM table (usually an extra one in addition to the ROM table built into the Cortex-M core complex).
Right now DAPLink presents a single "board ID" that is unique for every board. From that, we derive the target type via the lookup table in pyocd.board.board_ids. We could conceivably make DAPLink report the full part number for the target, as well as the full board name (either through a vendor-specific CMSIS-DAP command or non-standard DAP_Info command info ID). One probably minor issue is that you can't report this info in the USB serial number, so you'd have to connect and send CMSIS-DAP commands. That would mean that devices already opened would show as generic DAPLink devices. (I guess we could add extra USB strings, though?)