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

[Mick P. F.]

Thank you for your explanation, Master T.

I'll see if I can do something with it.

In the meantime I have noticed that even more garbage is created if I leave the "/ CS" signal in the "Low" state for the entire time a command is processed (sending and receiving)!

It's really absolute big "b...s..."...

This problem is something I didn't expect.