The FPGA normally boots from a dedicated serial NOR flash. This flash can be programmed by the Pico processor which exposes the flash to the host OS as either a removable drive or a DFU endpoint.
On Windows, while the RaspberryPi guide mentions using Visual Studio Code with a plugin a an IDE, better results were obtained by using the WSL2 environment.
Out of the box, the default firmware should already be present on your board. You can skip step 1 if this is the case.
Convert the binary bitstream
rgb_blink.bininto an UF2
rgb_blink.uf2with the UF2 Utils:
$ bin2uf2 -o rgb_blink.uf2 rgb_blink.bin
Connect the pico-ice via USB and lookup the USB drive named
pico-ice. Open it.
You can copy the
rgb_blink.uf2file to that drive you just attached. As soon as you copy the file over,t he pico-ice will reboot and allow the FPGA to come up depending on the code running in the Pico processor.
Install the DFU utilities.
a. For Windows, yosys-hq tabby-cad: double-clicking on
start.baton the OSS CAD Suite installation opens a prompt with the dfu-util command available.
b. For other systems you can install the dfu-util package.
Check whether the Pico is recognized as a DFU device:
dfu-util -l. This should list the pico-ice as a DFU device:
Found DFU: [1209:b1c0] ver=0100, devnum=105, cfg=1, intf=0, path="1-4.4", alt=1, name="iCE40 DFU (flash)", serial="DE62A435436F5939" Found DFU: [1209:b1c0] ver=0100, devnum=105, cfg=1, intf=0, path="1-4.4", alt=0, name="iCE40 DFU (CRAM)", serial="DE62A435436F5939"
Download the FPGA bin file to the pico-ice. The Pico can be rebooted as soon as the download succeeds with the
$ dfu-util -a 1 -D rgb_blink.bin
Once the FPGA bitfile transfers over using the DFU protocol, the Pico will check for whether the DONE pin goes high indicating a successful boot. This would make the CDONE green LED bright.
If this doesnt happen for whatever reason, the DFU utility will throw an error indicating that this did not succeed.
The user writing a custom firmware with the pico-ice-sdk should take care of starting the FPGA from the MCU. Review the pico_fpga example for how this can be done, as well as the
ice_fpga.h library documentation.
The USB DFU provided as part of the pico-ice-sdk must also be enabled for the DFU interface to show-up. The pico_usb_uart example project have it enabled by default.
This error might occur when a communication error occurs.
On Windows operating system, the device needs to be declared with Zadig as described here. Make sure to select the pico-ice device on the list rather than any other to avoid erasing your system’s USB drivers.
On Linux operating system, it might need to be allowed with an udev rule, or
dfu-utilmight need to be run as super user.
This could be due that there was no response from the flash chip, and the RP2040 is endlessy waiting the write confirmation.
If you had an earlier board, it could be due to the fact the TX and RX pins were swapped, and do not work for the old board anymore.
The UF2 file format contains the destination addresses of each block. In case you used other tools than those provided, it is possible that that the addresses were outside the valid range of the flash chip. Try to copy the CURRENT.UF2 to NEW.UF2 upon that same directory, and unmount the device. This should trigger a restart of the device. This restart device should appear from the debug UART:
This message sometimes comes from
dfu-util when the
-R flag is not used. With the
-R flag, the pico-ice will reboot at the end of the transfer, and DFU-util should not complain anymore.