adamgreig / ffp

iCE40 FPGA, SPI flash, and CMSIS-DAP SWD programmer

FFP: Flash/FPGA Programmer

FFP is a dead-simple USB to bidirectional SPI bridge for programming iCE40 FPGAs and SPI flashes. The hardware is an STM32F042 and not much else. Firmware and host software is written in Rust.

The firmware additionally supports SWD via the CMSIS-DAP v1 and v2 protocols, so many debuggers such as probe-rs, OpenOCD, and pyOCD are able to use an FFP to debug and program Cortex-M and other microcontrollers.

See software/ for the host-side software, firmware/ for the embedded device firmware, and hardware/ for the hardware design files.

Pinout

The FFP r1 hardware uses a 5x2 pin 0.05"-pitch connector, which is also commonly used for Cortex family microcontrollers for SWD and JTAG. The pinout is deliberately compatible (though note RESET is moved) to allow hardware reuse and for compatibility with tools such as TagConnect cables.

          ______
    3v3 --|1  2|-- FLASH DI / FPGA DO / SWDIO
    GND --|3  4|-- CLK / SWCLK
    GND --|5  6|-- CS / SWO
        x-|7  8|-- FPGA nRST
    GND --|9 10|-- FLASH DO / FPGA DI / nRESET
          ------

This is the same pinout used by amp_flashprog, a custom firmware for Black Magic Probes to bitbang SPI to the same ends.

Licence

Software and firmware is licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Hardware design files are licensed under the Creative Commons Attribution license (CC-BY).

ffp's Issues

DAP: Investigate supporting multiple queued commands

CMSIS-DAP's DAP_Info command returns a 'maximum packet count', which reflects how many packets the probe can have on-the-go at once. As far as I can tell, this refers to an internal queue of incoming requests which are processed in-order and then results returned in-order in an outgoing queue. Currently the firmware returns '1' for this field, and we always send the result of a request before receiving the next one.

However, this limits USB throughput, especially in HID mode where each frame will either be a new command or a response, but not both. If we could implement a short queue it might help improve throughput. The DAP_TransferAbort command might make more sense too.

DAP: Don't read RDBUFF if next transfer is another AP read

Currently we read RDBUFF after every AP read to retrieve the result of the posted read, but if the next operation is another AP read we'll get the result there instead, which would save time.

SW: Swap from libusb to rusb

Currently FFP software uses libusb, which hasn't been updated in years. We should look to swap to rusb which is more recently updated, and might make building simpler as it fetches libusb source code automatically.

DAP: Support reading SWO

Currently there's no SWO support. It requires bringing up the UART on the SWO pin, setting that up to read into a buffer, and responding to the SWO commands. Probably a bit of work but could be quite useful. For now I anticipate only implementing SWO over the HID endpoint, though in future we could use the CMSIS-DAP v2 SWO streaming endpoint for higher throughput. Since CMSIS-DAP v2 is working well, it seems obvious to get SWO working over that too.

No enumeration on Windows

Our configuration descriptor is exactly 64 bytes, which is also the maximum packet size. If a setup transfer is requested from the host with length exactly 64 bytes, there's no problem since no final zero length packet (ZLP) is expected. This is the case on Linux, which reads 9 bytes to determine the full configuration length, then reads exactly 64 bytes.

However on Windows, after reading the full configuration successfully once, a second read is made for 255 bytes. We respond with 64 bytes, don't send anything else, Windows waits 5s for the ZLP then gives up and fails to enumerate.

Can not build firmware successful. and how to build ffp host software for windows?

Compiling output below:

error[E0463]: can't find crate for core
|
= note: the thumbv6m-none-eabi target may not be installed

error: aborting due to previous error

For more information about this error, try rustc --explain E0463.
error: could not compile stable_deref_trait.

OS Type:
Linux 4.9.0 Debian 9

Rustc/Cargo Version:
rustc 1.44.0-nightly (94d346360 2020-04-09)
cargo 1.44.0-nightly (390e8f245 2020-04-07)

FW: Support bootloading without manually setting fuse

Currently jumping to bootloader only works if the BOOT_SEL fuse bit is set, otherwise the system bootloader immediately jumps to user code. There seem to be a few ways to work around this:

• Write the fuse from our own firmware if not set
• Drive the BOOT0 pin as GPIO immediately before rebooting?
• ...?

DAP: Support non-multiple-of-8 SWD sequences

Question regarding port to STM32F070

Hi adamgreig,
first, thanks for your great effort in building rust code for embedded.

We are trying to port the firmware part of this project to another board, which uses a slightly different microcontroller (STM32F070F6P6) without the USB clock recovery feature. Because of this we are using an external crystal oscillator and the internal pll to generate the 48Mhz for the USB peripheral (see this diff).

The dfu bootloader from ST is working fine on the board, so the hardware seems to be working.

However, the device is not enumerating properly and it seems like the USB stack is not responding. The error we get is:

[11859.787068] usb 2-3: new full-speed USB device number 17 using xhci_hcd
[11859.937106] usb 2-3: device descriptor read/64, error -71
[11860.207122] usb 2-3: device descriptor read/64, error -71
[11860.477049] usb 2-3: new full-speed USB device number 18 using xhci_hcd
[11860.627086] usb 2-3: device descriptor read/64, error -71
[11860.897080] usb 2-3: device descriptor read/64, error -71
[11861.017107] usb usb2-port3: attempt power cycle
[11861.727065] usb 2-3: new full-speed USB device number 19 using xhci_hcd
[11861.727242] usb 2-3: Device not responding to setup address.
[11861.947235] usb 2-3: Device not responding to setup address.
[11862.177017] usb 2-3: device not accepting address 19, error -71
[11862.327057] usb 2-3: new full-speed USB device number 20 using xhci_hcd
[11862.327091] usb 2-3: Device not responding to setup address.
[11862.547132] usb 2-3: Device not responding to setup address.
[11862.767028] usb 2-3: device not accepting address 20, error -71
[11862.767067] usb usb2-port3: unable to enumerate USB device

We suspect that we miss something in the powerup / clock setup sequence, since we get similiar errors if we set a wrong pll multiplier in a firmware generated by STM32Cube. Do you have any ideas / hints?

DAP: Detect SWO buffer overflow

Currently SWO buffer overflows are not detectable, as the read method has no way to distinguish how many times the DMA index might have wrapped around compared to the last read position. It might be possible to use the DMA half/full transfer complete flags in some fashion to detect overflow. Alternatively it might be possible to use the UART RXNE interrupt pending bit to poll for that in the application loop, but it seems higher overhead and messier.

DAP: Support atomic commands

Currently the atomic commands are both unsupported. Both look reasonably easy to support.

Swap to spi-flash library

spi-flash has more extensive support for reading parameters and working out the best way to erase/write flash, and should be basically a drop-in replacement for flash.rs.

DAP: Support WinUSB

CMSIS-DAP v2 adds WinUSB support, which would be a lot faster than the current HID-based protocol. The STM32F042 should have enough endpoints to implement this alongside HID and the SPI protocol, even including SWO streaming. Not sure how messy WinUSB actually is to implement - if it's just another descriptor and a bulk endpoint that streams the same commands as the HID endpoints, it might be pretty quick to do.

DAP: Support DAP_SWD_Sequence for multi-drop target selection

https://arm-software.github.io/CMSIS_5/DAP/html/group__DAP__SWD__Sequence.html

Provide pre-built firmware and host software images

It would be useful to provide pre-built images so users don't require Rust installed.

Firmware images:

• Provide the normal ELF executable, but with the file renamed to .elf
• Provide the raw binary file
• Provide a raw binary file with the dfu-util suffix added
• Look in to providing some sort of automatic firmware installer software

Host software:

• Provide pre-built Windows, MacOS, and Linux host software
• Not sure how to generate suitable Windows and MacOS builds
• Might also need to distribute/link to a libusb DLL

These files could probably be provided via GitHub release assets.

DAP: JTAG Support

Currently the firmware only supports the SWD protocol. Having JTAG support as well could be convenient, especially for use as an FPGA programmer with non-iCE40 devices such as ECP5 which have JTAG ports.

I'm not sure how the hardware support will work out for JTAG; parts or all of it may require bitbanging as only one SPI device is available.

Adaptation request

Can the ffp host computer program be ported and adapted to the Android app?
Maybe you can refer to the two App StmDfuUsb and ZFlasher STM.