I'm using SPI to communicate with a MIPI chip, the commands to the MIPI are sent as 9 bits but the data sent back is 8 bits.

[WScot.1]

I'm using SPI to communicate with a MIPI chip, the commands to the MIPI are sent as 9 bits but the data sent back is 8 bits. The 9 bit are set up in a uint16_t variable. Using HAL_SPI_Init the data size is set to 9 bits. When I receive the data using HAL_SPI_Receive the 8 bit data is shifted 1 place to the left as it is getting clocked by 9 bits. Is there a way to correct this?

Thanks, Will.

[waclawek.jan]

Which STM32?

Post waveforms captured by logic analyzer and read out content of the SPI registers.

JW

[WScot.1]

Hi JW, thanks for your reply. I'm using an stm32F769 processor. The HAL_SPI_Receive data and clock waveforms are shown below:

The SPI is set initialised as:

SPI registers:-After the 1st HAL_SPI_Receive()

After the 2nd HAL_SPI_Receive()The data I'm expecting to see for each 8 bit read is 0x28. The data I receive in rxData16[] is rxData16[0]=0x50 and rxData16[1]=0xA0 which appears to be 0x28 shifted to the left and shifted to the left twice for the second data read. Looking at the SPI DR register, I only see 0x50 appear after the second call to HAL_SPI_Receive().

Thanks, Will.

[waclawek.jan]

This is salesforce, an extensive garbage ST uses instead of proper forum software. Your pictures were not inserted even if they appeared so. Please use the "image" icon on the bottom of the editor window to insert pictures.

JW

[WScot.1]

Thanks, I'll try again.

The HAL_SPI_Receive data and clock waveforms are shown below:

SPI initialisation:

SPI registers:

First HAL_SPI_Receive

Second HAL_SPI_Receive

 

Thanks, Will.

[waclawek.jan]

OK but the SPI received exactly what you've shown... The SPI module has no way of knowing that the slave is transmitting 8 bits - you've set it to 9 bits. Tx and Rx in SPI can't be decoupled, it happens along the same number of clocks.

I don't know what is the slave chip you are talking about, but it's highly unusual that a SPI slave would expect to receive a different number of bits within one frame than it transmits. If this is indeed the case here, you have to take this into account and "manually" merge the 9-but received frames and then split them to 8-bit pieces.

JW

[WScot.1]

Hi JW,

Thanks for clearing this up, it's what I suspected, but it's nice to get confirmation.

Thanks again, Will.