Category: Hardware
Product Number: MAX96717F
I am writing to ask for your advice regarding SPI tunneling between a MAX96716F deserializer and a MAX96717F serializer.
Hardware Setup
The current hardware setup is:
-
NVIDIA Jetson Orin Nano running a custom Linux image (analogdevicesinc/gmsl: Gigabit Multimedia Serial Link (GMSL) technology from Analog Devices, Inc. (ADI)).
-
AD-GMSL522-SL carrier board.
-
MAX96716F EV kit connected to the carrier board through the Samtec connector. (i2c address 0x98)
-
MAX96717F EV kit connected to the MAX96716F over GMSL Link A using a coaxial cable. (i2c address 0x80)
-
An SPI peripheral connected to the serializer side.
Software
The Jetson device tree and pinmux have been modified to enable the SPI interface and pins on the carrier board. The SPI controller is successfully claimed by the Linux kernel, and communication through
/dev/spidev has been verified.Repository:
Intended SPI Configuration
The intended SPI direction is:
-
Jetson Orin Nano: SPI Master
-
MAX96716F: SPI Subordinate
-
MAX96717F: SPI Main
-
SPI peripheral: SPI Slave
Current Observations
Using simple SPI loop scripts, I first transmitted a single byte repeatedly (one byte per packet) and later repeated the tests using four-byte transfers.
On the deserializer side, the SPI interface behaves as expected:
-
SS1 asserts correctly.
-
The SPI clock is generated correctly.
-
MOSI contains the expected transmitted data (e.g. 0xA5).
-
The SPI waveform on the deserializer MFP pins appears correct.
However, the serializer side does not produce a valid SPI interface.
Specifically:
-
The serializer SPI clock output remains at a constant logic level.
-
The serializer SS1 output also remains at a constant logic level.
-
The serializer MOSI pin exhibits some activity, but it does not appear to be a valid SPI MOSI waveform.
During the one-byte transfer test I occasionally observed a waveform on the serializer MOSI pin that resembles the transmitted data, but it is significantly compressed in time and is not accompanied by a corresponding SPI clock or slave-select signal so it might be something completely different.
During the four-byte transfer test, the serializer MOSI pin still exhibits unusual activity. It appears somewhat noisy and is only present during portions of the deserializer SPI clock activity. The serializer SPI clock and SS1 outputs remain inactive.
Because of this, it appears that some form of signal or control activity is reaching the serializer, but the serializer does not begin driving a valid local SPI interface.
Register Observations (using GMSL SerDes Gui v6.9.4)
The SPI byte counter on the deserializer increases during transmission, for example:
RIB 98 0177 1 1RIB 98 0177 1 2RIB 98 0177 1 3RIB 98 0177 1 ...while the corresponding serializer SPI byte counter remains at zero:
RIB 80 0177 1 0The packet counters (
0x0025) increase on both the deserializer and serializer, which suggests that packets are traversing the GMSL link.Configurations Tested
So far I have tested:
-
SPI Mode 0 and SPI Mode 3.
-
One-byte and four-byte SPI transfers.
-
Different SPI Main/Subordinate configurations.
-
Different GPIO/MFP configurations.
-
RO/BNE configurations from the MAX96717F user guide (max96717fr-user-guide.pdf).
-
Verification of SPI timing using an oscilloscope.
-
Verification that the Jetson SPI controller is functioning correctly.
At this point, the remaining issue appears to be that the serializer does not generate the expected local SPI outputs despite the deserializer correctly receiving SPI traffic.
I was wondering whether there are any additional registers, initialization steps, or prerequisites specific to the MAX96716F/MAX96717F SPI control channel that might explain this behaviour.
In particular:
-
Is there any additional configuration required before the serializer begins driving its local SPI interface?
-
Are there any required link-initialization or reset procedures specific to the MAX96716F/MAX96717F? It seems to Auto-Link when both evkits are detected (indicated by LOCK LEDs on each evkit)
-
Are there any recommended registers or status indicators that you would suggest checking to verify that the SPI control tunnel is operating correctly?
I have attached oscilloscope and SerDes GUI screenshots, register dumps, and photographs of the setup for reference.
Any suggestions or guidance would be greatly appreciated.
Thank you all
RIB 98 0162 1 00 RIB 98 0170 1 09 RIB 98 0171 1 01 RIB 98 0172 1 03 RIB 98 0173 1 1E RIB 98 0174 1 1E RIB 98 0175 1 1E RIB 98 0176 1 04 RIB 98 0177 1 <incrementing> RIB 98 0178 1 00 RIB 98 0179 1 00 RIB 98 002C 1 04 RIB 80 0170 1 0B RIB 80 0171 1 01 RIB 80 0172 1 03 RIB 80 0173 1 1E RIB 80 0174 1 1E RIB 80 0175 1 1E RIB 80 0176 1 04 RIB 80 0177 1 00 RIB 80 0178 1 00 RIB 80 0179 1 00 RIB 80 002C 1 04
RIB 98 0001 1 1 RIB 98 0003 1 0 RIB 98 0005 1 0 RIB 98 0006 1 DE RIB 98 0010 1 11 RIB 98 0013 1 DA RIB 80 0001 1 4 RIB 80 0003 1 0 RIB 80 0005 1 0 RIB 80 0006 1 90 RIB 80 0010 1 1 RIB 80 0013 1 DA
