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.

MCU-PLUS-SDK-AM243X: MCSPI drivers not working well for TI AM243x LP

Part Number: MCU-PLUS-SDK-AM243X
  • I am able to use TI’s SDK ,mcu_plus_sdk_am243x_08_06_00_45, example (mcspi_loopback) to send/receive data over SPI between two AM243x LP boards, but only this example works while other examples (i.e. mcspi_performance_8bit..) were not working at all.
  • Although “mcspi_loopback” example is working but it can only use API function “MCSPI_transfer()” to send and receive SPI data between master/slave at the same time (synchronously) which is not usable in our use cases. We need either Master or Slave can send and receive SPI data at any time (asynchronously) .
  • I have tried other SPI drivers (MCSPI_writeTxDataReg() and MCSPI_readRxDataReg()) to write and read SPI data respectively but not working.
  • Other than MCSPI_transfer(), MCSPI_writeTxDataReg() and MCSPI_readRxDataReg() API function calls, is there any other API I can use to read and write SPI data?
  • Could you provide any examples for individual Master and Slave (Peripheral) SPI devices?

Thanks.

  • Hi Allen,

    The mcspi_loopback example in mcu_plus_sdk_am243x_08_06_00_45 is only an example program to show the customer how the MCSPI works easily. It uses the internal loopback which receives what it sends by define the Input Select as D0 (which is also the TX pin) in syscfg. Ultimately it is a SPI Controller example.

    If you want to exchange data between two AM243x LPs, you will need to connect two LPs using blue wires (LP1:D0 <--> LP2:D1, LP1:D1 <-> LP2:D0, LP1:CLK <--> LP2:CLK, LP1:CS <-> LP2:CS). Input Select should be changed to D1 in syscfg for the MCSPI controller. The MCSPI_transfer will either TX only or TX and RX at the same time according to the TR Mode in syscfg. Most of the time, you want set to TX and RX mode, in that case, the TX and RX happen at the same time. If you are sending data only this time, just ignore what is in the RX buffer. If you are receiving data only, just put garbage data in TX buffer, because in the MCSPI protocol, the MCSPI controller is always the clock provider and transaction initiator.  

    For the program runs on the MCSPI peripheral, you will need to change the Mode of Operation to Single Peripheral

    Once your syscfg file is set up properly, the MCSPI instance open will be handled by the Drivers_open() automatically.

    Best regards,

    Ming

  • Hi Ming, Thank you for the reply. Actually I had done what you mentioned in the reply and yes, it worked as you explained. However, my question is when I connect one AM243x LPs to other MCU's SPI port (i.e. STM32) then this function won't be working unless I can implement this “MCSPI_transfer()” function in STM32 MCU. So my intention is to implement the functions like in example, "mcspi_performance_8bit", and turn it to be able to not only write "SPI data" but also read "SPI data".

    By the way, in example, "mcspi_performance_8bit", it seems never send out data via SPI interface properly.

    If there is any instruction or example program can indicates how to utilize MCSPI API functions to send/receive SPI data with other MCU's SPI interface via 3/4 pin connections.

    Thank you!

    Allen

  • Hi Allen,

    Which is the SPI master in your set up? AM243x LP or the STM32 MCU? If AM243x LP is the master, then nothing you need to change on AM243x side. If you want to send data, use the MCSPI_transfer, ignoring what is in the RX buffer. If you want to receive data, use the MCSPI_transfer, but set TX buffer to 0, when it returns, get what is in the RX buffer.

    On the STM MCU side, simply implement it as a SPI slave device.

    Best regards,

    Ming

  • Hi Ming,

    Thank you very much. We will implement SPI master and SPI slave using two SPI ports. Could you also indicates how to use API to implement SPI slave and it will send data whenever it needs to send (not like using MCSPI_transfer() to wait until master trigger it).

    Thank you,

    Allen

  • Hi Allen,

    As I mentioned before, The SPI slave cannot send data to SPI master actively. A data transfer has to be initiated by the SPI master. The SPI slave can only send data when it is requested by the SPI master.

    If you want to send data actively in both directions, then you have to implement the SPI master on one SPI instance and SPI slave on another instance on one SoC. For example, on AM243x LP side, you use the SPI0 for master and SPI 1 for slave. On the other side (STM MCU), you have to implement the SP0 for SPI slave and SPI1 for SPI master.

    Best regards,

    Ming 

  • Hi Ming,

    In the previous reply, you mentioned "If you want to receive data, use the MCSPI_transfer, but set TX buffer to 0, when it returns, get what is in the RX buffer."

    Does it mean:

    MCSPI_Transaction   spiTransaction;
    spiTransaction.txBuf    = NULL;

    When I config this SPI master it as "Interrupt Mode" and "Blocking", the MCSPI_transfer() still keeps returning even there no data being received. Does it mean I need to keep check rx buffer until I got some data?

    Thank you,

    Allen

  • Hi Allen,

    No. I meant to set the content of the TX buffer to 0. The spiTransaction.txBuf  needs to point to the TX buffer.

    Since the SPI master to receive data, it has to provide the clock and CS for the SPI slave to send data while the SPI master is sending garbage data, so the SPI master receive will not be blocked. It will return when the garbage data has been sent out. The RX data should have the received data ready too. Igf the SPI slave is not ready to send the data out to the SPI master, then the SPI master will receive invalid data, but it will return what so ever.

    In another word, the SPI slave should be always prepared to transfer data when the CS is validated and the clock is provided, but the SPI slave can never initiate the data transfer by itself.

    Best regards,

    Ming.

  • Thank you so mach!