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.

AM5728: SPI issues

Part Number: AM5728


Hi Support,

my customer is facing issues when trying to use SPI3, SPI4 on AM5728 rev2.0 EVM board.

Current goal is to have master SPI3 for Tx only, slave SPI4 for Rx only, both pinmuxed to P16 connector.

Please see relevant excerpts...

 

  • ... from boardPadDelayInit.c : boardPadDelayCfg_t pad[]:

    /* SPI4 slave, Tx on D1; Rx unused */

/* SPI3 - clk on B12 (P16-GPIO5_10: 34) */
     {0x16D4, 0xD0003, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},
/* SPI3 - d1 on A11 (P16-GPIO5_11: 4);  MOSI Tx */
     {0x16D8, 0xD0003, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},
/* SPI3 - d0 on B13 (P16-GPIO5_12: 33);     MISO  (UNUSED) */
     {0x16DC, 0xD0003, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},
/* SPI3 - cs0 on A12 (P16-GPIO5_17: 3) */
     {0x16E0, 0x90003, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},

     /* SPI4 slave, Rx on D0; Tx unused */
/* SPI4 - clk on N7 (P16-VIN3A_HSYNC: 9) */
     {0x1460, 0xD0008, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},
/* SPI4 - d1 on R4 (P16-VIN3A_VSYNC: 37);     MISO (UNUSED)*/
     {0x1464, 0x90008, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},
/* SPI4 - d0 on N9 (P16-VIN3A_DE0: 14);     yellow; MOSI (Rx-input) */
     {0x1468, 0xD0008, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},
/* SPI4 - cs0 on P9 (P16-VIN3A_FLD: 44)*/
     {0x146C, 0xD0008, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},

  • ... from evmAM572x_clock.c: Board_moduleClockInit():

/* Added SPI3 support for master loopback */

    CSL_FINST(l4PerCmReg->CM_L4PER_MCSPI3_CLKCTRL_REG,
        L4PER_CM_CORE_COMPONENT_CM_L4PER_MCSPI3_CLKCTRL_REG_MODULEMODE, ENABLE);
/* Added SPI4 support for slave loopback */
    CSL_FINST(l4PerCmReg->CM_L4PER_MCSPI4_CLKCTRL_REG,
        L4PER_CM_CORE_COMPONENT_CM_L4PER_MCSPI4_CLKCTRL_REG_MODULEMODE, ENABLE);

  • ... from main_mcspi_slave_mode.c: SPI_test_mst_slv_xfer():


#define MCSPI3_BASE 0x480b8000
#define MCSPI4_BASE 0x480ba000
#define WR_REG(reg, val) (*(uint32_t*)(reg) = val)
#define RD_REG(reg, var) (var = *(volatile uint32_t*)reg)
#define SPI3_CH1CONF (MCSPI3_BASE + 0x12c)
#define SPI4_CH1CONF (MCSPI4_BASE + 0x12c)

 

    if (master == true)
    {
        transaction.txBuf = (Ptr)masterTxBuffer;
        transaction.rxBuf = (Ptr)addrMasterRxBuf;
        /* Set master D0_in D1_out */
        RD_REG(SPI4_CH1CONF, cnf);
        cnf |= 1 << 16;
        cnf &= ~((1 << 18)|(1 << 17));
        WR_REG(SPI4_CH1CONF, cnf);
    }
    else
    {
        transaction.txBuf = (Ptr)slaveTxBuffer;
        transaction.rxBuf = (Ptr)addrSlaveRxBuf;
        /* Set slave D0_in D1_out */
        RD_REG(SPI3_CH1CONF, cnf);
        cnf |= 1 << 16;
        cnf &= ~((1 << 18)|(1 << 17));
        WR_REG(SPI3_CH1CONF, cnf);
    }

---------------
Then they pairwise interconnect pins on P16, so that SPI3 master can transmit to SPI4 slave receiver:
34-9 (clk)
4-14 (data)
3-44 (cs0)

... and they then continue in stepping through main_mcspi_slave_mode.c:

    /* Initiate SPI transfer */
    transferOK = SPI_transfer(spi, &transaction);

    if(transferOK) {
/* ... */
}

they don't receive any message neither in masterRxBuffer, nor in slaveRxBuffer, although by looking at oscilloscope, master SPI is transmitting.

  • Another finding was that, when swapping the master-slave roles so that SPI3 is slave, SPI4 is master, then SPI3 slave receives the message correctly, SPI4 master receives nothing.
  • Yet another finding is when trying SYSTEM_TEST, setting clock high on SPI4 and reading on SPI3 register, 1 is detected, as expected, but when setting clock on SPI3 and reading on SPI4, 0 is detected.

(This seems to me like if the SPI4 clock input is not working properly for unknown reason. Or I could also miss something in the device configuration?)

Could you please give me some hints?

Thank you in advance,

regards,

Alberto

  • Hi Alberto,

    What software is this? Linux, RTOS...
  • Biser,

    this is TI-RTOS since there is not SPI-slave ready driver for Linux.
    And where needed (e.g. SPI SYSTEM_TEST), my customer is using direct register addressing.
    Please let me know your feedbacks.

    Thanks,
    Alberto
  • Thanks Alberto. I have notified the RTOS team. They will respond here.
  • Alberto,

    Can you specify the MCSPI_SYST setting in both the cases. Is the SPIENDIR, SPIDATDIR0 and SPIDATDIR1 for SPI4 being set correctly in the code ?

    The other thing to watch out for is the note for the spim_sclk signals on the master mode to work properly, the INPUTENABLE bit of the appropriate CTRL_CORE_PAD_x registers should be set to 0x1 because of retiming purposes. This note is added to the TRM under "Basic MCSPI Pins for Master Mode" description.

    Regards,
    Rahul

  • Hi Rahul,

    doing tests my customer noticed that there might be another effect influencing the outcome of an experiment with SPI.
    Briefly:
    • When loading/running the application via XDS560 emulator, which connects to running TI-RTOS, they are facing the problems mentioned above.
    • When loading/running the application via XDS100, which connects only after first boot TI-RTOS, then they remove the SDcard, then reboot the device (ceteris paribus) then the SPI4 runs as expected.

    Since for now they don't have enough control over the whole SDcard-boot-to-application-run chain to allow easy reproducible, I suggest that I continue getting things simpler until they are able to send us a complete package with cases description.

    Thanks for your interest and help,
    Alberto
  • Hi Alberto,

    Just to be safe, let's make sure the RX buffer on these pins is enabled. For SPI3 all the register values should be 0xD0003 and for SPI4 they should all be 0xD0008.

    Regards,
    Ahmad
  • Ahmad,

    yes that pin was enabled since the beginning.

    My customer achieved some advancement in getting SPIs on Sitara working.

    He is now solving an issue with bitrate. Please take a look at oscilloscope pictures for 6 and 12 MHz with time cursors either byte-to-byte, or bit0-bit7.

    The strange behavior is obvious. Whatever bitrate they set (above 1.5MHz), the byte-to-byte delay seems to remain approx. the same, and so is the true bit-rate.

    They use SPI3 and SPI4 in a 2-hreaded BIOS application, a modified version of SDK's example, i.e. with master and slave thread.

    They also use non-DMA interrupt mode.

    They've checked namely that  MCSPI_MODULCTRL[0] SINGLE = 1, CHxCONF[9] TURBO = 1, CHxCONF[28,29] FFER, FFEW = 1, which should assure that single-channel, turbo mode with FIFOs enabled is used - if I got it correctly...

    Could you please point in a possible direction to explore more deeply?

    Please note this issue is now urgent and will need escalation if not solved quickly.

    Thank you,

    regards,

    Alberto

    Screen Captures.zip

  • As further information, I asked customer to test IDK and the result is the same also with this tool.
    Please reply urgently.
    Thanks
    Alberto
  • Alberto,

    It may be good to know what has been changed in the code from the master slave example that we provide other than the SPI clock settings.
    the other thing to check is during the transfers, is there a Task_sleep value being used in the multi-threaded application and what is the value can this be optimized. the McSPI driver only has a initDelay configuration and no other fixed delays.

    If the driver is being configured in BLOCKING MODE then the driver pends for the Semaphores to be posted. Is the driver configured in BLOCKING or CALLBACK mode? Or check the configuration and specify if it is non-dma interrupt mode, polling mode or non-dma callback mode.

    Regards,
    Rahul
  • The driver by default disables the turbo mode (CHxCONF[9] TURBO = 0), we haven`t tested the clock timing in turbo mode (though the spec indicates it is used for multi-words transfer). Can you test this setup in non-turbo mode? Also, confirm if they are using the driver’s default configuration of initDelay and TCS0 or have they been modified?
  • The resolution for this issue was done by updating McSPI driver from PRSDK 3.2 to PRSDK 3.3 which has an EDMA based driver implementation.