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.

LAUNCHXL-CC3235SF: Incorrect data received on SPI port

Part Number: LAUNCHXL-CC3235SF
Other Parts Discussed in Thread: CC3235SF

Hello,

I am trying to get correct data on SPI port. But I am facing a strange behavior.

I am using cc3235 as a SPI master and trying to perform an SPI transaction.

The data sent is always as expected. But, sometimes the data is received over SPI is as expected

and sometimes the data received is incorrect.

I checked the data on Logic analyzer it is correct and as expected.  Please check attached screenshot.

Below are the settings i am using:

{
.baseAddr = GSPI_BASE,
.intNum = INT_GSPI,
.intPriority = (~0),
.spiPRCM = PRCM_GSPI,
.csControl = SPI_SW_CTRL_CS,
.csPolarity = SPI_CS_ACTIVELOW,
.pinMode = SPI_3PIN_MODE,
.turboMode = SPI_TURBO_OFF,
.scratchBufPtr = &spiCC3235SDMAscratchBuf[CC3235SF_LAUNCHXL_SPI1],
.defaultTxBufValue = 0,
.rxChannelIndex = UDMA_CH6_GSPI_RX,
.txChannelIndex = UDMA_CH7_GSPI_TX,
.minDmaTransferSize = 100,
.mosiPin = SPICC32XXDMA_PIN_07_MOSI,
.misoPin = SPICC32XXDMA_PIN_06_MISO,
.clkPin = SPICC32XXDMA_PIN_05_CLK,
.csPin = SPICC32XXDMA_PIN_NO_CONFIG
}

SPI_Params_init(&spiParams);
// spiParams.frameFormat = SPI_POL0_PHA0;
spiParams.mode = SPI_MASTER;
spiParams.bitRate = 2000000;
spiParams.dataSize = 8;

masterSpi = SPI_open(Board_SPI0, &spiParams);
if (masterSpi == NULL) {
UART_PRINT("Error initializing master SPI\n");
while (1);
}
else {
UART_PRINT("Master SPI initialized\n");
}

int32_t cc_spi_read(uint8_t *buff, uint32_t len)
{
/* Assert CS */
GPIO_write(CC3235SF_GPIO_OV_SPI_CS,0);

transaction.count = len;
transaction.txBuf = NULL;
transaction.rxBuf = (void *) buff;
SPI_transfer(masterSpi, &transaction);

/* Deassert CS */
GPIO_write(CC3235SF_GPIO_OV_SPI_CS,1);

return len;
}

  • Hello,

    Missed attaching expected SPI read buffer and actual read SPI buffer

    Actual SPI Read buffer (incorrrect):

    0x30 0x03 0x33 0xC0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x000x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    Expected SPI Read buffer(Coorect and visible on Wire):

    0x44 0x41 0x45 0x48 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x000x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

  • I have one more sample of incorrect read. If this could help. Does it have something to do with polarity or phase?

    Actual SPI Read buffer (incorrrect):

    0x03 0xFF 0xFF 0xFF 0x0C 0x3F 0x00 0x00 0x00 0x00 0x00 0xC3 0x00 0x00 0x00 0x00 0x00 0x00 0xF3 0x00 0x00
    0x00 0x03 0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x00 0x00

    Expected SPI Read buffer(Coorect and visible on Wire):

    0x01 0xFF 0xFF 0xFF 0x02 0x17 0x00 0xA0 0x00 0x00 0x40 0x39 0x00 0x00 0x00 0x10 0x00 0x00 0x1D 0x00 0x00

    0x00 0x01 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 

  • Jitendra,

    What device are you interfacing with?

    How are you seeing this garbage data? For example, are you outputting it over serial?

    BR,

    Seong

  • Hello,

    The device is a video encoder slave similar to video reference design.

    The data is copied from the memory view of the debugger.

    Surprisingly sometimes the data is captured perfectly and it continues working unless I reset the MCU.

    The logic analyzer screenshots are captured at launchpad pins.

    Can you suggest a time when I can get a prompt response? So that I can do any test promptly?

    Regards

  • Hi,

    When you say that the data is captured perfectly during a specific test run, is this the case indefinitely or does it eventually stop working during the same run?

    Also, are you running this on your own custom board or are you running this on a launchpad?

    Have you tried running running at a SPI clock rate less than 20MHz, and seeing if it reduces the incidence of this issue?

    How are you performing a reset of your board? Is this through toggling the nRESET line, or are you using some other reset method between test runs?

    Regards,

    Michael

  • When you say that the data is captured perfectly during a specific test run, is this the case indefinitely or does it eventually stop working during the same run?

    If it works, It continues working perfectly.

    Also, are you running this on your own custom board or are you running this on a launchpad?

    Launchpad is connected with custom board via jumpers. If you want more details i can share it via email.

    Have you tried running running at a SPI clock rate less than 20MHz, and seeing if it reduces the incidence of this issue?

    I tried with clock down to 2Mhz exactly sam behaviour.

    How are you performing a reset of your board? Is this through toggling the nRESET line, or are you using some other reset method between test runs?

    I have tried nRESET and power cycle both.

  • Hi,

    To clarify, do you have a CC3235 launchpad acting as a SPI master, that's providing data to a non-CC32XX device on your custom board that's acting as a SPI slave?

    With the jumpers between the CC3235 and your other device, have you ensured that you have kept the jumper lengths to a minimum? Maybe the SPI clock signal is being affected by your jumpers, causing incorrect data to be read. Do you have a scope capture of the SPI clock signal and checked it to ensure that the clock meets the timing parameters for the CC3235 SPI peripheral mentioned in the datasheet?

    During your test, are you opening and closing the SPI interface of the CC3235 repeatedly? Perhaps you can try adding a MAP_PRCMPeripheralReset(PRCM_GSPI) call in SPICC32XXDMA_open() of SPICC32XXDMA.c. I would put it immediately before the initHw() call of that function. That function will guarantee that the SPI peripheral of the CC3235 gets reset to a known-good state.

    Regards,

    Michael

  • Hi,

    I assume that you have resolved your issue since I have not heard back from you. If not, feel free to post a response to this thread, or open a new thread regarding this issue.

    Regards,
    Michael

  • Hello Michael,

    Please close the ticket.

    The trouble was because of another slave device on the SPI bus.