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.

IWR6843: SPI Master still gets data after Slave was turned off

Part Number: IWR6843

I connected 2 IWR6843 EVM via SPI. My Master can receive data from Slave after SPI_transfer. But after I turned off power to the Slave, Master still not get 0 value. Besides, in Slave code, I set data sent out to 5, but Master always get 65535. Why? How to make Master get correct data from Slave?

Here's my Slave code to send data to Master

    pTestMsgOut = (spiDataMsg*)&txBuf[0];
    memset(pTestMsgOut, 0, 128);
	pTestMsgOut->msgId = 5;
	pTestMsgOut->dataLen = sizeof(MmwDemo_output_message_header);
	pTestMsgOut->seqNo   = 5;
	for (i=0; i < sizeof(MmwDemo_output_message_header)/2;i++)
	{
		uint16_t *buf = (uint16_t *)&header;
 		pTestMsgOut->data[i] = buf[i];
	}

    spi_Write (spiHandle, (uint8_t*)pTestMsgOut, SPI_DATA_BLOCK_SIZE);

Here's my Master code to receive data

while(1)
{
spi_Read(handle, SPI_TEST_MSGLEN, (void *)rxBuf);
spiMsg = (spiDataMsg *)&rxBuf[0];

/* Start Data Transfer */
if (spi_Read(handle, SPI_TEST_MSGLEN, (void *)rxBuf) == 0)
{
System_printf("SPI transfer OK\n");
System_printf("Header %d, Seq %d\n", spiMsg->msgId, spiMsg->seqNo);

}
else
{
System_printf("Unsuccessful SPI transfer");
}
}

SPI transfer OK
Header 65535, Seq 65535
SPI transfer OK
Header 65535, Seq 65535
SPI transfer OK
Header 65535, Seq 65535
SPI transfer OK
Header 65535, Seq 65535
SPI transfer OK
Header 65535, Seq 65535
SPI transfer OK
Header 65535, Seq 65535
SPI transfer OK

.....

As u can see, spiMsg->msgId and spiMsg->seqNo received on Master are always 65525. I don't see its value as 5 even though I set spiMsg->msgId = 5 in Slave code. It seems that Master read size of int type instead of data.

  • Hi Hector,

    Seems like two devices are not able to communicate. Could you please verify your setup by connecting logic analyzer to slave device and see if you are able to receive data on logic analyzer.

    Thanks

    Yogesh

  • Hector,

    Please consult the SPI driver documentation and example code for the mode you wish to use.  If the mode is supported, use the example code in that mode.

      -dave

  • Dave,

    I used your sample code last time. You said you tested successfully. Your test code is Slave mode, demo code is Master, but Slave was stuck after SPI_open. You said Slave waits for Cfg from Master, but I sent Cfg and Slave was still stuck, SPI_transfer was not executed.

    Therefore, I modified your test code to be Master and demo code as Slave. Then I can see SPI_transfer works on test code, but always receive 65525 as above.

  • Hi Yogesh,

    I don't have a logic analyzer now. But I've just deleted UART_init_params for Logging UART Instance, then I realized that after this modification, I turned off Slave device, header and Seq turned down to 0 once. Previously, it always was 65535. It means SPI Slave is still working. Otherwise, those value will never changed after I turned off Slave.

    So UART logging setting might affect SPI in this case. But I don't know why data was only down to 0 once then turned back to 65535 again. 

    I tried to add memset(rxBuf, sizeof(rxBuf), 0) to see whether data remain 0 after powered off, but it didn't help. Currently, I'm pretty sure my Master & Slave communicate successfully, just don't know why data only down to 0 for one loop after turned off Slave, then Master data reading turn back to 65535. Can u explain and add some code to my version?

    Header 65535, Seq 65535
    SPI transfer OK
    Header 65535, Seq 65535
    SPI transfer OK 
    Header 0, Seq 0 // This is when I turned off Slave. those data are 0 for one loop
    SPI transfer OK
    Header 65535, Seq 65535 // why data not remain 0 in next loop?

  • Hector,

    As I have said, the code has been tested, and it has been successfully used by other customers.  You do not need to change who writes and who reads on master and slave.  You should go back to the original code, and focus on what the master is sending. You will need something to verify this output - an oscilloscope, an SPI protocol analyzer, or a known good SPI slave device.  I have given you all the information with respect to connecting the devices and debugging that I can think of in the other thread(s). 

      -dave