cancel
Showing results for 
Search instead for 
Did you mean: 

SPI always returns 0xFF

rohan_m
Senior

So we have a custom board from which we want to read a pressure sensor slave information via SPI.

And a similar exercise we have done with the NUCLEO board as well. NUCLEO756Z.

On the Nucleo the code run for a short while and then after half an hour it just starts returning 0xFF and also after reprogramming the device just get the same outputs.

So in all the code works perfectly for half an hour and then kaput. 

I cant seem to understand what the problem is here since we are just sending 2 bytes and receiving 22 bytes nothing more complicated than that. I am scratching my head for over a week but cant get around this issue. Has anyone encountered such an issue. 

I have also tried separate HAL receive transmits but to no avail after that. 

 

HAL_GPIO_WritePin (CS_ND210_GPIO_Port, CS_ND210_Pin, GPIO_PIN_RESET);

SPI_RES = HAL_SPI_Transmit (&hspi5, sent, 2, 100);

SPI_RES = HAL_SPI_Receive (&hspi5, recv[2], 20, 100);

HAL_Delay(1);

HAL_GPIO_WritePin (CS_ND210_GPIO_Port, CS_ND210_Pin, GPIO_PIN_SET);

HAL_Delay(5);

 

 

7 REPLIES 7
Danish1
Lead II

I suppose my first thought would be to try to understand if the problem were software or hardware.

Do you have access to an oscilloscope?

If so, try to see what is happening on the MOSI, SCL and MISO pins during the time that SSEL is low. Are you getting 20 bytes of credible data on the MISO back from your sensor?

----

Looking at your code, I suspect your line

SPI_RES = HAL_SPI_Receive (&hspi5, recv[2], 20, 100);

might contain an error. What is recv? Why are you accessing the third entry in it?

If it is declared as e.g. unsigned char recv[100]

Then if you want the received data to come back starting at the third character, you need to take the address of that i.e. SPI_RES = HAL_SPI_Receive (&hspi5, &recv[2], 20, 100);

rohan_m
Senior

rohan_m_0-1710758915845.jpeg

Also I dont know why is the voltage levels of the clock seen as 30V ?

I am not even supplying the same

Yeah even after that it is the same problem. That was just a typo I corrected it before hand as well. Thanks for answering. But that was not the solution.

LCE
Principal

If you don't tell us which SPI signals we see, the picture doesn't help much.

30V: scope thinks probe is set to 10:1, but probe is set to 1:1.

PS: and see what Danish1 said above

Yeah my bad but a very queer thing happened. I am getting 0xFFs on the SPI5, SPI4, SPI3 but when I connected the sensor to SPI1 the code worked without change in any logic just the name of the SPI. That I dont seem to understand. Atleast the sensor is responding. This happened on a NUCLEO.

Also the the same is happening on a custom board as well. Cant understand this occurence.

Can anyone point me to the pertinent registers to look at which can help in the debugging.

LCE
Principal

I would check all relevant SPI control and flag / status registers, always keeping an eye on the scope.

Maybe there's some super simple bug involved, something like the SPI handle hspi is tied to the wrong instance.