Writing and reading to external NORFlash using QuadSPI on STM32H743 mcu and successfully test erase, write, and read the flash a few days ago but now only read works. What could cause the erase and write command to not fail but not work either?

[PFlor.2]

A few days ago I successfully tested erasing the NORFlash as entire chip erase, block erase, and sector erase. I also was able to write a string to Flash and read the string back out of Flash into a buffer. After working on other development I came back and tested the QSPI again and now I cannot erase or write but can still read out of Flash the test string that was written several days ago. I'm using the exact same code as the first test, trying to just erase and read and get the same string so proved it's not erasing also try to write a different test string and still get the old string when I read. Also during the initial test it would take a little time for a full chip erase and now it just goes through quickly also indicating an erase is not happening. I do have MPU setup for the the 0x90000000 Flash address as well for MPU_PRIVELEDGED_DEFAULT but have access set for ALL_ACCESS so thought this was ok.

[Tesla DeLorean]

The BPx block protect bits are set in some way, the wrong sequences for Micron, Macronix or Winbond can lock other manufacturer's parts. You'd have to undo that.

Start by dumping out the Status Register(s)

Different Winbond chips support different write status register commands, the older expect SR1 and SR2 to be written as a PAIR, as SR2 can't be written by itself.

Or you've got the chips in the wrong mode, written values in to NON-VOLATILE settings which they subsequently REMEMBER.

[PFlor.2]

the code I have was supposed to be for Windbond, but can't be sure

[Tesla DeLorean]

You'll have to read the registers to understand the internal state.

You can't send commands to the device when the STM32 is in Memory Mapped Mode.

[Tesla DeLorean]

Detail the board / pins.

I've built code into loaders to unbrick devices in this state.

[PFlor.2]

I did try to put the device in memory mapped mode intentionally and then stepped through the erase chip function and see that hqspi->State is HAL_QSPI_STATE_BUSY_MEM_MAPPED, however when I do not put the device in memory mapped mode (removed that code) then the hqspi->State is HAL_QSPI_STATE_READY (this is within HAL_QSPI_Command())... this made me believe that memory mapped had nothing to do with it.

[PFlor.2]

from the STM32H743ZI I have the following QSPI pin assignments...

PA1 - QUADSPI_BK1_IO3

PB2 - QUADSPI_CLK

PB6 - QUADSPI_BK1_NCS

PD11 - QUADSPI_BK1_IO1

PE2 - QUADSPI_BK1_IO2

PF9 - QUADSPI_BK1_IO1

[PFlor.2]

from the STM32H743ZI I have the following QSPI pin assignments...

PA1 - QUADSPI_BK1_IO3

PB2 - QUADSPI_CLK

PB6 - QUADSPI_BK1_NCS

PD11 - QUADSPI_BK1_IO1

PE2 - QUADSPI_BK1_IO2

PF9 - QUADSPI_BK1_IO1

Thanks so much for your advice on this!

[Tesla DeLorean]

Ok PB2,PB6 PD11,PF9,PE2,PA1, on a W25Q64JV

Let me check, don't think it's in my two-dozen list yet..

[Tesla DeLorean]

https://github.com/cturvey/stm32extldr/blob/main/h7_w25q64/CLIVEONE-W25Q64_STM32H7XX-PB2-PB6-PD11-PF9-PE2-PA1.stldr