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.

TMS320F28069: SPI loopback occurring even though disabled

Part Number: TMS320F28069

Hi,

I'm running into a problem where the SPIRXBUF reads out whatever is in the SPITXBUF. If the loopback function was turned on, I'd expect this -- but I have it turned off.

Here's my SPI transmission function.

void spiTxRx(uint8_t * pau8_txData,
                     uint8_t * pau8_rxData,
                     uint8_t u8_numBytes,
                     uint8_t u8_spiModule,
                     uint8_t u8_chipSelect)
{
     changeCS(u8_chipSelect, CHIP_SELECT_LOW); //set chip select low
     uint8_t u8_i = 0;
     if (u8_spiModule == SPI_MODULE_A_TX)
     {
          for (u8_i = 0; u8_i<u8_numBytes; u8_i++)
          {
               SpiaRegs.SPITXBUF= *(pau8_txData + u8_i);
               // Wait until data is received
               while(SpiaRegs.SPIFFRX.bit.RXFFST !=1) { }
               *(pau8_rxData + u8_i) = (SpiaRegs.SPIRXBUF) >> 8;
          }
     }
     if (u8_spiModule == SPI_MODULE_B_TX)
     {
          for (u8_i = 0; u8_i<u8_numBytes; u8_i++)
          {
               SpibRegs.SPITXBUF= *(pau8_txData + u8_i);
               // Wait until data is received
               while(SpibRegs.SPIFFRX.bit.RXFFST !=1) { }
               // Check against sent data
               *(pau8_rxData + u8_i) = SpibRegs.SPIRXBUF;
          }
     }
     changeCS(u8_chipSelect, CHIP_SELECT_HIGH); //raise chip select now that we're done transmitting
     return;

}

I've attached a screenshot of the SPI B registers that shows the loopback when I'm transmitting SPI. From SPICCR, you can see that bit 4 is 0, so the loopback is disabled.

I've tested this out on both A and B SPI ports on both a dev board (LAUNCHXL-F28069) and a custom PCB with the TMS320F28069 on it and got the same results.

Thanks in advance,

Karen

  • Karen,

    I am seeing the same behavior as you. I have actually never seen this behavior before. It seems to be dependent on the configured word length.

    Edit: removed an incorrect statement.

    The code will not hang at the while loop, but RXBUF will always read as 0xFFFF if configured as 16-bit words.

    Thanks,
    Mark

  • Karen,

    While I agree that this behavior is unexpected, I do not think that it is a good idea to use the data from RXBUF when nothing is connected. Are you only debugging right now? Will there eventually be something connected to SPISOMI?

    Thanks,
    Mark
  • Hi Mark,

    I had something attached to the SOMI line, but I was running into the same problem with the RXBUF echoing the TXBUF, so I tested out different ports.

    I changed the SPICCR.SPICHAR field to select a 16-bit word instead of an 8-bit word and that fixed the problem with the echo-back.

    Thanks!
    -Karen
  • Karen,

    Hmm, so even with something connected to the SOMI line, RXBUF was reflecting TXBUF? Can you drive a 3.3V on SOMI while transmitting, it should read 1s.

    I have put in a question to our design team to follow up on this. As it is the new year, we may not receive a response until some time next week.

    -Mark
  • Karen!

    I had an end of year short circuit of my brain. There is in fact no problem with the SPI here. Please read the following explanation.

    The transmit code is not shifting the data properly. When transmitting less than 16 bits, the transmit data should be left shifted to the upper bits of TXBUF.

    In your case, the SPI is only transmitting 8 bits, and the data you wish to transmit is in the lower 8 bits of SPITXBUF. So when the SPI begins the transmission, it transmits the MSbit first (left shift) and then into the LSbit comes the data on the SOMI line. After 8 bits are transmitted, the original data was shifted 8 bits left into the upper 8 bits of SPIDAT, with the lower 8 bits being the received data from SOMI and is then copied to RXBUF. This appears as if the SPI received the data that was transmitted, when actually the data never was transmitted in the first place.

    If the customer was scoping the waveforms, they would see that the data was never transmitted.

    For proper operation, left shift the data going into SPITXBUF, and then read SPIRXBUF while masking off the upper 8 bits.

    Sorry for all of the confusion. I hope this explains it well. I will ensure that there is adequate documentation in the TRM to explain this.

    Happy New Year.

    Mark
  • Hi Mark,

    Thanks for looking into it.

    Happy New Year!