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.

[tjaekel]

Disconnect the external chip and use a flying wire to connect MISO with MOSI (on MCU):
You should receive what you send.

If this fails: the MISO pin is not properly configured (a wrong pin used, a wrong ALT, ...).

This MOSI - MISO "short cut" should work before you try with an external chip connected.

Other reasons why it can fail:

• SPI mode is wrong (OK, you say it makes sense on scope)
• LSB vs. MSB is wrong (the external chip would not understand the command and might not respond)
• CS/NSS : low or high active? Most chips want to see CS going low on a new transaction, but also seen
  high active CS.
• SPI bitrate too fast (external chip gets bit errors)
• time between CS goes active (low) and first clock edge is too fast (external chip has a timing constraint),
  there is a config to increase the "gap"
• the cable is too long
• there is ringing on the SPI signals (not a correct impedance match, e.g. not using "serial termination")
• The VDD of MCU and external chip are different (e.g. MCU runs 3V3 but external chip uses 1V8, so that
  level shifters are needed)
• Sometimes, pull-ups are needed:
  a) if CS becomes floating - all is messed up
  b) if SCLK becomes floating - often the MCU SPI will release the bus - it takes time before SCLK has a
      "correct" level, when MCU starts driving again, but CS comes fast and cable is long

Check with a scope if the signals look correct, esp. the signal levels, signal integrity, ringing, setup and hold times...

[GreenGuy]

I removed the EEPROM part from the board and shorted MOSI to MISO.  The data sent was not returned.  The data returned was 0.

 

Here is the scope shot with the EEPROM mounted as probed at the EEPROM.

I have verified that the MISO from the MCU to the EEPROM has good connectivity by configuring the MISO line in the MCU code with a pull-up and with a pull-down (2 different cases) and while the SPI4 is idle measure the MISO line at the EEPROM.  The measurement shows HIGH pulled-up case and LOW in the pulled-down case.  After removing the EEPROM and shorting the MOSI to MISO at the EEPROM location.  I repeated the the same cases and noted that inspecting the GPIOE, pins 5&6 show HIGH when pulled up and LOW when pulled down.

The connection is good.

I am certain at this point the the MCU SPI4 is broken!  Guess I will have to disable SPI4 and bit bang the EERPOM.  

[AScha.3]

(Just : i use the spi4 on H743VI , in 8 bit slave mode at about 24Mbit ; no problems so far .)

What i not understand:

you state : SPI4 is setup as 8bit .

but on top you show: 16b

What now ?

+

in timing diagram i see clk + data send on mosi ;

so what coming on miso then ? (and dont forget, you read from a fifo, not a static register. This works only 1x , then data away. -> 0x0. )

+

why you write: RXDR register is 0x000000000000F -

but RXDR is 32b , 0x00000000 ->

 

[GreenGuy]

So in your first trial, SPI4 MISO was set to PE13 and the received data was 0 regardless of the transmit data.

And in the second trial, SPI4 MISO was set to PE5 and the received data matched the transmitted data.

Do I have that correct?

Interesting, because In my design, I have SPI4 MISO set to PE5 since PE13 is being used by FMC.

 

[AScha.3]

Right, on PE5 miso gets input from pin, read data ok then.

So you can try remap on other pin - in your case ? (in my 144pin only PE5/13 possible)

+

check while debug, whats in SFR for GPIO port PE -> pin5 : should be 5 (=AF5)

[GreenGuy]

I am using TFBGA240+25, but as I posted the PE13 pin is being used by the FMC for D10 and I need the SDRAM.

I can confirm for me the after SPI4_Init the PE alternate for AF5 = 0x5.

 

 

 

 

[hardrock]

Please see the source code below.

uint8_t readStatusRegister()
{
 uint8_t TxBuf[2];
 uint8_t RxBuf[2];
 
 TxBuf[0] = 0x05; // RDSR Instruction
 TxBuf[1] = 0x00; // dummy
 HAL_SPI_TransmitReceive_IT(&hspi4, TxBuf, RxBuf, 2);
 
 // RxBuf[0] = 0x00; //dummy
 // RxBuf[1] = 0x02;
 return RxBuf[1];
}

 

[GreenGuy]

Yes this is appropriate for the M95010-W EEPROM and is precisely how I applied it.

However, in my case the Data from the status register while visible on the scope did show up in RxBuff[1], but rather 0x00.  You may need to back track through the post to find the scope shot.  At least I hope it is still there.

[David Littell]

My apologies for coming into this late - been distracted with someone arguing that BOOT0 doesn't need an external pulldown, hahaha!  I may have missed some things in my first read-through.

Is it feasible to physically swap the MISO & MOSI signals and enable IO Swap in CubeMX?

Just curious, why SPI for "just" an EEPROM?

[GreenGuy]

All good. 

Did not try swapping pins since I would have to swap them at the device.  Could try that bu removing the device and using a simple loopback (short MOSI and MISO). But if it did work it would mean needing to later spin a board which is not desirable since we can implement a bit-bang as a solution.

For EEPROMS the choices are SPI, I2C, CAN, and Single Wire to name a few.

Reason for using EEPROM and not internal flash for persistent storage; The device sits on a separate board with some analog components that require calibration.  The calibration parameters are stored on the other board with the analog parts so the digital board can be changed without losing having to re-calibrate the pair.

 

 

[David Littell]

---

@GreenGuy wrote:

All good. 

Did not try swapping pins since I would have to swap them at the device.  Could try that bu removing the device and using a simple loopback (short MOSI and MISO). But if it did work it would mean needing to later spin a board which is not desirable since we can implement a bit-bang as a solution.

For EEPROMS the choices are SPI, I2C, CAN, and Single Wire to name a few.

Reason for using EEPROM and not internal flash for persistent storage; The device sits on a separate board with some analog components that require calibration.  The calibration parameters are stored on the other board with the analog parts so the digital board can be changed without losing having to re-calibrate the pair.

 

 

---

Well, consider that the simple loopback isn't the same thing as swapping the pins internally.

I'd suggest that I2C should be used instead of SPI for something popcorn like an EEPROM.