Need help to solve a problem with SPI bus of the NUCLEO144-H743Z2

[Mick P. F.]

Hello,

I have a problem with the SPI protocol (NUCLEO144-STM32H743Z2 board) in a very specific case.

The MCU first sends a byte array as a command to the device on the PIS bus, this device interprets the sequence and, depending on the content of the command received, also sends back a byte array of different lengths as a response.

I have the source code of this device. It actually only sends a response after it has completely received and interpreted the command from the MCU.

At first I noticed that when communicating with the setting "Hardware NSS Signal: Hardware NSS Output Signal" (see "SPI-Settings_with_Hard_CS.png" and "SPI-Settings_GPIO_Hard_CS.png") a nonsense comes back as a response (probably some bits go lost), and only with the setting "Hardware NSS Signal: Disable" (see "SPI-Settings_with_Soft_CS.png" and "GPIO-Settings_for_Soft_CS.png") and under the control of the "/CS" by software the answer comes back undistorted.

I expected the response to arrive at the MCU with a delay so that I can use the "HAL_SPI_Transmit" and "HAL_SPI_Receive" commands so that communication takes place correctly. But it doesn't work. The logic analyzer shows me that the response on the MCU comes back at the same time as the command is sent. In fact, it's completely impossible. This contradicts the principle “First the action, then the reaction�?!

Have I set something wrong in STM32CubeMX?

In the “SPI Settings" there is the field “NSSP�?, the meaning of which I am not familiar with.

It is also not clear to me whether I should change the field "Master Keep io State" or not.

These fields are not mentioned in the “UM1718�? manual. Some time ago I have downloaded all the manuals available on the Internet, but I don't know which one to look up.

Can you help me to solve this problem please?

Thanks in advance,

Michael

[TDK]

There doesn't appear to be anything wrong with your CubeMX setup, and your logic analyzer plots look good, as long as you're controlling CS manually.

The slave can't respond to something you haven't yet sent. There's no context here as to how you expect the slave to be behaving vs how it's actually behaving. I would look into that.

HAL_SPI_Receive can output extra clocks, I would recommend using HAL_SPI_TransmitReceive for all communication since you have both MOSI and MISO pins assigned.

[Mick P. F.]

Hello,

That is not the problem!

The use of the "HAL_SPI_TransmitReceive" call does not seem to me to be the solution and/or seems to be nonsensical, because the MCU can't recognize how many bytes are in the response. The argument "Size" to this call (similar to "HAL_SPI_Transmit") contains the number of bytes to send and it does not "know" how many bytes will arrive. it also does not "say" how many bytes it read! it could be less or more than it sent!

I know exactly what the device is doing at the other end of the bus and how it behaves. It receives a complete and correct message from the MCU, because I recognize the complete command and what the device is sending back in the response and they are correct, but the response appears incomplete in the picture "SPI-Protocol_with_Soft_CS.png" because it is longer that the array sent. The MCU must first receive and interpret the first three (or four bytes) of the response before it knows whether and how many blocks will follow! Some (empty) responses are three bytes long! Each block begins with a byte that contains the block length.

Therefore, after the first 4 bytes of the response, the MCU must receive/read alternately individual bytes and blocks!

As I already said, the principle "The Cause and the Effect" is the most elementary principle of physics and cannot be violated. I am still of the opinion that something is going wrong here, maybe something is being buffered? In any case, the response is only sent after receiving the command and not at the same time! The behavior of the interface seen in the picture "SPI-Protocol_with_Soft_CS.png" completely confuses me!

I would still be interested in what "NSSP" means. During my research, I only found one document that is written in Japanese or Chinese, which I do not understand!

Kind Regards,

Michael

[MasterT]

Regarding NSSP look into RM0433 Reference manual.

Troubleshooting communication link, I'd start with peripheral devise not connected, MISO-MOSI jumped (loopback) to see if SPI reads what it sends correctly. TransmitReceive mode of course.

[TDK]

> it also does not "say" how many bytes it read! it could be less or more than it sent!

SPI in master mode sends exactly as many bytes as it wants. It receives the same number of bytes that it sends. It's not like UART where they are independent lines. For every byte sent on MOSI, one is received on MISO. You can choose to ignore received bytes as you wish, but they are still on the line.

If you need to read 4 bytes to interpret how many additional bytes to send/receive, then do that. What is stopping you?

[Mick P. F.]

In any case, this strange behavior on the SPI bus makes programming considerably more complicated!

But it's nothing that I can't handle.

My only regret is that I cannot get a plausible explanation for this bus behavior in order to work out a short and more logical software solution.

[Mick P. F.]

I "flown" through the document "RM0433", chapter "50 Serial peripheral interface (SPI)", the term "NSSP" is not mentioned there at all and certainly not explained, unless it is referred to there differently and therefore not immediately recognizable!

it is also somewhat unsatisfactory.

[Mick P. F.]

I also just realized that a byte is missing between the fourth received byte "06" and the following byte "2E".

And that is (please forgive me) absolute ********.

[Mick P. F.]

The internet censorship sends its regards ...

[MasterT]

Right.

"Additionally, bit SSOM=1 setting invokes specific mode which interleaves pulses between

data frames if there is a sufficient space to provide them (MIDI[3:0] has to be set greater

then one SPI period). Some configuration examples are shown at Figure 618: SS

interleaving pulses between data (SSOE=1, SSOM=1,SSM=0).

2174/3289 RM0433 Rev 6"

This pulse makes sense for continuous data transfer, nice feature to have, otherwise SS stays low all the time and doesn't mark frame.

I use it to interface mcp3561R.

Parameter that defines pulse width:  hspi2.Init.MasterInterDataIdleness   = SPI_MASTER_INTERDATA_IDLENESS_02CYCLE;