We use STM32F767NIH and see random QSPI interface failure accessing a flash.

[Flavio1]

We use STM32F767NIH and see random QSPI interface failure accessing a micron flash. The failure happens when we run diagnostic sw in a loop that does a write, read back and verify function. Using a protocol analyzer, we notice that when the QSPI fails (during read), CS pin going high a few times. Is this normal?

[Flavio1]

Hi user 6.02214076

We found out that the old board had a bad rework. Fixing the rework seems correct the stuck at zero issue at DQ3 and jumps at the CS. However the QSPI test (write/ read back/ verify) still failing when ran in a loop. We have tried to reduce the clock frequency, but did not help. Noticed anything alarming on the capture I loaded last time?

[Tesla DeLorean]

It was unhelpfully annotated, and lacked signals on D2/D3. No real idea what the data patterns on the chip are (assume an incrementing pattern, prefer distributed LFSR noise), or the failure criterion. Normally one would use a GPIO trigger when the STM32 test fails, and then truncate the tail.

Only 20% contains data, end point doing a STATUS READ?

Not sure how I'm expected to debug this?

Here I tend to test single, dual and quad reads, proving I can CRC the entire array, and get consistent answers.

Then do the memory-mapping, and make sure that's coherent with the prior tests.

Got a usable UART-TX on this board? What are the QSPI pin assignments?

Show initialization. Show test loop/expectations.

[Flavio1]

After fixing the rework issue, i notice these two issues.

1- DQ3 is running, however it is always high by default when not active.

2- we still see pulses on the CS. basically clock is running after CS is high.

Did anyone had experience with such issues?

[Tesla DeLorean]

You indicated earlier that you have a pull-up on DQ3, so I'd assume when CS is HIGH the thing goes Hi-Z from the memory side.

The lower set of traces seems to replicate the earlier issue where the signalling on D3 bleeds through or glitches CS. Check that the VCC domain that the pull-up goes to actual gets to the rest of the VCC net, and isn't a floating island.

Try Reading in DUAL or SINGLE modes, confirm they work.

Enumerate the STM32 pins used in your CUSTOM BOARD.

State a USART-TX pin that can be used for diagnostic output.

[Flavio1]

Thanks, we plan to test x1 and x2.

Based on Spec, I have pull up on both DQ2 and DQ3. why DQ2 is low when CS is high? Also I don't see why DQ3 has to be toggled when CS is high.

[Tesla DeLorean]

I'm not going to wade into this any deeper without a better idea of the circuit and settings..

Check the netlist, check the continuity, check the pin positions.

>>..we plan to test x1 and x2.

It is a couple of minute test to code, that's why I'd do it first to establish a base line.

[Flavio1]

We have tested x1 as well. It fails the same way as x4. The failure happens in different designs that use STM32, so it's not dependent on a particular HW. I have loaded a new analyzer capture when it failed x1 test. For this particular capture, the logic analyzer does not detect any error, but QSPI controller stopped sending additional commands to finish the transaction (diag issues 32 4-byte reads to read 128 data bytes from 0 to 0x7F, but the transaction stopped after reading 0 to 0x6F). There is an erratum of STM32 mentioning QSPI controller may be stalled (section 2.4.3 of this rev 6 errata document attached) in memory-mapped mode. We are not using memory-mapped mode (we are using in-direct mode), but could this apply to our case as well? I added protocol analyzer data as well.

[Tesla DeLorean]

Create a test application demonstrating the failure, on a stock ST board, and share that with your FAE, or support engineer responsible for your account.

Data can trail-off on QSPI devices if there is a disparity between the clocking frequency and the dummy cycles afforded to the device, you basically out-run the devices ability to preload data into the output buffers from the flash memory array.

[Tesla DeLorean]

Doing a high-stress pattern on a 16MB N25Q128 on a STM32F746G-DISCO, 100's of passes, no failures, will let it grind all night...

[Tesla DeLorean]

4600 full passes over the 16MB array, no byte level or CRC failure.