Methods for troubleshooting an SPI connection?

Short story, I am trying to read data from a sensor over SPI and am reading 255 from every byte on a custom "development board" - am I correct in assuming the SPI communication is at least somewhat functional to receive anything at all?

Long story:

I have developed a custom sensor board using an STM32 F103C8T6, with Honeywell HSC Series Differential pressure sensors. The whole thing was successfully breadboarded using a "Blue pill", a dev board with the exact same processor - I even used the blue pill schematic while designing my board, so they have many of the exact same components etc. The SPI communication worked fine on the breadboard, but does not on the custom board. All the pins/assignments are exactly the same between boards. Every byte received from the sensors is 255 - I've tested a few things like removing the SCLK and MISO lines, which makes the received bytes 0 instead - hence my assumption that something is happening within the spi communication, just not correctly.

For reference, here is the code that receives info from the sensors - I don't think it's a code issue though, since it worked fine on the dev board. The STM32 itself seems to be running fine otherwise, I can make pins go high/low successfully etc.

uint8_t count = 4; // transfer 4 bytes (the last two are only used by some sensors)
  memset(_buf, 0x00, count); // probably not necessary, sensor is half-duplex
  SPI.beginTransaction(SPISettings(800000, MSBFIRST, SPI_MODE0));
  digitalWrite(SSPin, LOW);
  SPI.transfer(_buf, count);
  digitalWrite(SSPin, HIGH);
  SPI.endTransaction();

Is there anything else crucial I'm missing? Aside from a logic analyser, is there any way to debug the spi communication further?

sakza: The SPI communication worked fine on the breadboard, but does not on the custom board. All the pins/assignments are exactly the same between boards.

Which is a very strong indication that there is a problem with the custom board.

Is there anything else crucial I'm missing? Aside from a logic analyser, is there any way to debug the spi communication further?

An oscilloscope ?

I have found logic analyzers like this to be useful along with the Pulseview software.

srnet:
Which is a very strong indication that there is a problem with the custom board.

That’s the conclusion that I’ve come to as well. I’m not necessarily hoping to miraculously get this board working, but hoping to figure out what the issue is at least before the next revision. I don’t have an oscilloscope, but I would be able to get my hand on one for a few tests, what would I be looking for?

groundFungus: I have found logic analyzers like this to be useful along with the Pulseview software.

That looks really handy, I haven't seen anything that compact before. Definitely looks worth an investment

sakza: That's the conclusion that I've come to as well. I'm not necessarily hoping to miraculously get this board working, but hoping to figure out what the issue is at least before the next revision. I don't have an oscilloscope, but I would be able to get my hand on one for a few tests, what would I be looking for?

You have a working setup and a not working setup.

So compare the SPI signals, do they look the same ?

srnet: You have a working setup and a not working setup.

So compare the SPI signals, do they look the same ?

Super weird conclusion, the working and non working SPI interfaces were indistinguishable. I ended up replacing the stm32 chip itself and it's now working. Despite the clock working and data being transferred, I guess something internally in the stm wasn't quite right. Weird issue, but solved!