2020-06-20 03:40 AM
Good morning
Seems I come a little further with my GPIB Nucleo-F207ZG project where ports stopped responding...
The initialization for the SPI1 looks like:
hspi1.Instance = SPI1;
hspi1.Init.Mode = SPI_MODE_MASTER;
hspi1.Init.Direction = SPI_DIRECTION_2LINES_RXONLY;
hspi1.Init.DataSize = SPI_DATASIZE_16BIT;
hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
hspi1.Init.CLKPhase = SPI_PHASE_1EDGE;
hspi1.Init.NSS = SPI_NSS_SOFT;
hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_32;
hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
hspi1.Init.CRCPolynomial = 10;
So I can read out an attached MAX31855 ADC like:
uint16_t tempdata[2];
HAL_SPI_Receive(&hspi1, tempdata, 2, 1000);
The first time I call HAL_SPI_Receive() I see on my scope that it sends out 48 clock cycles...
but the temperature is returned fine from MXA31855...which is 0x01A0 for example...stripping of the last bits gets me the celsius degrees...so 0x01A0 << 4 = 26 degrees...
On the next read SPI1 sends 32 clock cycles...and I see that the returned data from MAX31855 is correct....but the function returns always 0x0000.
On subsequent calls to HAL_SPI_Receive() I receive then 0x1B50...so somehow the returned data seems to be shifted.....
So only the first call sends back correct data from SPI1...
Any ideas what is going wrong here?
thanks in advance
richard
2020-06-20 05:41 AM
I don't use nor understand Cube/HAL, but if HAL_SPI_Receive() uses the Rx-Only mode of SPI, avoid using it and use normal duplex SPI. The reason is, that Rx-Only mode runs the clock continuously and it's relatively hard to stop it in time. You don't need to assign any pin to MOSI in GPIO.
https://community.st.com/s/question/0D53W00000A1NbSSAV/problem-with-spi-clock-ticks
JW
2020-06-20 05:47 AM
Interestingly I never had problems on the Nucleo-F070 board with the same code...but already switched to full duplex....and IIRC ialways 48 clock cycles were sent in receive-only mode..
The question is...why after reset it works as it should (48 clocks) and afterwards uses always 32 clocks...so no free running here...I assume HAL_SPI_Receive behaves differently after reset and after first call of it...
Problem was also that the additional clocks have overwritten some RAM past the allocated buffer..although 2 * 16bit were specified in the call...
2020-06-20 07:48 AM
> I assume HAL_SPI_Receive behaves differently
No need to assume. Cube/HAL is open source, so you can observe/debug it exactly as your own code.
Or avoid it and write your own code.
JW