Synchronous Serial Interface (SSI) Debugging and Error Handling#

Debugging SSI communication typically involves both hardware and software analysis.
Start by inspecting physical connections, then use debugging tools such as logic analyzers and debug logs to isolate issues.

Finally, analyze driver-level error codes to determine root causes and implement corrective actions.

Common Debugging Tips#

Refer to the official Silicon Labs troubleshooting guide for application debugging:
WiSeConnect Debugging Guide

These practices provide a foundation for identifying and resolving communication issues before focusing on hardware or firmware specifics.

Visual Inspection and Connection Validation#

Before running software tests, verify physical connections and signal quality.
Reliable wiring and solid PCB design are critical for stable SSI communication.

Pin Mapping#

  • Verify signal mappings for SCLK (CLK), CS (nCS), and data lines:

    • Single-bit mode: MOSI (IO0) and MISO (IO1)

    • Dual mode: IO0–IO1

    • Quad mode: IO0–IO3

  • Confirm that pins are properly configured in the pinmux for SSI, not GPIO.

Common Reference and Voltage Levels#

  • Ensure a shared ground between connected boards.

  • Check I/O voltage compatibility (for example, 1.8 V or 3.3 V). Use a level shifter if voltage domains differ.

Cables, Connectors, and Layout#

  • Inspect connectors and cables for damage or loose connections.

  • Keep signal traces and wires short and direct.

  • Avoid stubs or daisy-chained connections on SCLK.

  • For high-speed links, add series resistors (22–49 Ω) near the driver to minimize ringing.

  • Follow good PCB design practices: solid ground planes, impedance control, and minimal crosstalk near signal lines.

Power and Reset#

  • Confirm power rails are stable.

  • Ensure any hardware reset pins are released before communication tests.

Interfacing with SiWx917 Development Kits (Primary/Secondary Setup)#

You can test SSI communication between two SiWx917 development kits by configuring one as the primary and the other as the secondary.

Connection Steps#

  1. Connect CLK, CS, MOSI, and MISO between the two boards.

  2. Ensure both share a common ground.

  3. Power on both boards and verify correct voltage levels.

Use Simplicity Studio to flash and debug firmware on the primary device.
Run SSI transfers and monitor activity using a logic analyzer and Simplicity Studio debug tools.

Note: When using custom secondary devices, ensure clock polarity (CPOL), phase (CPHA), data width, and timing configurations match the primary’s settings.

Example Setup Diagram#

SSI Primary–Secondary Connection ExampleSSI Primary–Secondary Connection Example

Using a Logic Analyzer for Debugging#

A logic analyzer provides protocol-level visibility for SSI signal timing and data flow.

Setup Steps#

The following steps will help you capture and analyze SSI signal activity to diagnose communication issues and verify correct protocol operation.

  1. Attach probes to CLK, CS, MOSI, MISO, and DATA2/DATA3 (for Dual or Quad SPI modes).

  2. Confirm that the logic analyzer’s input voltage matches the board’s logic levels (for example, 3.3 V).

  3. Capture SPI transactions during normal SSI operation.

  4. Use the logic analyzer software’s SPI protocol decoder to analyze timing and data waveforms.

Example Capture#

The following figure shows SSI communication between two SiWx917 development kits (one configured as the primary, the other as the secondary) using DMA-assisted data transfers.

SSI Logic Analyzer Capture ExampleSSI Logic Analyzer Capture Example

Software Debugging Techniques#

In addition to hardware validation, software-level tools provide critical insight into SSI behavior.

Enable Debug Logging#

Enable debug logging to monitor SSI operations and print error messages or status codes.

Example:

if (status != SL_STATUS_OK) {
    DEBUGOUT("SSI Error: 0x%02X
", status);
}

Error Code Handling#

SSI driver APIs return standardized status codes (sl_status_t) that help identify communication issues and guide recovery actions.
Always check for SL_STATUS_OK after each API call to ensure successful operation.

Common Error Codes and Recovery Actions#

Error Code

Description

Recommended Recovery Action

SL_STATUS_OK

Operation successful.

Continue normal operation.

SL_STATUS_INVALID_PARAMETER

Invalid configuration or argument.

Verify and correct parameters.

SL_STATUS_BUSY

Peripheral is busy.

Wait for transfer completion or reset the peripheral.

SL_STATUS_TIMEOUT

Operation timed out.

Check signal integrity, chip-select timing, and retry.

SL_STATUS_TRANSMIT

Transmission error detected.

Verify CS, SCLK, and MOSI connections.

SL_STATUS_RECEIVE

Reception error detected.

Check MISO signal integrity and ensure secondary readiness.

SL_STATUS_NOT_INITIALIZED

SSI not initialized.

Call sl_si91x_ssi_init() before performing transfers.

Tip: For persistent errors, reset and reinitialize the SSI using sl_si91x_ssi_deinit() followed by sl_si91x_ssi_init() to restore the peripheral to a known state.

Interrupt Error Handling#

The SiWx917 SSI generates interrupts to signal events that require software handling.

Event Type

Description

Recommended Action

Transfer Complete

Indicates that a data transfer finished successfully.

Clear interrupt flags and prepare for the next transaction.

Data Lost (Overflow/Underflow)

Signals FIFO overrun or underrun conditions.

Reset the peripheral and verify buffer handling.

Note: Always clear interrupt status bits after handling an event to prevent repeated triggers.