Add support for Cypress FX3 (Explorer) device with F/LOSS firmware (WIP)

[zougloub]

A while ago @zeldin made fx3lafw, an adaption of fx2lafw for the Cypress FX3 chip, supporting in particular CYUSB3KIT-003 "SuperSpeed Explorer Kit", and a libsigrok fork supporting it. I have used it and took a few minutes to rebase it, but didn't follow up.

Recently #148 has support for the same hardware, but it takes a different firmware, which I find has two downsides:

• licensing: it can't be redistributed
• tooling: requires Cypress tooling vs. a simple arm-none-eabi GCC

So I'm taking some time to test #148 but also rebase the fx3lafw changes on the latest libsigrok.

What this provides, is a 32-channel LA:

And the acquisition performance is strange, but good enough for tests:

• 32ch x 3072 samples @ 96MHz
• 32ch x 3855360 samples @ 48/32 MHz
• 32ch x 4494336 samples @ 16 MHz
• 32ch x 3299328 samples @ 8 MHz

There is one extra feature but it is not perfect (cf. zeldin/libsigrok#1): to use of the device when it hasn't been flashed yet (case of an FX3 booting from USB eg. CYUSB3KIT-003 PMODE aka J4 jumper shorted), sigrok can use it (how to flash then use the firmware in one shot), but not always because the blank FX3 is presented as USB2 but then switches to USB3, which may be on a different bus:

• Before:

    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 1: Dev 40, If 0, Class=Vendor Specific Class, Driver=, 480M
        ID 04b4:00f3 Cypress Semiconductor Corp. FX3 micro-controller (DFU mode)

• After:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 1: Dev 11, If 0, Class=Vendor Specific Class, Driver=, 5000M
        ID 04b4:00f3 Cypress Semiconductor Corp. FX3 micro-controller (DFU mode)

And this only works if the bus topology is mirrored between USB2 and USB3.

Alternatively, the user can flash the firmware (with this or eg. https://git.code.sf.net/p/fx3load/code) and use it after.

fxload -t fx3 -I ../fx3lafw/fx3lafw-cypress-fx3.fw -D /dev/bus/usb/001/047

[cnlohr]

I don't particularly see the issue with #148 - Where are you seeing the limitation? A while ago, Cypress released the full source of their SDK (fx3_sdk_1_3_3_src.zip)

[zeldin]

@cnlohr Neither the Cypress SDK nor the firmware mentioned in #148 have a libre license. In particular, it forbids release of source code to a third party (i.e. not Cypress or the receiver of the (non-transferable) license from them).

[abraxa]

@cnlohr What @zeldin said but there's an important detail: the FX3 firmware from Infineon (naturally) depends on their SDK, which contains an OS that Infineon obtained a license for. The SDK doesn't work without the OS and the OS cannot be redistributed, which forces anyone who wants to work on the FX3 firmware to first agree to the license terms of the SDK and download the SDK.

The solution created by @zeldin and improved on by @zougloub works without the OS and doesn't need the SDK at all. Hence, all of the FX3 firmware code is redistributable and anyone can build it as-is. To me, this difference is significant and perfectly aligns with the goals of sigrok.

[abraxa]

@zougloub , @zeldin How would you rank the maturity of the driver and the firmware? Is it usable and robust enough to merge it? What are the current limitations and which parts need major work?

From what I understand, streaming doesn't yet work, which from my point of view is the killer feature of the FX2, so supporting it on the FX3 is equally essential. Is this something one of you can work towards?

[zeldin]

@abraxa I'm unsure if you are asking about this driver (which is actually the fx2lafw driver, just with some added extensions to support more bits and a higher base clock), or about the one in #148. The fx2lafw driver only works with streaming.

[abraxa]

@zeldin Oh, my bad, I didn't realize. Even better then!

[danielkucera]

Can we please have this merged? Is there any blocker?

[abraxa]

Hello Daniel, we currently don't have an expert available to review this PR and we don't have the manpower to merge PRs that will cause users to ask us for support. We do very much want to support the FX3 but it's not trivial and if users need to apply a patch to get support for it, it's at least understood that it's not officially supported.
If we merge FX3 support, users may (understandably) get the impression that it's officially supported and expect it to work out of the box.
I'm aware that both approaches have their downsides but since we're stretched thin on manpower at the moment, we're trying to do what we can.

[zougloub]

Well, if there was the possibility to merge this as a second-class driver, with delegated support [1] that would work for me. I don't think the extra code in here represents a big potential source of maintenance nightmare for the core contributors (there's one merge conflict in 2 and a half years).

[1] the wiki / code could indicate a maintainer (eg. myself) with any issue or bug assigned to them

[danielkucera]

Hi @abraxa , thanks for the explanation, that is a fair point.
Are you concerned about the changes to ezusb_install_firmware which is shared by more drivers or with the changes to fx2lafw itself?
If the former is the case, I have a branch rebased on latest master where these are omitted: https://github.com/danielkucera/libsigrok/tree/fx3
It works but still needs some polishing. Would you be okay with this approach or rather not touch anything?

[biot]

I'd like to help review this driver and get it merged. I don't have an FX3 board, but I can comment on C code like a champ. I also wrote the original fx2lafw driver.

I don't understand where this F/LOSS firmware is though. Is the idea to develop this driver and only then develop fully free firmware for it to talk to, or am I missing something?

[danielkucera]

A while ago @zeldin made fx3lafw, an adaption of fx2lafw for the Cypress FX3 chip,

It is right here ^^^

[tofurky]

I'm doing some testing of this after a rebase onto master and noticed a few things with the "EZ-USBFX3" I picked up on AliExpress. It's described as "New FX3 USB3.0 Mini Type-C USB 100MHz 16 Channel Logic Analyzer Work With Sigrok PulseView" and is similar in form factor to the cheap FX2 ones.

• It shows up as 04b4:1234, not 04b4:00f3, so the device in supported_fx2 doesn't match:

  libsigrok/src/hardware/fx2lafw/api.c

  Lines 118 to 120 in 5dc0bb4

  	{ 0x04b4, 0x00f3, "Cypress", "SuperSpeed Explorer Kit", NULL,
  	"fx3lafw-cypress-fx3.fw",
  	DEV_CAPS_FX3 | DEV_CAPS_32BIT, NULL, NULL },

• fx3lafw hard-codes the USB pid as 0x00f3 as well, so even if I add it to supported_fx2, it doesn't find it after reenumerating with fx2lafw: Device failed to renumerate.. I worked around it by recompiling fx3lafw with 0x1234 instead of 0x00f3.
• The device first enumerates as usb2 then comes back as usb3 after loading firmware. This causes another check to fail with e.g. fx2lafw: Connection mismatch: usb/3-8.1.3 vs. usb/2-1.1.3:

  libsigrok/src/hardware/fx2lafw/protocol.c

  Lines 201 to 205 in 5dc0bb4

  	if (strcmp(_sdi_connection_id, _connection_id)) {
  	/* This is not the one. */
  	sr_info("Connection mismatch: %s vs. %s", sdi->connection_id, connection_id);
  	continue;
  	}

• The rebase of the original branch is a bit screwy here: 4f43f4d vs zeldin/libsigrok@55f86bf
• The sample rates shown as supported aren't all actually supported. The default of 20KHz causes the following, with pulseview freezing if another capture is attempted afterwards, even with a supported sample rate (note: I'm using old pulseview 0.4.2-3ubuntu1 rebuilt locally against newer libsigrok, maybe it's fixed upstream):

sr: [18:14.656662] session: bus: Received SR_DF_HEADER packet.
sr: [18:14.656665] fx2lafw: GPIF delay = 9599, clocksource = 192MHz.
sr: [18:14.656667] fx2lafw: Unable to sample at 20000Hz.
sr: [18:14.657237] session: Could not start fx2lafw device usb/2-1.1.3 acquisition.
sr: [18:14.657244] hwdriver: fx2lafw: Stopping acquisition.
sr: [18:14.657253] usb: usb_source_finalize
...retry at 96MHz, freezes...
sr: [18:51.121023] hwdriver: sr_config_set(): key 30000 (samplerate) sdi 0x5a908f1ccfa0 cg NULL -> uint64 96000000
sr: [18:51.121048] hwdriver: sr_config_list(): key 30000 (samplerate) sdi 0x5a908f1ccfa0 cg NULL -> {'samplerates': <[uint64 20000, 25000, 50000, 100000, 200000, 250000, 500000, 1000000, 2000000, 3000000, 4000000, 6000000, 8000000, 12000000, 16000000, 24000000, 32000000, 48000000, 64000000, 96000000, 192000000]>}
sr: [18:51.121160] hwdriver: sr_config_get(): key 30000 (samplerate) sdi 0x5a908f1ccfa0 cg NULL -> uint64 96000000
sr: [18:51.121209] hwdriver: sr_config_get(): key 50001 (limit_samples) sdi 0x5a908f1ccfa0 cg NULL -> uint64 1000000000

Haven't done anything beyond capturing zeroes yet; will report back if I encounter anything else.