RTOS/TMS320C6748: SPI receiver problem

user5238872

Part Number: TMS320C6748
Other Parts Discussed in Thread: OMAPL138,

Tool/software: TI-RTOS

Hi,

I am developing a driver for the SPI interface, I do not want to use interrupts so I am developing with polling.

I can transmmit correctly and my slave SPi is sending correctly the response, the problem is that I can not control when the response byte is received.

I show my source code and try to explain the problem:

/*Clear reception flag: write 1 in the SPI_SPIFLG in RXINTFLG*/ (First line)
ClearSPIFlagReceptionBuffer(uiSPIReg);
/*Write data in SPI_SPIDAT1*/
SPITransmitData1(uiSPIReg, pucOutBuffer, CS_NONE_UI); --> Correct send of the byte

// Wait to the byte is sent
uiStatusSPI = SPIFlagStatus(uiSPIReg);
while (!(uiStatusSPI & SPI_SPIFLG_TXINTFLG_UI)){
uiStatusSPI = SPIFlagStatus(uiSPIReg);
}
/*Wait for TXBUF Available*/
while (SPIReceiveBufferEmpty(uiSPIReg))
{
}

/*Now a new byte is received in SPI_SPIBUF. I read it*/
usReceivedData = SPIDataReceive(uiSPIReg);

/*I save the input byte*/
pucInBuffer[uiNumReceivedData] = (Char_uc)usReceivedData;
uiNumReceivedData++;

/*I send a new byte*/
SPITransmitData1(uiSPIReg, ucZero, CS_NONE_UI);
/*Check the byte has been transfered*/
uiStatusSPI = SPIFlagStatus(uiSPIReg);
while (!(uiStatusSPI & SPI_SPIFLG_TXINTFLG_UI)){
uiStatusSPI = SPIFlagStatus(uiSPIReg);
}
/*Wait for TXBUF Available*/
while (SPIReceiveBufferEmpty(uiSPIReg))
{
}

// FAIL: usReceivedData is sometimes the response of the second byte and others the response of the first byte transmitted.

usReceivedData = SPIDataReceive(uiSPIReg); (FAIL line)

Also I have checked that if I execute in debug mode and I stop in the last line (FAIL LINE) the response byte is always read correctly, so it can be a time error.

Also I have notice a weird behaviour with the CS and SPI_SPIDAT1. When I write SPIDAT1 with new data, data is sent and the SPI CLK is also sent (in case the CS is low), correct behaviour. However if I update the CS value in the SPIDAT1 to set to HIGH, the SPI CLK and MOSI are also sent when I do not want to sent a new data value, only I want to update the CS.

I have tried modifying only the byte where the CS is in SPIDAT1, but the SPI CS is not update although I can check in the debug register that the value is updated to high (I check in my oscilloscope that the SPI CS signal is still low).

HWREGB(uiBaseAdd + SPI_SPIDAT1_UI+2) = (Char_uc) uiCSNR ;

Thank you very much.

Best regards,

Lucía

over 6 years ago

0 Sahin Okur over 6 years ago

TI__Mastermind 27355 points

Hello Lucía,

We generally don't support custom driver development. We have a working SPI driver + example for C6748 in Processor SDK RTOS that we are happy to support. Can you please take a look at that for reference?

Processor SDK RTOS download link:
www.ti.com/.../PROCESSOR-SDK-C6748

Instructions on building the SPI example:
software-dl.ti.com/.../index_device_drv.html

SPI driver source code location:
~\pdk_omapl138_1_0_6\packages\ti\drv\spi

0 user5238872 over 6 years ago in reply to Sahin Okur

Prodigy 220 points

Hi,

The problem is that the RXINTFLG Bit in SPIFLG Register is not reset when I tried to reset.

I tried to clear by two ways according the datasheet (I call the two ways consecutively):

- Writing a 1 to this bit

- Reading the SPIBUF

But the bit is not clear and it looks a new byte is in SPIBUF.

I checked in your documents (SPRZ285.pdf and SPRZ232F.pdf) that other TMS320 boards have the same problem because a silicon error.

Do you know how resolving this error?

Thank you very much,

Lucía

0 Sahin Okur over 6 years ago in reply to user5238872

TI__Mastermind 27355 points

Hi Lucia,

Table 28-13 in the C6748 TRM lists all the ways to clear this bit:

Regards,
Sahin

0 user5238872 over 6 years ago in reply to Sahin Okur

Prodigy 220 points

Hi,
I had seen this table in the datasheet. However, this bit is not reset always using only one way. Sometimes, the bit is reseting only after using two ways consecutively how SPRZ285.pdf and SPRZ232F.pdf is explaining.
So, i need you confirm me that the TMS320C6748 has the same silicon error that these files are detailing.

Thank you very much,

Lucía

0 Sahin Okur over 6 years ago in reply to user5238872

TI__Mastermind 27355 points

Hello,

I'll need to reach out to the design team to confirm if it's a silicon bug or not. I will post a reply here once I have an update.

Regards,
Sahin

0 Norman Wong over 6 years ago

Guru 26430 points

You should not assume which order the TX and RX flags happen. You might be overlooking that the flags are one word off due to the shift register underneath. Some possible example code:

void SPITransfer(unsigned int uiSPIReg,
                 int n,
                 const unsigned char *ptx,
                  unsigned char *prx)
{
  int nrx = n;
  int ntx = n

  ClearSPIFlagReceptionBuffer(uiSPIReg);
  (void)SPIDataReceive(uiSPIReg); // Dummy Read

  while(ntx && nrx)
  {
    uiStatusSPI = SPIFlagStatus(uiSPIReg);
    if (uiStatusSPI & SPI_SPIFLG_TXINTFLG_UI)
    {
      if (ntx)
      {
        SPITransmitData1(uiSPIReg, *ptx++, CS_NONE_UI);
        ntx;
      }
    }

    if (uiStatusSPI & SPI_SPIFLG_RXINTFLG_UI)
    {
      if (nrx)
      {
        *prx++ = SPIDataReceive(uiSPIReg);
         nrx--;
      }
    }
  }
}

The first transmit byte will move from the TXBUF into the shift register almost instantly.

The second transmit byte can written to the TXBUF very soon after the first.

The third transmit byte has to wait for first to get out the shift register. That happens at the same time as the first receive byte gets moved from the shift register to RXBUF. So the 3rd TXINT and 1st RXINT occur at the same time and any order.

Processors

Processors forum

RTOS/TMS320C6748: SPI receiver problem