We are currently evaluating the ADIN3310 using the EVAL‑ADIN3310 development board. Our intended workflow is to perform an initial configuration over SPI, and then hand over control to Ethernet Port 0.
We have built and integrated the ADIN33x0 TSN driver library, and configured the switch to use single‑SPI as the host interface. During bring‑up, the initialization fails with a timeout in SES_AddDevice(), and we observe no activity on the MISO line. Additionally, TIMER0 remains low.
On the bus side, CS, SCLK, and MOSI appear correct on the scope. The driver sends a 32‑bit SPI transaction (repeated twice), but no response is received from the ADIN3310. At this point, we would expect valid data to be driven on MISO for device enumeration.
What we checked so far:
- The device has valid firmware: We can successfully connect to the ADIN3310 by configuring Ethernet Port 0 as the host interface.
- Bootstrapping pins are correctly set at reset: CS, TIMER0, TIMER1 = HIGH, TIMER2, TIMER3 = LOW.
- Supply voltages: VDD and the SPI I/O voltage are both at 3.3 V.
- SPI configuration: Clock reduced to 100 kHz and all four SPI modes tested.
Given the timeout in SES_AddDevice(), we suspect the ADIN3310 is not responding as expected to the initial SPI discovery/handshake sequence.
During SES_AddDevice(), is the ADIN3310 expected to drive MISO and return a valid response in single‑SPI mode, or is a prior configuration/state (e.g., TIMER0 assertion, SPI_SIO configuration, or alternate frame format) required before MISO becomes active?
Any guidance on additional checks or common SPI bring‑up pitfalls around SES_AddDevice() would be greatly appreciated.
