Yes, but qualifies it with "to prevent adverse command sequence". So if you are willing to accept an "adverse command sequence" then that's OK....Code:
, and it must also trackthe VCC supply level at power-down to prevent adverse command sequence.
But the datasheet uses the word 'must'.
I don't think the power-down case is controversial. Plainly if power disappears during a write sequence then at the very least the write may be partially completed - and that's obviously true of any flash device, regardless of the interface details. More specific to the kind of issue we are discussing here is the possibility that one command is interpreted as a different one, with the particularly bad case of a read turning into a write or erase.
In practice with RP2040 XIP the flash is normally executing in the address-only mode (ie. read command is latched), so there's even less chance than usual of a read turning into something else. The bootrom button isn't relevant to this situation, as the RP2040 won't stop driving nCS until it hits a brownout reset - the brownout detector applies to DVDD not VDDIO so will only cut in after the core voltage regulator goes out of regulation, which will be after VDD is already below the flash's inbuilt write inhibit (specified in the flash datasheet as having a threshold between 1.0 and 2.0V).
So the powerdown case is probably no worse than other typical uses of this flash device; if you are only reading from the flash it's extremely unlikely to give rise to a problem, and if you want to power down while writes could be in progress then you need to take extra precautions in your power arrangements, again nothing specific to the RP2040.
The power-up case is controversial as it could potentially (if relying on nothing other than the datasheet) leave the flash in a non-operational state at power-up. With the extra resistor fitted, this only applies with the bootrom button pressed; if you are using the bootrom button only for manual programming of devices, then an occasional failure to program requiring you to "do it again" is maybe acceptable. RPi claim to have tested this and found it not to be a problem with the Winbond devices; I don't see any evidence to dispute this, though others may differ. The RP2040 has default pull-up on the nCS pin, so in the absence of the boot button nCS will be high as soon as the RP2040 has sufficient power for the reset logic to operate - given that DVDD has a fully-operating minimum of 1.05V, this is highly likely to occur before the PSU has ramped above the 1.0V minimum of the Flash's on-chip protection, and thereafter the RP2040 pull-up will cause nCS to track Vcc. Adding the resistor would make this more pedantically compliant with the datasheet. With the bootrom button pressed, nCS remains low until RP2040 bootrom code starts running (and it then gets taken high and will track Vcc the rest of the way up if the PSU ramp hasn't yet fitted - given that RP2040 is specified to run from 1.8V it will typically start running sooner).
The one problem that I've personally experienced is actually the opposite of the one we are worrying about here: with a slow PSU ramp, the RP2040 starts operating too soon and issues commands before the flash is ready (violating the tVSL part of the datasheet). That's more likely to occur with non-Pico designs with different power arrangements - the Pico's buck-boost converter is likely to give fast rise times on the 3V3 supply even if the external Vsys rises more slowly, while a LDO supply generating 3V3 for the RP2040/flash can cause this (fixed in my case by an external power-on-reset circuit attached to the RP2040 RUN pin).
Statistics: Posted by arg001 — Tue Mar 11, 2025 11:09 am