STM32H743 SPI4 MISO pin not receiving data

[GreenGuy]

INFO:

STM32H743XIHx

STM32Cube FW_H7 V1.11.2

STM32CubeIDE Version: 1.14.1 - (have not updated to 1.15 due to being mid-project)

STM32CubeMX - Version: 6.10.0-RC9

SPI4 configuration:

I have verified the following:

1) The NSS, SCLK, MOSI, and MISO lines all have the correct levels at the correct time communicating to a MX9050 EEPROM device attempting to read the status byte. The MOSI line contains 0x05 and the MISO line contains 0xF0 in response as read using a O'scope.

2) The data received using the line:

Inst->status = HAL_SPI_TransmitReceive_IT(hspi, &TxBuf, &RxBuf, 2);

is all 0.

3) I have verified the trace going to PE5 (SPI4_MISO) (D1 - TFBGA240+25), as probed on the same side of the board that the STM32H743 is mounted, also shows the same MISO signal that appears on the connector going to the EEPROM device. The signal levels are good ruling out a poor solder joint.

4) I have tried setting the MISO line as pulled-up and pulled-down and can verify that when SPI4 is not being used, the trace on the same side of the board as the STM32H743 measures high when pulled-up and low when pulled-down.

5) I have verified that when the MISO line is pulled-up, the data received is still all 0.

6) Am not using DMA, and normally using D-Cache with proper cache handling. Turn D-Cache off does not change the received data.

7) I am using SPI1, SPI2 in Master full duplex to communicate with external DAC/ADC's and SPI5 to communicated with an FPGA. This all works with and without DMA fine.

The only conclusion I can come up with at this time given the steps taken thus far is that the data on SPI4 MISO pin is not finding it way from the fifo to memory and neither DMA nor Cache is the issue. I have also check the Errata for the STM32H7 and there is nothing indicated there that SPI4 has a related problem.

SPI connection to the EEPROM is critical to the design and SPI4 is the only spi resource left. This needs to work!

[Pavel A.]

Have you checked levels of other pins of the MX9050? Does it get proper power? Is the HOLD pin in wrong state?

[GreenGuy]

Sorry I left that out of the original post.  

/HOLD and /WRITE are tied high (to VCC).

[GreenGuy]

Also if HOLD was enabled, it think the read status command would not respond with 0xF0 as it is presently doing.  What I have done to this point has all been prior to using the EEPROM for anything else, like a hand shake to make sure the EEPROM is present and talking.  Like I said before, the data is coming back from the EEPROM on MISO and is present on the MCU pin for MISO in the correct phase.  It is just not showing up in the buffer.

[GreenGuy]

I checked the SPI4 RXDR and it contains the data the scope shows on the MISO line.  This data is not making it to the buffer pointed to in the HAL_SPI_TransmitReceive call.

[GreenGuy]

As an experiment, I made a read of the RXDR after the HAL_SPI_TransmitReceive_IT call like this:

uint32_t rxdr = Inst->hspi->Instance->RXDR; (note the value of the RXDR register is 0x000000000000F)

and noticed that the RXDR, clears when read, and the value of rxdr is 0. 

So assuming that if the value in the RXDR register is my data and the register clears when the data is transferred, then I must conclude that the process of transferring the data to the receive buffer is not occurring, otherwise, I would expect the value in the RXDR register to be 0 after the HAL call.

The process I use for SPI transfers is the same for SPI1, SPI2, and SPI4 and the set-up is the same except the SPI4 is setup as 8bit while the others are 16.

I am beginning to think this is a bug in the silicon unless I have missed something.

The marking on the STM32H743XIH6 I have is:

7BA6N  92  VQ   V

PHL 7B  2  26

[GreenGuy]

Further investigation:  I cannot use the instance to see the Special Register for SPI4->RXDR.  It shows 0 while the SFR's tab in the debugger shows:

So there is a disconnect there and I am not sure how the Instance structure gets updated.

[Pavel A.]

Do you really keep the registers opened in the viewer while debugging the SPI?  http://efton.sk/STM32/gotcha/g4.html

[GreenGuy]

No.  I only view it when stopped and then close it.

And as far as the SFR's  I only view after the transfer on the second pass to verify the the FIFO is receiving the data.

[GreenGuy]

Sure would like to know why when accessing the RXDR register via the hspi->Instance, the data contained after the HAL_TransmitReceive call goes from 000000000000000f to 0 and the value returned is 0?

Spent most of the day going over RM0433 with a fine tooth comb and find nothing that would solve the current behavior.