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.

TMS320F28386S: CM's SSI port issue

Part Number: TMS320F28386S


Tool/software:

Good morning.

I am using CM core to communicate with BT815 based display with SPI and faced strange behaviour. Before I implemented same display using Tiva C, STM32 and FTDI chip on PC, whithout problems.

But when I'm using CM's SSI, I see when I read data from SSI it is shifted one bit right. As the communication with display is half duplex, so I do not have to write and read at the same time, I have to set clock phase to 1 before reading and restore it to 0 after. It works, but not realy convinient. As I see, the C28x core's SPI ports behave the same. 

Is there any cure for this? Thank you!

  • This sounds like there may be a mismatch on the clock polarity and phase configuration. Please review the sections in the TRM to ensure the SSI is configured to match the polarity and phase configuration required by your BT815 device.

    47.2.5.1 Freescale SPI Frame Format

  • The polarity and phase configuration required by BT815 device is polarity=0 and phase=0.

    So I set the Freescale Mode 0 for this device alwais. It works fine on Tiva C, STM32 and the FTDI USB-2-SPI converter, but not on TMS320 device

    I was trying all the possible configurations, but the device responds correctly only with CLK Pol=0 and CLK Phase=0. But the SSI port receives the data shifted one bit. The only way for now to make this work is:

    [Set Pol=0, Phase = 0]

    [Send command(s)]

    [Set Pol=0, Phase = 1]

    [Send 0 and read response]

    [Set Pol=0, Phase = 0]

    The same issue I see when I work with ADS8900 from C28x CPU1 core, so I set the SPI_PROT_POL0PHA0 to write ADC configuration registers and then change it to SPI_PROT_POL0PHA1 to read the measured value, thanks the ADC read data comand is 0.

  • From the BT815 DS, the data should be sampled on rising edge of clock, and driven on falling edge of clock. The clock is also default in low state. 

    This corresponds to Freescale mode, SPO=0, SPH=0 on the C2000 SSI port.

    I would recommend looking at the SSI signals on a logic analyzer to ensure the signaling is indeed as expected. 

  • Yes, I know it, and, again, the SSI port is set up right to  SPO=0, SPH=0.

    The logic analyzer (I use Digilent one) shows correct response to the command (the first command checks for CHIP ID which should be 7C alwais, and analyzer shows 7C response). But the SSI reads it as 3E. 

    The same configuration on STM32, Tiva C and FTDI converter shows no problems, returning 7C.

    The only workaround I found is to switch SPH to 1 right before reading and then switch it back to 0.

  • At what frequency are you running the SSI output clock? I'm wondering if there is a setup timing issue on SSIRx. Perhaps changing SPH=1 buys more setup time and that's why it functions properly during reads. Have you tried running the SSI output clock slower? 

  • 12MHz is the standard clock speed for this device. On STM32 I occasionally raised it to 45MHz, but it still was working.

  • I took another look at the BT DS to understand what setup and hold time can be expected on the MISO pin. The BT DS only gives a max Tod spec, so it is not possible to calculate the min hold time the MCU can expect. Per F2838xd MCU DS, the SSI requires a 2ns hold time. Is it possible the BT device is not meeting this hold time spec and the SSI is always reading one bit delayed? 

  • I'm sorry, ignore the last comment. This is incorrect observation on my part. The setup and hold time specs are fine. 

  • Can you please share the logic analyzer plot for analysis? 

  • Unfortunately, I am working remotely now, and will be at facility whre the device is set within couple of weeks.

    But I'll try to ask colleagues to connect the analyzer and capture the results. I will do it with F2838x device as well as with STM32 one, to compare.