QSPI reads only 0x9999

[ronnietango]

I have a custom board with STM32H747IGT6 MCU, which communicates with a S25HL512TFAMHI010 flash memory chip over QSPI. I have made several iterations of this board, and the QSPI communication has always been fine.

However, on the most recent iteration of the board, I am finding a very strange problem. I am able to erase/program the flash chip with external loader file using STM32CubeProgrammer, and to use this to read the 0x90000000 address, which shows my data has been programmed as expected.

But when I try to run my code as normal, the memory mapped QSPI read always returns 0x9999 (39321) for every address.

I've tried several of the new boards with the same results, and checked that the exact same code still works on the previous iterations of the hardware.

I'm at something of a loss for how to debug this..!

[ronnietango]

Thanks for this. I have double checked that all 6 bytes of the ID are the same on both boards (and also cleared the sCommand structure each time it is initialised, which doesn't change anything in the memory mapped mode unfortunately.) It also seems that the value of the Status Register 1 is 0x00, so this shouldn't be causing the Mass Erase to fail...

---

@Tesla DeLorean wrote:

If the read command template you supply in mapped mode is wrong, you'll get confused junk from the memory, or static bytes if the command is wrong/ignored.

---

It's certainly very possible that there could be an error in my code (although the same code still works just fine with the supposedly identical hardware - no changes to PCB routing/length matching etc - perhaps one of those situations where it has always just worked by blind luck until now..?), but I haven't been able to find anything so far...

Currently waiting for logic analyser to be delivered, and otherwise at a total loss for how to continue debugging this at present..!

[Tesla DeLorean]

>> otherwise at a total loss for how to continue debugging this at present.

Well got zero visibility into the issue from here.

At what point do you start getting the NINE's?

Perhaps show a demo where you Read with a 1-1-1 command (0x03), and then use that same structure to switch to memory map and show it's the same or different.

The Read Dual (0xBB) should also perform the same from a command level transaction to the memory mapped equivalent.

[TDK]

Perhaps show a complete example that exhibits the problem. Remove the code complexity and only include writing to the QSPI and then reading from it, showing the issue.

Since you can read from it in non-memory mapped mode, and STM32CubeProgrammer can read it correctly, seems like a bug in the code to me.

[ronnietango]

OK I've managed to get it working, although the solution surprises me somewhat.

It turns out that in order for the memory mapped mode to work correctly, the Write Enable (0x06) command needs to be sent first. This only needs to happen once for each chip - if you comment it out after having run it once, everything still works properly.

This is how the same code (without Write Enable) was working on my old boards (but not the new ones) - they must have run the Write Enable command at some point in the distant past, which I then removed from the firmware because I thought it wasn't necessary (because I'm only ever reading from the memory in this application.)

I still can't find anything in the S25HL512TFAMHI010 datasheet which states that this should be required - the Write Enable command is listed as a Prerequisite Transaction for various operations, but not for the read operation (RDAY4_4_0 = 0x6C) that I'm using in memory mapped mode - perhaps I'm missing something? In any case it's working now.

Thanks everyone for your help!