This lab walks you through building three Zephyr applications for Sparrow:

• Example 1: UART Shell app with standard commands + a custom I2C scan command
• Example 2: UART Shell app + LittleFS mounted from internal flash (ESP32‑C6)
• Example 3: Wi‑Fi webserver that reads BME680 sensor data and serves it to a browser

Open a terminal in your Zephyr workspace and run:

west --version
west boards | grep esp32c6

If the board (ESP32C6 Xiao) is listed and west works, continue.

Tip: If you switch branches or update modules often, use:

> west update

Each lab uses the same basic structure:

<APP_ROOT>/
  CMakeLists.txt
  prj.conf
  src/
    main.c
  boards/
    esp32c6_devkitc_esp32c6_hpcore.overlay
  (optional) Kconfig

Build command used in all labs:

west build -b esp32c6_devkitc/esp32c6/hpcore -p auto .

Flash:

west flash -d build --runner esp32

Monitor serial output:

screen <your_port_name> 115200

Build a UART shell application that includes standard Zephyr shell commands and adds a custom command:

• i2c_scan — scans the I2C bus for responding device addresses

• A booting application with a serial shell prompt like:
  • sparrow$
• Shell commands available (examples):
  • help, kernel, device, log, etc.
• Custom command:
  • i2c_scan

Create a new folder, e.g. sparrow_console and unzip the project here.

sparrow_shell_i2c_scan/
  CMakeLists.txt
  prj.conf
  src/main.c
  boards/esp32c6_devkitc_esp32c6_hpcore.overlay

Build:

west build -b esp32c6_devkitc/esp32c6/hpcore -p auto .

Flash:

west flash -d build --runner esp32

Open the serial console and test:

• help
• i2c_scan

Expected: you see a list of detected I2C addresses or “no devices found”.

• If no devices are found:
  • verify SDA/SCL pins match your wiring
  • confirm pull-ups are present (internal/external)
  • verify bus speed matches device capabilities
• If shell doesn’t appear:
  • verify console device selection in overlay (chosen nodes)
  • ensure shell backend is serial and autostarted

Build a shell app that provides a “Linux-like” file navigation experience (as much as Zephyr supports), using:

• LittleFS
• mounted on an internal flash partition
• with fs shell commands enabled

Typical workflow in shell:

• fs mount (or auto-mount at boot)
• ls /lfs
• cd /lfs
• pwd
• create/read files (depending on enabled commands)

Create a new folder, e.g. sparrow_littlefs and unzip the project here.

Build:

west build -b esp32c6_devkitc/esp32c6/hpcore -p auto .

Flash:

west flash -d build --runner esp32

Test in shell:

• fs (to see available fs commands)
• ls /
• ls /lfs (it is mounted at boot)
• cd /lfs
• pwd
• fs mkdir /lfs/folder1
• fs write /lfs/folder1/hello.txt -o 0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21
• fs cat /lfs/folder1/hello.txt

Expected: you can navigate the mount point and list directory contents, create and view files, etc..

• Devicetree error about duplicate partition labels:
  • ensure you only define one storage_partition label
  • don’t copy/paste partition blocks twice
• Mount fails:
  • verify the storage partition exists in build/zephyr/zephyr.dts
  • ensure partition does not overlap other partitions
  • confirm the flash driver and flash map are enabled
• Shell missing fs commands:
  • verify CONFIG_FS_SHELL (and any related symbols) are enabled

Build a webserver that:

• connects to Wi‑Fi (WPA2‑PSK)
• obtains an IPv4 address via DHCP
• reads BME680 sensor data periodically
• serves the latest sensor values to a browser

Wi‑Fi + TLS stacks can be memory hungry. For a simple HTTP server:

• keep responses small
• avoid allocating large buffers repeatedly
• limit concurrent connections (1 client at a time is fine for a lab)

Create a new folder, e.g. sparrow_web_bme and unzip the project here.

Build:

west build -b esp32c6_devkitc/esp32c6/hpcore -p auto .

Flash:

west flash -d build --runner esp32

Open serial output and note the printed IP address. From a machine on the same LAN, open http:<device-ip>:<port>'' Expected: * browser receives a response containing the latest sensor values ==== Troubleshooting ==== * No Wi‑Fi logs: * raise log level (e.g. default level or module-specific) * ensure Wi‑Fi mgmt is enabled * No IP address: * verify DHCP is enabled * ensure DHCP is started after link is up * “memory allocation failed” from Wi‑Fi adapter: * reduce concurrent HTTP clients * reduce buffer sizes (HTTP response buffer) * avoid repeated dynamic allocations in the HTTP thread * consider increasing heap pool size only if you have flash/RAM headroom * Browser connects but gets no response: * verify socket calls are using Zephyr’s socket headers * verify server binds to INADDR_ANY on the chosen port * ensure response includes valid HTTP headers and CRLF