ICE-V Wireless
Overview
The ICE-V Wireless is a combined ESP32C3 and iCE40 FPGA board.
See the ICE-V Wireless Github Project [1] for details.
Hardware
This board combines an Espressif ESP32-C3-MINI-1 (which includes 4MB of flash in the module) with a Lattice iCE40UP5k-SG48 FPGA to allow WiFi and Bluetooth control of the FPGA. ESP32 and FPGA I/O is mostly uncommitted except for the pins used for SPI communication between ESP32 and FPGA. Several of the ESP32C3 GPIO pins are available for additonal interfaces such as serial, ADC, I2C, etc.
For details on ESP32-C3 hardware please refer to the following resources:
For details on iCE40 hardware please refer to the following resources:
Supported Features
The icev_wireless board supports the hardware features listed below.
- on-chip / on-board
- Feature integrated in the SoC / present on the board.
- 2 / 2
-
Number of instances that are enabled / disabled.
Click on the label to see the first instance of this feature in the board/SoC DTS files. -
vnd,foo -
Compatible string for the Devicetree binding matching the feature.
Click on the link to view the binding documentation.
icev_wireless/esp32c3 target
Type |
Location |
Description |
Compatible |
|---|---|---|---|
CPU |
on-chip |
Espressif RISC-V CPU1 |
|
ADC |
on-chip |
ESP32 ADC1 |
|
Bluetooth |
on-chip |
Bluetooth HCI for Espressif ESP321 |
|
CAN |
on-chip |
ESP32 Two-Wire Automotive Interface (TWAI)1 |
|
Clock control |
on-chip |
ESP32 RTC (Power & Clock Controller Module) Module1 |
|
Counter |
on-chip |
ESP32 Counter Driver based on RTC Main Timer1 |
|
on-chip |
ESP32 general-purpose timers2 |
||
DMA |
on-chip |
ESP32 GDMA (General Direct Memory Access)1 |
|
Flash controller |
on-chip |
ESP32 flash controller1 |
|
GPIO & Headers |
on-chip |
ESP32 GPIO controller1 |
|
I2C |
on-chip |
ESP32 I2C1 |
|
I2S |
on-chip |
ESP32 I2S1 |
|
Input |
on-board |
Group of GPIO-bound input keys1 |
|
Interrupt controller |
on-chip |
ESP32 Interrupt controller1 |
|
LED |
on-board |
Group of GPIO-controlled LEDs1 |
|
MTD |
on-chip |
Flash node1 |
|
on-chip |
Fixed partitions of a flash (or other non-volatile storage) memory1 |
||
Pin control |
on-chip |
ESP32 pin controller1 |
|
PWM |
on-chip |
ESP32 LED Control (LEDC)1 |
|
RNG |
on-chip |
ESP32 TRNG (True Random Number Generator)1 |
|
Sensors |
on-chip |
ESP32 temperature sensor1 |
|
Serial controller |
on-chip |
ESP32 UART2 |
|
on-chip |
ESP32 UART1 |
||
SPI |
on-chip |
ESP32 SPI1 |
|
Timer |
on-chip |
ESP32 System Timer1 |
|
Watchdog |
on-chip |
ESP32 XT Watchdog Timer1 |
|
on-chip |
|||
Wi-Fi |
on-chip |
ESP32 SoC Wi-Fi1 |
Connections and IOs
The ICE-V Wireless provides 1 row of reference, ESP32-C3, and iCE40 signals brought out to J3, as well as 3 PMOD connectors for interfacing directly to the iCE40 FPGA. Note that several of the iCE40 pins brought out to the PMOD connectors are capable of operating as differential pairs.
ICE-V Wireless (Back)
The J3 pins are 4V, 3.3V, NRST, GPIO2, GPIO3, GPIO8, GPIO9, GPIO10, GPIO20, GPIO21, FPGA_P34, and GND. Note that GPIO2 and GPIO3 may be configured for ADC operation.
For PMOD details, please refer to the PMOD Specification [6] and the image below.
Programming and Debugging
Programming and debugging for the ICE-V Wireless ESP32-C3 target is incredibly easy 🎉 following the steps below.
Building and Flashing
Simple boot
The board could be loaded using the single binary image, without 2nd stage bootloader. It is the default option when building the application without additional configuration.
Note
Simple boot does not provide any security features nor OTA updates.
MCUboot bootloader
User may choose to use MCUboot bootloader instead. In that case the bootloader must be built (and flashed) at least once.
There are two options to be used when building an application:
Sysbuild
Manual build
Note
User can select the MCUboot bootloader by adding the following line to the board default configuration file.
CONFIG_BOOTLOADER_MCUBOOT=y
Sysbuild
The sysbuild makes possible to build and flash all necessary images needed to bootstrap the board with the ESP32 SoC.
To build the sample application using sysbuild use the command:
west build -b icev_wireless --sysbuild samples/hello_world
By default, the ESP32 sysbuild creates bootloader (MCUboot) and application images. But it can be configured to create other kind of images.
Build directory structure created by sysbuild is different from traditional Zephyr build. Output is structured by the domain subdirectories:
build/
├── hello_world
│ └── zephyr
│ ├── zephyr.elf
│ └── zephyr.bin
├── mcuboot
│ └── zephyr
│ ├── zephyr.elf
│ └── zephyr.bin
└── domains.yaml
Note
With --sysbuild option the bootloader will be re-build and re-flash
every time the pristine build is used.
For more information about the system build please read the Sysbuild (System build) documentation.
Manual build
During the development cycle, it is intended to build & flash as quickly possible. For that reason, images can be built one at a time using traditional build.
The instructions following are relevant for both manual build and sysbuild. The only difference is the structure of the build directory.
Note
Remember that bootloader (MCUboot) needs to be flash at least once.
For the Hello, world! application, follow the instructions below.
# From the root of the zephyr repository
west build -b icev_wireless samples/hello_world
west flash
Open the serial monitor using the following command:
$ west espressif monitor
After the board has automatically reset and booted, you should see the following message in the monitor:
***** Booting Zephyr OS vx.x.x-xxx-gxxxxxxxxxxxx *****
Hello World! icev_wireless
Debugging
As with much custom hardware, the ESP32C3 modules require patches to OpenOCD that are not upstreamed. Espressif maintains their own fork of the project. The custom OpenOCD can be obtained by running the following extension:
west espressif install
Note
By default, the OpenOCD will be downloaded and installed under $HOME/.espressif/tools/zephyr directory (%USERPROFILE%/.espressif/tools/zephyr on Windows).
The Zephyr SDK uses a bundled version of OpenOCD by default. You can overwrite that behavior by adding the
-DOPENOCD=<path/to/bin/openocd> -DOPENOCD_DEFAULT_PATH=<path/to/openocd/share/openocd/scripts>
parameter when building.
Here is an example for building the Hello World application.
# From the root of the zephyr repository
west build -b icev_wireless samples/hello_world -- -DOPENOCD=<path/to/bin/openocd> -DOPENOCD_DEFAULT_PATH=<path/to/openocd/share/openocd/scripts>
west flash
You can debug an application in the usual way. Here is an example for the Hello World application.
# From the root of the zephyr repository
west build -b icev_wireless samples/hello_world
west debug