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!

[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.

[tjaekel]

Yes, if you have a mistake on PCM (MISO - MOSI swapped) - the MCU should have a feature to swap these signals.
But no effect on the "loopback test".

Yes, other option is to use I2C EEPROM (I do often, no need for a fast SPI or QSPI memory chip, e.g. for my SYSCFG persistent storage or "man" pages).

Why you do not get it to work?
I had never such issues with SPI on any STM32 MCU. It is working fine.
The only I had (twice): a GPIO pin, e.g. with SPI was fried, not working anymore after long time working fine.

And: if the SPI CLK signal coming out of MCU is "blocked" (e.g. a shortcut on external) - the SPI Rx will not work anymore. The MCU seems to get the SPI CLK for SPI Rx directly from the pin.

How to help you with more guidance?

[AScha.3]

>I had never such issues with SPI on any STM32 MCU. It is working fine.

Me too, SPI on all chips working fine, never had a problem , same as you.

Ok, but the SPI4 didnt work - only 0x00 received .

Just to be sure, i changed the miso pin back to first setting, optimizer -o0, core at 240M (no need to run 480M , as before), core voltage level 2 now.

Same program...

Surprise ! SPI4 working at 7,5Mbit , as if there never was a problem.

-> optimizer -O2 : working.

-> now same setting, as yesterday: core at 480M, scale 0 , 15Mbit on SPI4 : working.

So SPI4 working (now) as it should.

Only one question remains : why it didnt work at my first test (with soldered wire connecting mosi-miso , as now also ) ?

(Signal was on the loop wire, checked with scope; miso received also 2 bytes, but value always zero.)

[GreenGuy]

Now I want to go back to the lab and see if Rod Serling is standing in the corner.

Seriously, the point is not what protocol should be used, but why is the current SPI protocol not working on the parts that I have.  I have 6 proto boards that all do the same thing.  I have tried all of the different optimizations with the same end result.  With the results from AScha.3 I was beginning to think it might be a package issue.  Given the latest results, I don't know what to think.

As far as the immediate problem is concerned, I have a working solution which uses the pins that SPI4 would have used as GPIO and bit-banging.  Not very fast but it works solid.  Fortunately, in my case, speed is not a concern.

[David Littell]

So did you swap the pins via CubeMX?

[tjaekel]

To be "honest": way are you flooding the forum with "your" particular problem?
SPI works on almost all MCUs (and many people have it working, including me).
And when it comes to "SPI protocol": it is dependent on the external chip you want to use.
I think, the forum can help you to setup SPI on the MCUs, but not on the "SPI protocol" you need in order to talk to an external chip (the forum does not support particular external chips).

• if you have a bug on "your" board: have you tried to use the SWAP feature?
• Is the SPI in general working, e.g. with the "MISO-MOSI shortcut"?
• are you sure, you have the right SPI mode, MSB vs. LSB, SPI clock speed?
• do you see the signals coming out (and in)?

I think: SPI works, unless you have damaged (fried) your chip pin. If you see all signals coming out and going in,
all other stuff is an issue in your FW (or you have damaged your chip).

To be "very honest": you fill the forum with so many thread responses, that even me start to ignoring it. Sorry: too much.

Good luck.