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.

AM625: MCSPI bidirectional communication with half-duplex

Part Number: AM625

Our customer wants to connect the slave device "RV-8063-C7" with 3-pin SPI. "RV-8063-C7" has a half-duplex bidirectional data pin (SIO), but does not have full-duplex bidirectional data pins (SI and SO).

Can MCSPI on AM62x connect a slave device with half-duplex bidirectional data pin (SIO)?

If so, how can it be connected?

Which should be used, one data pin (switching MO or MI) or tied two data pins (both MO and MI)?

For one data pin (switching MO or MI), the transmit-only mode and the receive-only mode will need to be switched in software since MCSPI does not support the transmit-and-receive mode with half-duplex.

We are concerned about output collisions between connected data pins.

Are the MCSPI data pins high impedance except when the data output is active?

Best regards,

Daisuke

  • Hello Daisuke,

    Thank you for the query.

    I need to check with the experts internally and come back.

    Please expect some delay.

    Regards,

    Sreenivasa

  • Hi Sreenivasa-san,

    Thank you for your support. Our customer is waiting for your update.

    Please give me an answer by Friday morning (Japan time). Your prompt reply would be appreciated.

    Best regards,

    Daisuke

  • Hello Daisuke,

    Thank you for the note and push.

     Refer below input i received from the expert:

    However there are two possibilities that I can immediately think of:

     Use a single channel.

    1. Writes would work as a normal spi channel
      Reads.  Send command word, change pin configuration, read data.  (CS needs to be manually controlled).
    2. Use 2 channels
      Channel A for writes and for read command.
      Channel B for read data

      Config needs to change between reads and writes.
      Other than manual control of the CS, the switch between command and read data should be automatic

     

    #1 should work but requires software to manage the change been command a read data.

    #2 would need to validated to prove it’s viable.

     Regards,

    Sreenivasa

  • Hi Sreenivasa-san,

    Thank you for your reply.

    We are concerned about output collisions between connected data pins.

    Are the MCSPI data pins high impedance except when the data output is active?

    Could you also give me an answer to another question?

    Best regards,

    Daisuke

  • Hello Daisuke,

    Thank you.

    Please refer the inputs i received from the device expert.

    The output buffer associated with output pins of each device will only be enabled when it’s it is sending data and the protocol ensures only one device is driving data at any time.  So the output buffer of the device not driving data will be high-Z.

    Regards,

    Sreenivasa

  • Hello Daisuke,

    Please note that i have updated the above message in the thread with the information i received from the device expert.

    Regards,

    Sreenivasa

  • Hello Daisuke,

    Based on your request below, i am adding the answers as i receive for the IP related questions on the SPI interface

    Please give me an answer by Friday morning (Japan time). Your prompt reply would be appreciated.

    Here are additional inputs i received. Please read through the inputs 

    If the Hi-Z question is in relation to the E2E post, then in order to receive data, you must write data to the Tx buffer, otherwise no spiclk will be generated.   Writing TX data will result in the DO pin driving. Only way to ensure DO  is not driving, is to disable the driver, or configure the signal appropriately in the IP.  Disabling the TX output in the padconfig register would be another (simpler) way of implementing this using a single channel.  The CS would still need to be manually controlled. Automatic control of CS would result in an undesired de-assertion  of the CS between the command word (TX) and the RX data, these would be seen as 2 transactions by our IP.

    Regards,

    Sreenivasa

  • Hi Sreenivasa-san,

    Thank you for your reply.

    Our customer will consider using a slave device with 4-pin SPI in their next custom board revision.

    Best regards,

    Daisuke

  • Hello Daisuke,

    Thank you for updating customer resolution.

    Regards,

    Sreenivasa