`aen-cc3501e-companion-tour`

The capstone full-surface example for the on-module TI CC3501E Wi-Fi 6 + BLE 5.4 coprocessor, driven from the Alif M55-HE core on the E1M-AEN801 (Alif Ensemble E8) SoM.

Where aen-cc3501e-bringup is the minimal power + PING soak, this app walks the portable wireless checkpoint plus the diagnostic companion API in one linear sequence — living documentation of the hand-written-firmware path.

Source: examples/aen/aen-cc3501e-companion-tour/.

Which surface does what

The app never touches the raw wire protocol. It splits cleanly across three headers:

Layer	Header	Used for
Portable Wi-Fi	`<alp/iot.h>`	Application-level Wi-Fi calls
Portable BLE	`<alp/ble.h>`	Application-level BLE open + scan
Chip diagnostics	`<alp/chips/cc3501e.h>`	Bridge diagnostics, `GET_DIAG_INFO`, raw scan/connect/socket verbs

The tour

init  ->  ping  ->  diag info
      ->  portable Wi-Fi open  ->  portable BLE open + scan
      ->  Wi-Fi scan  ->  Wi-Fi connect  ->  get IP
      ->  TCP socket: open -> connect -> send -> recv -> close
      ->  Wi-Fi disconnect
      ->  BLE enable  ->  BLE scan  ->  BLE disable
      ->  proxied-GPIO read (IO15 over the bridge)

Every step is non-fatal. A step that fails prints its status and the tour continues. On a bench with no AP in range the connect times out; on a firmware image built without BLE the enable returns NOT_READY; the example still runs end to end and shows the shape of each call. A real application would branch on these statuses instead of just logging them.

Two output contracts

The tour prints two interleaved streams.

[tour] lines are the human-readable narration — one per step, carrying the returned status:

[tour] E1M-AEN CC3501E companion full-surface tour
[tour] bridge bring-up -> 0
[tour] PING ok after 1 attempt
[tour] GET_VERSION -> protocol v2 (host expects v2)
[tour] diag: fw=0x0102 reset_cause=1 role=0 uptime=8421 ms ...
[tour] WIFI_SCAN -> 5 AP(s)
[tour] WIFI_CONNECT skipped (TOUR_WIFI_SSID empty -- set it at build time)
[tour] BLE_ENABLE -> controller + NimBLE host up
[tour] BLE_SCAN -> 10 advertiser(s)
[tour] GPIO proxy: IO15 (over the bridge) reads 1
[tour] full-surface tour complete

PORTABLE_WIRELESS: lines are the stable machine-greppable checkpoint the bench reads:

PORTABLE_WIRELESS: wifi_open PASS
PORTABLE_WIRELESS: ble_open PASS
PORTABLE_WIRELESS: ble_scan PASS count=10
PORTABLE_WIRELESS: SUMMARY pass=3 fail=0

On real AEN silicon, wifi_open PASS proves alp_wifi_open() selected the attached CC3501E provider, and ble_scan PASS count=N proves <alp/ble.h> reached the same radio path.

GET_DIAG_INFO is a v2-only opcode — against v0.1 firmware it is rejected, and the tour prints -> rejected (v0.1 firmware; v2-only) -- expected rather than counting it a failure.

Wi-Fi credentials + socket target

Credentials are deliberately empty by default — never hardcode them in a public example. Set them at build time without editing the source:

west build -b alp_e1m_aen801_m55_he/ae822fa0e5597ls0/rtss_he \
  examples/aen/aen-cc3501e-companion-tour -- \
  -DEXTRA_CFLAGS="-DTOUR_WIFI_SSID=\\\"myssid\\\" -DTOUR_WIFI_PASS=\\\"mypass\\\""

When TOUR_WIFI_SSID is empty the connect / IP / socket steps are skipped (they need an association) and the tour jumps straight to the BLE section. The TCP destination is set by TOUR_TCP_IP / TOUR_TCP_PORT in src/main.c — change it to a host reachable from your bench network.

SoM bring-up is one call

The hardware setup — control pins, inter-chip SPI, power/reset sequence — is cc3501e_bridge_bringup(), the reusable SoM template shared with the bringup example.

The proxied-GPIO step is built with CONFIG_ALP_SDK_GPIO_CC3501E_PROXY=y: alp_gpio_open(ALP_E1M_GPIO_IO15) routes over the bridge while every other pin delegates to the platform GPIO driver. See aen-cc3501e-gpio for what the proxy is and its polling caveat.

`board.yaml`

Identical in shape to aen-cc3501e-gpio:

som:
  sku: E1M-AEN801

preset: e1m-evk

cores:
  a32_cluster:
    os: "off"
  m55_he:
    app: ./src
    peripherals:
      - spi
      - gpio

chips:
  - cc3501e

diagnostics:
  log_level: info

Status

build_only: true on native_sim/native/64, verified against the emulated SPI controller plus the alp,pin-array in the shipped overlay. CI proves compile + link only — every step's status is a bench signal on real AEN silicon with the CC3501E firmware up.

The bench build/flash recipe (two J-Links) and the wiring table live in aen-cc3501e-bringup and apply verbatim here.

Which surface does what​

The tour​

Two output contracts​

Wi-Fi credentials + socket target​

SoM bring-up is one call​

board.yaml​

Status​

See also​