Hardware Debug
Few methods are available to debug the Holoscan Sensor Bridge in hardware to narrow down the issues.
Data Generator
Internal to the Holoscan Sensor Bridge IP, there’s a Sensor Data Generator that drives the Sensor RX Interface signals. Enabling the Sensor Data Generator tests from the internal Sensor RX to Host TX Dataplane path to verify correct RoCE/CoE configuration and Host TX path is integrated correctly. To enable Data Generator:
- Add `define SIF_RX_DATA_GEN to “HOLOLINK_def.svh”
- Add the below code to the python script and call the function after setting up the receiver.
Packet Sequence Number (PSN) Registers
Packet Sequence Number registers count the number of packets at various dataplane traffic of the Holoscan Sensor Bridge.
Sensor Interface (SIF) TVALID Counter SIF TVALID Counter register increments for every clock cycle “i_sif_axis_tvalid” is asserted. If this register is not incrementing, check the driver and connection to “i_sif_axis_tvalid” port.
Sensor Interface Start of Frame (SOF) PSN Start of Frame is considered as the first cycle “i_sif_axis_tvalid && o_sif_axis_tready” after “i_sif_axis_tlast” is asserted. In camera application, “i_sif_axis_tlast” is asserted at the end of a frame. If this register is not incrementing, check the SIF TVALID counter is incrementing and “i_sif_axis_tlast” is properly asserted. If those signals are properly asserted, Holoscan Sensor Bridge “o_sif_axis_tready” is stuck low, which could indicate Host Dataplane traffic is in a stuck state.
Host Dataplane PSN Once sufficient sensor data is received to send out an Ethernet packet sized by configurable register, sensor data is encapsulated by CoE or RoCE headers and transmitted via Host TX Interface. Each Dataplane Host packets sent are incrementally numbered. If this register is not incrementing, either no sensor data is driven into Holoscan Sensor Bridge IP or the CoE/RoCE configuration is not set properly to transmit the data.
Peripheral Debug
The SPI and I2C controllers provide status registers to help debug communication issues.
Status Register Monitoring Monitor the STATUS register (offset 0x0300_0080 for SPI and 0x0300_0280 for I2C).
For SPI and I2C controllers:
- BUSY (bit 0): 1 = transaction in progress, 0 = idle
- FSM_ERR (bit 1): Configuration errors (e.g., invalid byte counts)
- DONE (bit 4): Transaction completed successfully
I2C Additional Status Bits
- ARB_LOST (bit 2): Arbitration lost (multiple masters)
- NACK (bit 3): Slave sent negative acknowledge
Common Issues and Debug Steps
-
Transaction Not Starting
- Check CONTROL.START bit is set
- Verify BUS_EN register selects correct device
- Monitor BUSY bit transition from 0 to 1
-
Transaction Stuck in BUSY State
- Check FSM_ERR bit for configuration errors
- Verify byte count registers are valid
- For I2C: Check device address and timeout settings
- For SPI: Check SPI_MODE and PRESCALER configuration
-
Communication Failures
- I2C NACK: Verify device address and power
- I2C ARB_LOST: Check for bus contention
- SPI Data Issues: Verify SPI_MODE and clock frequency
- All: Check signal integrity with oscilloscope
UART Debug Registers
Use UART status and debug registers at base 0x0300_0400 to isolate RX/TX path issues:
- STATUS0 (0x0300_0480):
- TX_BUSY (bit 0) / RX_BUSY (bit 1): Activity indicators
- TX_FIFO_EMPTY (bit 3) / RX_FIFO_NOT_EMPTY (bit 5): FIFO flow state
- RX_PARITY_ERROR (bit 6), RX_FRAME_ERROR (bit 7), TX_OVERFLOW (bit 8), RX_OVERFLOW (bit 9), RX_GLITCH_ERROR (bit 13): Sticky error bits
- LAST_RX_VALID (bit 10): Indicates
LAST_RXcontains valid data
- STATUS1 (0x0300_0484):
- Sticky interrupt status for TX empty/almost-full/almost-empty, RX not-empty, and RX glitch error
- LAST_RX (0x0300_0548):
- Non-destructive view of the most recent byte consumed from
RX_DATA
- Non-destructive view of the most recent byte consumed from
Clear sticky interrupt/error conditions through CTRL3 (0x0300_040C) and clear
LAST_RX_VALID via CTRL0[10] (0x0300_0400).