• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 33 subscribers
  • Views 184 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SN65C1167: Driving 1.5 metre cable with SPI

Jithin S
Prodigy 20 points

Part Number: SN65C1167

Dear E2E Team,

We have developed a CMOS sensor based smart camera, with IO (Digital & Analog) support to interact with field devices like Valves, Actuators etc. We have two hardware versions of the camera with different form factors. In the first version, we have populated all the IOs inside the camera in a separate PCB, with analog outputs realized using AD5686R (SPI DAC) and digital I/O via processor GPIO pins directly. In the second version, due to form factor constraints, we have planned to support the IOs, external to camera by means of Processor's SPI bus in a separate PCB.  Based on the Analog Application journal (slyt441), we have used the IC SN65C1167EPWR in our design for extension of SPI bus. We have two hardware boards (1 & 2) in the design.

Board 1: Power Board

Board 2: IO Expander Board

The connection between the two boards, with the hardware functional blocks in each board is shown in figure 1.

In the IO Expander Board, we have two slave devices (16-bit 4 channel serial DAC- AD5686R & 16-bit SPI IO Expander- MCP23S17).

Figure 1: Board 1 & 2 and the connection between them

Our camera's processing element is based on Zynq Ultrascale+ MPSoC, and is linux based. We have successfully tested the MCP23S17 device (at 1MHz SPI clock frequency) in output mode. But failed in testing the device in input mode.

Also, with the other device (DAC- AD5686R), there are issues with MOSI data transmission. Please find the table below for the expected and actual values of the DAC output voltage for the input count values.

DAC count
(in decimal)

Expected DAC output voltage
(in Volts)

Actual DAC output voltage (in Volts)

13100

1

2.3

25200

2

4.6

39300

3

3.6

52500

4

4.3

65500

5

5.3

 

We have followed all the design guidelines properly for the routing of differential pair, as well as all the suggested components in the application note, were included in the design. Also, we tried various experiments like: reducing cable lengths between the two boards (1.5 m and 0.5 m) & SPI clock speeds at 50MHz, 10MHz & 1 MHz.

We are actually stuck up with the testing. In fact, we have tried to probe the SPI signals, with oscilloscope's serial decode enabled.

Kindly help us to resolve the issue and move forward with the testing successfully.

Attached the SPI Extender design we used in both boards:

Board 1 - SPI Extender

                                                                                                                Board 1 - SPI Extender design

                                                                    Board 2 - SPI Extender design

  • 0
    TI__Guru 50835 points

    Hi Jithin,

    Thank you for the detailed explanation of your system and the task that this device is performing in context. 

    How do the two slave devices determine which has control of the MISO signal on the IO board? It appears that the DAC needs to have a sync pin asserted to accept SPI data whereas the IO expander is address based. Are there other control signals that are being passed from the power board to the IO board to facilitate this slave selection? Are the CS1 and CS2 signals in Figure 1 carried between boards some other way?

    Is it possible to share more information regarding the results from the SPI analyser test when SPI frames were captured on an oscilloscope? I'm curious to see what the timing between signals looks like after the combined propagation delay from to transceivers and isolator. I would also be interested to see if there are any issues when the system runs at a data rate where these delays are entirely negligible such as a 10kHz clock rate. This will help us determine if the issue is based on the synchronization of the MISO signal from the slave being off from the master's clock signal or if there is a an issue with some relative timing that is independent of clock speed. 

    Regards, 
    Eric Schott