Add USB Bulk backend support for cmsisDAP and cable support for Sipeed SLogic Combo 8

[aisuneko]

The current cmsisdap cable implementation only detects cables (with specific hardcoded vid:pids) which communicates via hidapi's HID (in other words, compliant with the CMSIS-DAPv1 protocol). This PR fixes this with support for the CMSIS-DAPv2 protocol which communicates through libusb's USB Bulk Transfer, along with a new backend system for the cmsisdap driver class and the --cmsisdap-backend CLI argument for the user to choose from the multiple backends available, or by auto selection. OpenOCD's cmsis_dap_usb_bulk.c is used as reference.

This PR also adds support for the Sipeed SLogic Combo 8 cable (sipeed_slogic), which could not be detected by HID and only works with USB bulk.

Tested with the SLogic Combo 8 and the Colorlight 5A-75B v7.0 board (Lattice LFE5U-25).

Example output:

$ ./openFPGALoader -c sipeed_slogic -m bitstream.bin --verbose-level=2 --cmsisdap-backend=usbbulk
write to ram
Found 1 compatible device:
        0xd6e7 0x3507
        VID : d6e7
        PID : 3507
        serial number : 012345ABCDEF
        firmware version : 2.1.0
        target device vendor : SIPEED
        target device name : RV CMSIS-DAP
        hardware capabilities : 33
        SWO trace buffer size : NA
        max packet cnt : 08
        max packet size : 512
Hardware cap 00 01 33
USB bulk init successful
clk frequency conf done
Raw IDCODE:
- 0 -> 0x41111043
- 1 -> 0xffffffff
Fetched TDI, end-of-chain
found 1 devices
index 0:
        idcode 0x41111043
        manufacturer lattice
        family ECP5
        model  LFE5U-25
        irlength 8
File type : bin
Open file: DONE
b3bdffff
Parse file: DONE
bitstream header infos
Part: LFE5U-25F-6CABGA256
idcode: 41111043
IDCode : 41111043
displayReadReg
        Config Target Selection : 0
        Done Flag
        Std PreAmble
        BSE Error Code
                No err
Enable configuration: DONE
SRAM erase: DONE
Loading: [==================================================] 100.00%
Done
userCode: 00000000
Disable configuration: DONE
displayReadReg
        Config Target Selection : 0
        Done Flag
        BSE Error Code
                No err
$

[aisuneko]

According to CI messages, Windows toolchains are missing <hidapi.h>. @trabucayre Is this intended behavior?

[trabucayre]

An #include "cmsisDAP.hpp" has been added in main.cpp but when cmsisdap support is disabled hidapi is not searched and built fails. This include must be replaced by:

#ifdef ENABLE_CMSISDAP
#include "cmsisDAP.hpp"
#endif

But the main issue here is this dependency is not installed by the CI -> cmsisdap support is always disabled.

[trabucayre]

The missing dependency is fixed on branch master. I will rebase your PR on this branch with small modifications.

[aisuneko]

Do not merge yet. There is still an issue with this backend which would cause the flash process to halt at the last step (after program load), which I'm investigating.
Fixed with 89c42ce.

[aisuneko]

@trabucayre Tested again with both mem and flash programming options. Feel free to try it out with CMSIS-DAPv2 probes that you may own and tell me if there are more bugs :)

Also check out #662. a byproduct from the fix above.

[trabucayre]

Hi I have few remarks.

• with BACKEND_AUTOSELECT it seems more logical to try first the best option (v2) and moving to v1 as fallback
• I'm hesitant about the conversion between string and constant at main.cpp level. This add more complexity at this level, maybe moving this to cmsisdap driver is more easy/reduces extra logic.
• the sipeed_slogic is a board, not a cable. I think I will modify board.hpp to have a CMSIS_BOARD macro allowing to specify vid/pid

[aisuneko]

with BACKEND_AUTOSELECT it seems more logical to try first the best option (v2) and moving to v1 as fallback

Will fix in my next commit.

I'm hesitant about the conversion between string and constant at main.cpp level. This add more complexity at this level, maybe moving this to cmsisdap driver is more easy/reduces extra logic.

Are there better solutions to backend selection in your opinion? After all we should leave an argument available for the user to choose a specific backend to use - there could be more backends implemented in the future such as TCP.

the sipeed_slogic is a board, not a cable. I think I will modify board.hpp to have a CMSIS_BOARD macro allowing to specify vid/pid

There are two slogic products by Sipeed:

• the SLogic Combo 8, a BL616/BL618-based multi-purpose probe and debugger with support for CK-Link/DAP/UART (also with low-speed logic analyzer functionality);
• the SLogic16U3/SLogic32U3, a Gowin-based FPGA high-speed logic analyzer.

This PR only concerns the former, but I could rename the device in concern to e.g. sipeed_slogic_combo8 to avoid confusion.

[trabucayre]

Sorry for the confusion. Indeed the sipeed slogic combo 8 is a cable not a board.

[trabucayre]

I have added a new branch with some modifications https://github.com/trabucayre/openFPGALoader/tree/cmsisdap_backend

• switch priority
• allows enable/disable v1 / v2

[aisuneko]

I have added a new branch with some modifications https://github.com/trabucayre/openFPGALoader/tree/cmsisdap_backend

* switch priority

* allows enable/disable v1 / v2

Are you planning to keep the argument in main.cpp, or to delete it and only keep the build flags? Also, what will you close this particular PR since you've opened a new branch, or else...?

[trabucayre]

For the argument it's a good question. In one hand having this option allows to have control about backend type but in other hand the most important thing is to have the better/faster protocol supported by the cable. So I don't know.
My branch is temporary, just to show some idea I have but at the end, this PR will be merged once rebased with my modifications and your if you add more commits.

[aisuneko]

For the argument it's a good question. In one hand having this option allows to have control about backend type but in other hand the most important thing is to have the better/faster protocol supported by the cable. So I don't know. My branch is temporary, just to show some idea I have but at the end, this PR will be merged once rebased with my modifications and your if you add more commits.

I gave it some more thought... indeed it doesn't matter that much whether or not we exposed an interface for the user to choose a specific backend. Seems that these two implementations (HID and USB Bulk) are mutually exclusive for most CMSIS-DAP probes; at least among my two such probes, one is HID only and the other is bulk only. That is, we'll likely to be dealing with only one of the two backends available at a time.

I'll make one more commit to address this before merge.

[trabucayre]

I have adapted your modifications in my temp branch and removed the first switch to always uses bulk -> hid -> fails.
If this code is fine too you / not introduces regression I will update your PR with these commits and merge.

[aisuneko]

I have adapted your modifications in my temp branch and removed the first switch to always uses bulk -> hid -> fails. If this code is fine too you / not introduces regression I will update your PR with these commits and merge.

Sure. I think I need extra time to test the stability of this backend. I'll let you know when I think this is ready to merge.