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!

[AScha.3]

We see.

afaik is same chip, die .

Just some pins (100,144,..) used/bonded and memory test for 1M or 2MB , die always has 2MB.

[GreenGuy]

For what it's worth, I wrote a bit-bang routine to read the status and it works.  I have not looked on the scope to see the baudrate but using a timer for the clock edges set for 250ns it should be near 2MHz.

[AScha.3]

So i tried , on H743ZIT :

simple i/o loop , mosi -> miso (at 15Mbit) ; 2 bytes : AA ,  55 , HAL_SPI_TransmitReceive():

- first test on SPI4 : sending ok, receive 00 ;  hmmm....

- next test on SPI2: sending ok, receive ok ; ahaa...

- then both + print result:

	  HAL_SPI_TransmitReceive(&hspi2, (uint8_t *)TxData, (uint8_t *)RxData, 2, 20);
	  printf("Rx2 : %X , %X  \r\n" , RxData[0] , RxData[1]);

	  HAL_SPI_TransmitReceive(&hspi4, (uint8_t *)TxData, (uint8_t *)RxData, 2, 20);
	  printf("Rx4 : %X , %X  \r\n" , RxData[0] , RxData[1]);

- then check AF port/pin setting : seem ok, AF5 .

- then try moving the miso to other pin PE13 -> PE5 now.

- then:

>> So seems a chip problem ( or ds wrong about the AF mapping) :

AF5 on PE13 not switching to SPI4_miso.

conclusion :

SPI4 Rx is not switched to PE13 , when set to it; only zero data input, not level on pin.

SPI4 Rx is switched to PE5 , when set to it; Rx data as expected.

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