Closed newbrain closed 2 years ago
I will have a look at this, but their versioning is unreliable. In early versions of the protocol ID=0x04 was the only version field and it meant the version of the firmware, not the protocol.
The description says "The value of CMSIS-DAP Protocol Version must be one of the versions from the CMSIS-DAP revision history, such as "2.1.0"", but even very standard debugger like MCU Link returns "1.10", which is not one of the enumerated values.
As a tool I would not rely on the version string for anything. It is easier to send the command and see if you get a response.
According to their own log only latest v2.1.0 added separate product firmware info, which I assume renamed old version into CMSIS version. So, only firmware starting with v2.1.0 will have reliable version returned from 0x04 command.
Wait, they have the same entry for multiple versions. First version to add it was V1.3.0. This is just stupid.
Stable interfaces are overrated 😂.
Just look at the contortions pyocd does to guess the version: https://github.com/pyocd/pyOCD/blob/0a4b44cad9ff06987ba3699133f82706cc245c48/pyocd/probe/pydapaccess/dap_access_cmsis_dap.py#L630-L685
And you are of course right, it should be "1.2.0" to match the pattern.
I only went back to 1.2 as the first to support SWD_Sequence, I though it was worth a shot since AFAICS, free-dap is compliant. I'll make some experiment, as said above. A CMSIS-DAP probe for 49 SEK (Rpi pico cost in SE) is a good bargain.
Another small thing, still about FW version: you have operation 0x07 in DAP_Info defined as DAP_INFO_PRODUCT_FW_VER, but that should be 0x09.
I'll add all those new string options later today. I'll set it to "1.3.0", since it looks like the closest matching one. But I'm not really trying to implement specific version of their spec, so if something else is not working or does not match the reported version - I don't really care.
But again, I don't understand why they even bother parsing those strings. Most of the debuggers on the market don't return anything meaningful in the version string. This is the first implementation I see that tries to do this.
All you have to do to know if the command is supported is send it to the debugger. If it responds with an error, then it is not supported.
Thanks, supportive and well reasoned as always. See you on the eevblog forum!
I've added new string options and changed the reported version to "1.3.0". I dropped the firmware version entirely, since I never updated it anyway.
See if that works for you.
Hi, I see free-dap declares support for CMSIS-DAP 1.0, though it already implements the DAPSWDSequence command introduced, along a number of optional features, in version 1.2.
In pyocd, the CMSIS-DAP version is used to determine SWD_Sequence support, and the latter is needed to debug RP2040 targets - due to their DP structure. Currently an error message to that effect is displayed when using
pycod --target rp2040
.Since the capabilities bits returned by DAP_Info declare no support for other 1.2 optional features, it would seem that free-dap is actually 1.2 complaint already.
So, changing the supported version string to "v1.2" might be enough to enable the use of free-dap for RP2040 targets through pyocd.
I'll be trying this update in the coming days/weekend and in case submit a PR.
Thanks for this useful tool!