SPI-Slave - data corruption using Full Duplex communication

[rmalhotra9]

Posted on December 30, 2009 at 11:56

SPI-Slave - data corruption using Full Duplex communication

[rmalhotra9]

Posted on May 17, 2011 at 13:35

Hi,

I’m trying to use the SPI1 on STM32F103RBT6 device and have some issues. The SPI1 is configured as a slave in full duplex mode and the NSS is controlled by the Master which is another ARM processor. In the test that is implemented, the master transmits 0XAA and expects a certain data back from the STM32. The issue I see is that so long as no data is loaded by the STM32 on the Tx buffer, it receives correct data from the master. As soon as the Tx buffer is loaded with a relevant data, the output as well as the rec’d data gets corrupted. What is strange is that it is always the lower nibble getting corrupted. It seems like some sort of timing problem where the data is getting loaded to the SPI_DR before the complete byte has been received. Has anyone seen a similar issue? Any assistance would be much appreciated. The source code is attached. Thanks. regards, rsm

[rmalhotra9]

Posted on May 17, 2011 at 13:35

Hi,

This is a follow up to my previous posting. I took some measurements on the Scope to understand how the bits are being shifted out on the MISO pin when the STM32 SPI is configured as a Slave in Full Duplex Mode. I found a few issues which I would like to report: 1. The Diagram indicated in fig 211 of RM00008 seems to be incorrect for the MISO pin wrt to CPOL. In fact when CPOL = 0, the data is shifted out on the falling edge and when CPOL = 1, the data is shifted out on the rising edge. Please see the attached pdf for the waveforms. 2. The data shifted out is 0x80 instead of 0x84 even though the transmit buffer of the SPI_DR is loaded with 0x84. The data rec'd in the receive buffer of SPI_DR is in-correct. Instead of 0XAA the data rec'd is 0XAD. To ensure that the data is written only once the Transmit buffer is empty and the Busy Bit is not set, the following code is used in the Interrupt Service Routine: void SPI1_IRQHandler(void) { u8 temp1; if(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == SET) { temp1 = SPI_I2S_ReceiveData(SPI1); readData[rxCounter++] = temp1; } temp1=0x84; if(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == SET) { if(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == RESET) { SPI_I2S_SendData(SPI1, temp1); } } } 3. For the same test setup, same code on the STM32, if the MISO pin is disabled by configuring the MISO pin as GPIO pin instead of a SPI pin, the data rec'd in the SPI_DR is correct in all instances. 4. If the code is modified, so that 0x00 is transmitted on the MISO pin of the STM32, the data rec'd in the Rx buffer of the SPI_DR does not get corrupted. From #2, #3, #4, it seems if in Full Duplex Mode, if a non-zero value is loaded to the Transmit Buffer of the SPI_DR by the STM32, the data received in the Receive Buffer of the SPI_DR seems to get corrupted. Also what has been observed is that in most instances it is lower nibble that is corrupted. The sample code for the above test is attached for those interested in replicating the issue. The device I'm using is STM32F103RBT6 and the development platform is the Olimex Dev Board. The tool chain is from IAR Version 5.40. The SPI1 is used on the above device. Can anyone from ST or any other member comment on this issue? Is there a bug which I should be aware of? Thanks. rsmnull

[jj]

Posted on May 17, 2011 at 13:35

You've constructed an excellent post - detailed, methodical - Bravo.

Can you replicate this issue on a 2nd (or better still several) other boards? (strength in numbers) What happens if you break the connection between ''Slave Out'' and outside world? Is there any chance this signal is ''feeding back'' somehow? What happens if you substantially reduce SPI rate?

[rmalhotra9]

Posted on May 17, 2011 at 13:35

Hi JJ,

Thanks for the response. Please see the response to some of the questions: 1. Can you replicate this issue on a 2nd (or better still several) other boards? (strength in numbers) [RSM] We are expecting some new hw next week - we shall test it on them. We might even look to populate a different device on one of the boards and see if this issue is specific to a particular STM32 device. The device that we are using is in a LQFP64 package. 2. What happens if you break the connection between ''Slave Out'' and outside world? Is there any chance this signal is ''feeding back'' somehow? [RSM] Our initial thoughts were also that - and we thought that there was a shot or some sort of cross talk. We broke the connection between the ''Slave out'' and the outside world - the results were identical. We also measured the rail voltages on the device - it is rock steady at 3.3V. Lastly we tried the same test on SPI2 - the results are identical suggesting that there is some issue internally. 3. What happens if you substantially reduce SPI rate? [RSM] The last set of waveforms are extremely reduced rate (clock is approx 2mS ton, 2ms toff). The signals from the host are actually generated for the CS, MOSI and CLK using GPIO Bit Banging and we also have a mechanism to single step through the code i.e. Generate one clock pulse, see the values on the MOSI, MISO etc on the scope. The results of this were compared with SPI running at clock speeds of 3KHz, 590 KHz and 1.3 MHz. The results are identical. thanks. -rsm

[jj]

Posted on May 17, 2011 at 13:35

Hi RSM-

You've covered the bases - smells now very much like a ''bug'' to this reporter. (but it is important that this behavior persists across several boards!) Sure you've done so - check errata for your exact MCU (and replacement candidates) just in case. Please do report your ''additional boards'' test.

[friquero]

Posted on April 11, 2013 at 00:47I would like to know if this post had a resolution because I'm working with two STM32L151 communicating them via SPI port and I'm having a similar problem. I only can receive data correctly if I switch off transmission. When I want full duplex in master and in slave. I can't also make the examples work. Can anybody help me ?? 

[friquero]

Posted on April 11, 2013 at 01:53

I have attach the source code if someone wants to have a look. I have try interrupts, dma or polling. I always have the same result. I can't get reception if transmission is on. (Slave mode)

________________ Attachments : spi_source_code.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0PO&d=%2Fa%2F0X0000000bgD%2FiV5C_gXtIUGmjrMr3SkFva8iDM2j5wkD9Gfuv4ybJEI&asPdf=false