So there's this project, see, that uses moderate gobs of flash memory....
It has the usual constraints: limited space, at least I-temp rating, vast mechanical integrity, don't want to use lots of MCU pins to talk to it, and in general: a small-footprint chip with an SPI interface.
Well, there's this handy NOR-flash part, see, and it has the appropriate specs, and 64 MBytes ought to be plenty for the application at hand, and so it comes time to write the AGROS device driver for it.
And I note that it supports the Serial Flash Discoverable Parameters feature, and I think that this could be useful: I could write the driver for generality, and it could go out and see what chip is installed, and how it's organized, and all that good stuff.
And so I downloaded the JEDEC SFDP spec, and it was somewhat confusing, even considered in conjunction with the chip data sheet, and yet it seemed worth pursuing.
Eventually, for sufficiently this afternoon values of eventually, I tossed together a dummy driver and a test program for reading the SFDP data, and commenced to explore the address space.
OK, so the first several bytes that come back from command 0x5A, address 0, look right. Two parameter headers, the first 9 DWORDS at 0x000448 and the second 81 DWORDS at 0x000400. Which... um... actually, that doesn't look right; something about 0x51 × 4 being rather more than 0x48?
Well, anyway. Try reading starting at 0x000448. All FFs. At 0x000400? All FFs.
Look back at datasheet. Address to 0x5A command is supposed to be zero. Hm? But it's clearly not ignored....
Oh, well. Allocate a bloody huge buffer (2K bytes). Read a buncha SFDP data starting from zero. Has the header. Has all FFs the rest of the way down.
So... am I reading the spec wrong, or has the chip vendor implemented it wrong, or is the chip not working right?
Well, if it doesn't start making sense Real Soon Now, the driver will have rather more limited capability, and the user will just have to fill in all appropriate chip specs when configuring the application.
Update: well, obviously. The addresses in the SFDP header are DWORD addresses, not the byte addresses that the 0x5A command takes. And, contrary to the note in the datasheet, the 0x5A command on this chip does in fact handle nonzero addresses.