Edit:
... and to clarify: that not means that users must chose flash with reset, but that the ROM boot code will issue a 1us pulse on IO3 (prop IO-P59) prior to start booting. If the user do not intend to switch to QSPI he can use a flash without hw reset pin. The normal non QSPI flash chips will simply be wired on pins 56,57,60,61
And BTW the prop can issue by default an 1us low pulse for flash reset prior to boot. This can be eventually disabled by one of the fuses. In this way P58 and P59 can be normal IO's when the prop is connected to an SPI only device or these pins are used for SD in case of SD boot. Even if the pulse with the SD not selected would not hurt it.
...
The chip will stay in 4b mode even after the power is cycled to the chip? ...
No, both "power cycle" and "hw reset" will revert back the flash chip to 1b mode. But this is not true for prop warm/sw reset. Using 16 pin flash which have external reset it could be transparent to the prop IF the sw reset drives the external reset pin low. If not or in case of 8 pin flash the prop must issue an reset to the flash chip, the easyest way is using the shared IO3/RESET pin when CS is high.
The shared reset pin works always as reset in 1b mode while it works as IO3 with CS low and RESET with CS high in 4b mode. This for all the flash chips having reset pin that I've seen.
@cgracey: the p2 is driving its reset pin low during sw reset isn't it?
No, the Prop2 does not drive RESn low. It's only an input.
I'd rather not have a hardware reset signal. It's more clutter. That could push things to 7 pins. We could get by with three, if we forget about dual/quad modes.
I'd rather not have a hardware reset signal. It's more clutter. That could push things to 7 pins. We could get by with three, if we forget about dual/quad modes.
...
Here is what it would look like to implement quad SPI:
SPI_SEL = 61 CS
SPI_CLK = 60
SPI_D3 = 59 RESET
SPI_D2 = 58
SPI_D1 = 57
SPI_D0 = 56
it's enough to drive low P59 while P61 is high before start accessing the flash. It not requires an additional signal.
The ROM boot code can act in standard SPI but let then the users switch to QuadSPI safely.
This way you don't have to bother with flash sw reset commands.
This way who will want to use QSPI will buy flash chips that have hw reset, the others can buy flash chips without this function.
The only downside is a 1us pulse on one pin (P59) after P2 power-on/reset. If by using the standard SPI flash, this P59 pulse is seen as a wasted pin, it can be avoided by burning an internal fuse if necessary.
Or users can connect other things eg a LED on this pin for which this pulse during boot won't hurt, so the total pins are really 4 (56,57,60,61)
I wonder how the ESP8266 handles this? It supports both SPI and quad SPI.
Very good point. If the ESP8266 can do both SPI and quad SPI, it sets user expectations, and it should also give a reference example to check with a logic analyzer.
Do they give a list of Flash part codes ?
What about the newer ESP32, I'm guessing that is at least a superset here ?
I don't understand why we can't just boot in SPI mode and then have the option of accessing the same chip in QSPI.
I think that is the common aspiration, the finer points around how to exit Quad mode on soft reset are what is under discussion....
I can see merit in 3 pin and 6 pin connects, so have suggested using a spare boot-pin map to select these 2.
The 6 pin one, would manage QuadSPI connected parts, loading in 1b SPI.
Have you asked OnSemi about internal EEPROM/Flash/OTP yet?
This would solve all these issues quite simply.
Do you mean as a dual-die package ?
Dual-die has appeal, but does not solve all the issues & creates others.
In most cases, users will still need external Flash, and now you have 2 Images to manage again.
I'd rather not have a hardware reset signal. It's more clutter. That could push things to 7 pins. We could get by with three, if we forget about dual/quad modes.
...
Here is what it would look like to implement quad SPI:
SPI_SEL = 61 CS
SPI_CLK = 60
SPI_D3 = 59 RESET
SPI_D2 = 58
SPI_D1 = 57
SPI_D0 = 56
it's enough to drive low P59 while P61 is high before start accessing the flash. It not requires an additional signal.
The ROM boot code can act in standard SPI but let then the users switch to QuadSPI safely.
This way you don't have to bother with flash sw reset commands.
This way who will want to use QSPI will buy flash chips that have hw reset, the others can buy flash chips without this function.
The only downside is a 1us pulse on one pin (P59) after P2 power-on/reset. If by using the standard SPI flash, this P59 pulse is seen as a wasted pin, it can be avoided by burning an internal fuse if necessary.
Or users can connect other things eg a LED on this pin for which this pulse during boot won't hurt, so the total pins are really 4 (56,57,60,61)
dMajo,
I've been reading about this HOLD#/RESET#/DQ3 issue.
If I am reading right, this alternate RESET# option is set by a non-volatile bit for the Winbond and Mircron parts.
For the ISSI part, I see this note: "For RESET# pin option instead of HOLD# pin, call Factory."
I was reading in the Micron datasheet that this HOLD#/RESET# pin is only active in the SPI (not QPI) mode, if it is pre-enabled by a non-volatile bit. So, you would need to issue an exit-QPI instruction before asserting reset on DQ3.
Anyway, this 'reset' use of HOLD#/DQ3 requires programming the part, according the supportive manufacturers.
Maybe I'm not seeing something that is clear to others.
The only thing that is looking reliable to me is the 3-wire connection, mainly because it inhibits QPI.
With even 1 data bit, the flash chip could function as very fast file storage system. 10MB/s read seems quite sufficient for most uses, to me. And it saves 1 or 3 pins. No matter the data width, writing is going to be at least 10x slower.
Have you asked OnSemi about internal EEPROM/Flash/OTP yet?
This would solve all these issues quite simply.
BTW I can do any test/verifications with S25FL116K0XMFI043. I have 5 parts.
I still haven't asked, I'm sorry.
Part of the reason has been that there will be no room on the die for any flash memory, as RAM and logic take up all the space, already. So, it's a rather hypothetical matter. When I have a sit-down with these guys again, I'll bring it up. If I ask now, it's going to send people on what will be fruitless errands, with obligatory follow-ups and so forth. I've been reluctant to exercise them over this matter.
Also, introducing a variable like internal flash, at this point, is unwelcome. I want to finish this ASAP and have something solid we can all stand on for tool development.
10MB/s read seems quite sufficient for most uses, to me. And it saves 1 or 3 pins...
...at a cost of being one quarter the speed it could have been.
I've not seen a comment on the issues of supporting both 3 pin and 6 pin ? - User pin-set choice ?
10MB/s read seems quite sufficient for most uses, to me. And it saves 1 or 3 pins...
...at a cost of being one quarter the speed it could have been.
I've not seen a comment on the issues of supporting both 3 pin and 6 pin ? - User pin-set choice ?
Every different configuration we test for will take another 14ms, protracting start time. It also forces likely-unused pins to get toggled that cannot, then, hook to state-sensitive nodes of the user's greater circuit (imagine cases of no flash). I wish this whole matter were simpler and there was a clear way to go.
The idea of losing QPI is a little sad, but simplicity, reliability, and vendor flexibility are way more important. At least, that's my opinion.
It sounds like the QPI situation is a complete mess. Even if you were able to make all currently existing variants work right now, it seems like next week a vendor might make a new chip that won't work.
Also, The P2 has 512k shared RAM, you can fill that in 1/20th of a second (50ms) at 10MB/s using SPI. QPI would get that down to 12.5ms (1/80th of a second). The read size of an initial startup chunk that sets the pins correctly for any external hardware (thinking reset condition needing to get pins to safe states), would likely be what 2k? 4k? Let's go with 8k. That 8k would take 781.25us (less than 1 ms) in SPI, and 195.3125us in QPI. So what real world situation is going to fail over the difference of a half millisecond?
Especially when that comes after how many milliseconds of reset time for the P2 already?
One question I have that could be a problem... Say you have a flash chip part that can do QPI, but you have it hooked up in 3 wire mode. Is it still possible to send the commands to cause the part to enter QPI mode? Thus making it so you have to power cycle to get things back to working? Seems like if it's possible to get the chip into a bad state even with 3 wire mode, then that doesn't really solve the problem.
It sounds like the QPI situation is a complete mess. Even if you were able to make all currently existing variants work right now, it seems like next week a vendor might make a new chip that won't work.
Also, The P2 has 512k shared RAM, you can fill that in 1/20th of a second (50ms) at 10MB/s using SPI. QPI would get that down to 12.5ms (1/80th of a second). The read size of an initial startup chunk that sets the pins correctly for any external hardware (thinking reset condition needing to get pins to safe states), would likely be what 2k? 4k? Let's go with 8k. That 8k would take 781.25us (less than 1 ms) in SPI, and 195.3125us in QPI. So what real world situation is going to fail over the difference of a half millisecond?
Especially when that comes after how many milliseconds of reset time for the P2 already?
One question I have that could be a problem... Say you have a flash chip part that can do QPI, but you have it hooked up in 3 wire mode. Is it still possible to send the commands to cause the part to enter QPI mode? Thus making it so you have to power cycle to get things back to working? Seems like if it's possible to get the chip into a bad state even with 3 wire mode, then that doesn't really solve the problem.
An 'enter-QPI' command could be sent with the 3-wire hookup, but nobody would do that, because it wouldn't be usable.
The argument for QPI is (only?) that it enables 4x faster reading for apps which will want to read the flash on a continuous basis, after booting.
Have you asked OnSemi about internal EEPROM/Flash/OTP yet?
This would solve all these issues quite simply.
BTW I can do any test/verifications with S25FL116K0XMFI043. I have 5 parts.
I still haven't asked, I'm sorry.
Part of the reason has been that there will be no room on the die for any flash memory, as RAM and logic take up all the space, already. So, it's a rather hypothetical matter. When I have a sit-down with these guys again, I'll bring it up. If I ask now, it's going to send people on what will be fruitless errands, with obligatory follow-ups and so forth. I've been reluctant to exercise them over this matter.
Also, introducing a variable like internal flash, at this point, is unwelcome. I want to finish this ASAP and have something solid we can all stand on for tool development.
Chip,
IMHO, the space for Eeprom/Flash/OTP should only be minimal. I am just talking about sufficient space to replace the Boot ROM - isn't that about 2-4KB?
Then the various boot SPI chips, SD, serial, all become moot. Obviously we will need to be abe to program the internal eeprom/flash/otp initially.
Chip,
My example case was kind of directed at jmg who seems to feel that people won't even use the chip at all if it doesn't support QPI mode at boot to get the fastest possible boot from reset. Presumably to handle critical hardware states or whatever. He may be right, but if your situation hangs on the thread of microseconds after reset, then the P2 isn't going to be a good choice no matter how fast it reads the flash.
Yes, it would be nice if we could have 40MB/s reads from large flash chips, but I think 10MB/s is sufficient for most needs. I think the only way you could support QPI on boot is to limit what flash parts can be used with the P2 for booting, which is bad. It also could be a problem down the line when the supported parts are no longer available and newer parts no longer work the same way (which seems to have already been the case with flash chips and QPI mode).
Re: entering QPI mode while hooked up 3 wire. Yeah it would be stupid to do, but could happen via software bug. I guess that's not too terrible, they just have to power cycle when they have that bug. Then fix their bug.
Chip,
My example case was kind of directed at jmg who seems to feel that people won't even use the chip at all if it doesn't support QPI mode at boot to get the fastest possible boot from reset.
Err no, not what I have said.
The discussion is not about QPI at boot, the plan always was to boot in 1 bit mode.
The problem is closing the door to ALL QSPI uses, by forcing a 3 pin mode, and then users have to add another Flash part to get QSPI.
That will seem like a ugly kludge/oversight to many users.
Parallax designed a Whizz Bang MCU but then nobbled it, to 1/4 of possible Flash bandwidth ?!
Of course, smarter users will apply the age-old trick of using a resistor between DI and DO, to emulate 3 bit mode, but still permit QPSI use, if they want.
Only now, guess what ? They might have that part in QSPI when a soft reset arrives.
So even 3 pin mode does need to think about QSPI exit.
I don't think this problem can be solved by ignoring it, and selecting a subset, as that subset is an illusion.
Check into what ESP8266 does, as they have set the expectation companies can support both, by delivering that.
Chip,
Re: entering QPI mode while hooked up 3 wire. Yeah it would be stupid to do, but could happen via software bug. I guess that's not too terrible, they just have to power cycle when they have that bug. Then fix their bug.
See above, you can have a 3 wire-boot part, in Quad mode, in a perfectly legal, no-bugs design.
ie you have created a problem, but not solved anything....
IMHO, the space for Eeprom/Flash/OTP should only be minimal. I am just talking about sufficient space to replace the Boot ROM - isn't that about 2-4KB?
Then the various boot SPI chips, SD, serial, all become moot. Obviously we will need to be abe to program the internal eeprom/flash/otp initially.
Issues with on-die NV, are that adds process steps, even if only a small area is used.
It is also quite hard to test for on-die operation.
If OnSemi had an OTP process that could swap-in for the ROM, at zero added risk and zero added die area, maybe...
but OTP often have strange Vpp caveats.
Part of the reason has been that there will be no room on the die for any flash memory, as RAM and logic take up all the space, already. So, it's a rather hypothetical matter. When I have a sit-down with these guys again, I'll bring it up. If I ask now, it's going to send people on what will be fruitless errands, with obligatory follow-ups and so forth. I've been reluctant to exercise them over this matter.
Also, introducing a variable like internal flash, at this point, is unwelcome. I want to finish this ASAP and have something solid we can all stand on for tool development.
I'd agree that on-die flash is not practical at this stage, but you could ask about stacked die, and what is needed to at least allow for that ?
Every different configuration we test for will take another 14ms, protracting start time.
It also forces likely-unused pins to get toggled that cannot, then, hook to state-sensitive nodes of the user's greater circuit (imagine cases of no flash). I wish this whole matter were simpler and there was a clear way to go.
Why does it add 14ms ? or cost unused pins ?
In a default 3 pin mode start-up, a simple read-presence check, should take microsecond region times.
ie if something is wired as 3 pin, you can detect that without wigging any more pins ?
Cases of no-flash would be managed in the Pin-Map, but you do need to allocate some pins to boot anyway.
The only thing that is looking reliable to me is the 3-wire connection, mainly because it inhibits QPI.
Is it really necessary to hobble the hardware to protect people from doing a bad hardware/software design. If you support normal 2 pin SPI and allow the option of using QSPI mode after boot, the chip is more flexible. If someone misuses that they pay the price. I'm sure there are many ways to do a bad hardware/software design. You can't protect against all of them and it seems a shame to lose a potentially useful feature to provide this particular protection.
What I think Chip is saying is that if we run the Flash in 3-pin SPI (resistor from DO to DI) mode then that ALLOWS the user to hook-up the chip for QSPI mode BUT the boot ROM only has to worry about a standard SPI read mode for BOOTING. We don't have the huge memory resources of an RPi which can also take its time as well booting so it doesn't matter if it checks a whole database of chips and combinations.
It is up to the user to worry about any boot issues with the chip being stuck in 4-bit mode.
Is it really necessary to hobble the hardware to protect people from doing a bad hardware/software design. If you support normal 2 pin SPI and allow the option of using QSPI mode after boot, the chip is more flexible. If someone misuses that they pay the price. I'm sure there are many ways to do a bad hardware/software design. You can't protect against all of them and it seems a shame to lose a potentially useful feature to provide this particular protection.
Agreed.
Looking at the data open in front of me
Fremont FT24H16
Adesto AT25SF80
Winbond W25Q80
ISSI IS25LQ080 (added)
All have a common Read Device ID Command, and all have 0xff (or 0xffff) as a Single-pin reset mode, using just IO0
The Winbond part has Sticky modes, but uses M4=0 to hold in that mode, ie M4=1, will exit.
( That happens when 0xff is clocked in on IO0, even in StickyQ mode.)
Peter tested some common reset strings, ( & Enable Reset (66h) & Reset (99h) of larger parts ) and devices seem to tolerate 'not my reset' just fine.
That means you can detect a 3-pin connected memory, and save pins, if you want to.
You can also issue QSPI reset commands to that memory. or, you can use 6 pin mode, and QuadSPI reset, then boot in 1bit mode, but use all the available speed in that Flash device you paid for, in your end product, without needing to add another device, and manage 2 memory images.
I think it just needs a simple list of 'Supported/tested Memory' to guide users, & some simple init strings.
The only thing that is looking reliable to me is the 3-wire connection, mainly because it inhibits QPI.
Is it really necessary to hobble the hardware to protect people from doing a bad hardware/software design. If you support normal 2 pin SPI and allow the option of using QSPI mode after boot, the chip is more flexible. If someone misuses that they pay the price. I'm sure there are many ways to do a bad hardware/software design. You can't protect against all of them and it seems a shame to lose a potentially useful feature to provide this particular protection.
If they use QPI in their design, we get warm-boot trouble. Remember, also, that QPI goes from a 3-pin to 6-pin requirement. Are there really going to be needs for a 4x faster ROM? - because that's really all it is - a ROM.
The only thing I can picture that would benefit from this is an app that constantly overlaid code or 'played' the data out a DAC to make a static video image. And it must be worth giving up 3 pins for.
If they use QPI in their design, we get warm-boot trouble. Remember, also, that QPI goes from a 3-pin to 6-pin requirement.
See post above - I'm not see any brick-walls in the data sheets I'm looking at ??
ie You can support both 3 pin, and 6 pin modes, and if the ROM finds a 3 pin part, it can leave other pins alone.
By issue of Reset preambles, then Read Device ID, it can detect a part is present, in some microseconds.
That test works even on a blank device. It does not need to make sense of the ID, just that it is <> 0000/ffff
The only thing that is looking reliable to me is the 3-wire connection, mainly because it inhibits QPI.
Is it really necessary to hobble the hardware to protect people from doing a bad hardware/software design. If you support normal 2 pin SPI and allow the option of using QSPI mode after boot, the chip is more flexible. If someone misuses that they pay the price. I'm sure there are many ways to do a bad hardware/software design. You can't protect against all of them and it seems a shame to lose a potentially useful feature to provide this particular protection.
If they use QPI in their design, we get warm-boot trouble. Remember, also, that QPI goes from a 3-pin to 6-pin requirement. Are there really going to be needs for a 4x faster ROM? - because that's really all it is - a ROM.
The only thing I can picture that would benefit from this is an app that constantly overlaid code or 'played' the data out a DAC to make a static video image. And it must be worth giving up 3 pins for.
What about the SPI chips that do 4 bit data transfers but still accept commands over a single bit interface? I don't think they have the same reset problem do they? Also, is there any chance someone would put a QSPI SRAM on the same bus as the QSPI flash chip? The D0-D3 pins can be share among multiple devices can't they?
What I think Chip is saying is that if we run the Flash in 3-pin SPI (resistor from DO to DI) mode then that ALLOWS the user to hook-up the chip for QSPI mode BUT the boot ROM only has to worry about a standard SPI read mode for BOOTING.
That's very close, but I think you do need reset preambles in there. They are quite simple.
Otherwise, soft reset (re)boot can fail. Boot read is always in 1-bit mode.
Device ID <> Blank seems a simple, quick means to detect a connected device.
What I think Chip is saying is that if we run the Flash in 3-pin SPI (resistor from DO to DI) mode then that ALLOWS the user to hook-up the chip for QSPI mode BUT the boot ROM only has to worry about a standard SPI read mode for BOOTING.
That's very close, but I think you do need reset preambles in there. They are quite simple.
Otherwise, soft reset (re)boot can fail.
Device ID <> Blank seems a simple, quick means to detect a connected device.
Yes, so with the simple reset preamble to assist those who use QSPI mode we can then keep the boot simple. For those who want to run at the fastest possible rate I would suggest that they have a first stage booter which also switches to a higher frequency (remember that the P2 booter is only running at a measly 20MHz) and then use their QSPI mode if they so desire. The P2 booter needs to be kept simple because it is mask ROM and needs to be reliable, both now, and for many years.
What I think Chip is saying is that if we run the Flash in 3-pin SPI (resistor from DO to DI) mode then that ALLOWS the user to hook-up the chip for QSPI mode BUT the boot ROM only has to worry about a standard SPI read mode for BOOTING.
That's very close, but I think you do need reset preambles in there. They are quite simple.
Otherwise, soft reset (re)boot can fail. Boot read is always in 1-bit mode.
Device ID <> Blank seems a simple, quick means to detect a connected device.
I agree. ID'ing devices would be quick. Probably just look for not $00 and not $FF.
Yes, so with the simple reset preamble to assist those who use QSPI mode we can then keep the boot simple.
Yup, and a simple device ID can stop at 3-pin check mode, if it finds a connected device.
If not found, it can try 6 pin mode (assumes a quad connected device).
It might even be possible to read both SI_IO0(3 pin ID) and SO_IO1(6 pin ID), and make the next-step decision faster one pass.
For those who want to run at the fastest possible rate I would suggest that they have a first stage booter which also switches to a higher frequency (remember that the P2 booter is only running at a measly 20MHz) and then use their QSPI mode if they so desire.
Yup, the very first stub loaded, is likely to be small. From there, users can do what they like.
What I personally dislike is the increasing amount of pins needed to support different boot devices.
2 for serial, 3 (6?) for Flash some more if SD boot is in the mix.
I tend to run out of pins in my projects and often need to 're-use' pins 28-31 in the P1 for other purposes.
Now we are down to <90 multipurpose pins on the P2. All other do something at boot time. Sad.
And like with SD cards it seems QSPI is also vendor dependent and NOT 'reliable, both now, and for many years' like Peter stated so nicely.
Next year we might get hyper-flash using XQSPI with 8 pins or whatever.
It is sad that the P2 will not have any built in Flash/MRAM/EEPROM to be initially independent of external storage once programmed. That would solve all the boot issues.
But, please, keep the amount of pins used just for 'powering up and booting' as small as possible.
Comments
And BTW the prop can issue by default an 1us low pulse for flash reset prior to boot. This can be eventually disabled by one of the fuses. In this way P58 and P59 can be normal IO's when the prop is connected to an SPI only device or these pins are used for SD in case of SD boot. Even if the pulse with the SD not selected would not hurt it.
No, the Prop2 does not drive RESn low. It's only an input.
Chip the pins are 6 anyway: it's enough to drive low P59 while P61 is high before start accessing the flash. It not requires an additional signal.
The ROM boot code can act in standard SPI but let then the users switch to QuadSPI safely.
This way you don't have to bother with flash sw reset commands.
This way who will want to use QSPI will buy flash chips that have hw reset, the others can buy flash chips without this function.
The only downside is a 1us pulse on one pin (P59) after P2 power-on/reset. If by using the standard SPI flash, this P59 pulse is seen as a wasted pin, it can be avoided by burning an internal fuse if necessary.
Or users can connect other things eg a LED on this pin for which this pulse during boot won't hurt, so the total pins are really 4 (56,57,60,61)
Very good point. If the ESP8266 can do both SPI and quad SPI, it sets user expectations, and it should also give a reference example to check with a logic analyzer.
Do they give a list of Flash part codes ?
What about the newer ESP32, I'm guessing that is at least a superset here ?
I think that is the common aspiration, the finer points around how to exit Quad mode on soft reset are what is under discussion....
I can see merit in 3 pin and 6 pin connects, so have suggested using a spare boot-pin map to select these 2.
The 6 pin one, would manage QuadSPI connected parts, loading in 1b SPI.
Have you asked OnSemi about internal EEPROM/Flash/OTP yet?
This would solve all these issues quite simply.
BTW I can do any test/verifications with S25FL116K0XMFI043. I have 5 parts.
Do you mean as a dual-die package ?
Dual-die has appeal, but does not solve all the issues & creates others.
In most cases, users will still need external Flash, and now you have 2 Images to manage again.
dMajo,
I've been reading about this HOLD#/RESET#/DQ3 issue.
If I am reading right, this alternate RESET# option is set by a non-volatile bit for the Winbond and Mircron parts.
For the ISSI part, I see this note: "For RESET# pin option instead of HOLD# pin, call Factory."
I was reading in the Micron datasheet that this HOLD#/RESET# pin is only active in the SPI (not QPI) mode, if it is pre-enabled by a non-volatile bit. So, you would need to issue an exit-QPI instruction before asserting reset on DQ3.
Anyway, this 'reset' use of HOLD#/DQ3 requires programming the part, according the supportive manufacturers.
Maybe I'm not seeing something that is clear to others.
The only thing that is looking reliable to me is the 3-wire connection, mainly because it inhibits QPI.
With even 1 data bit, the flash chip could function as very fast file storage system. 10MB/s read seems quite sufficient for most uses, to me. And it saves 1 or 3 pins. No matter the data width, writing is going to be at least 10x slower.
I still haven't asked, I'm sorry.
Part of the reason has been that there will be no room on the die for any flash memory, as RAM and logic take up all the space, already. So, it's a rather hypothetical matter. When I have a sit-down with these guys again, I'll bring it up. If I ask now, it's going to send people on what will be fruitless errands, with obligatory follow-ups and so forth. I've been reluctant to exercise them over this matter.
Also, introducing a variable like internal flash, at this point, is unwelcome. I want to finish this ASAP and have something solid we can all stand on for tool development.
I've not seen a comment on the issues of supporting both 3 pin and 6 pin ? - User pin-set choice ?
Every different configuration we test for will take another 14ms, protracting start time. It also forces likely-unused pins to get toggled that cannot, then, hook to state-sensitive nodes of the user's greater circuit (imagine cases of no flash). I wish this whole matter were simpler and there was a clear way to go.
The idea of losing QPI is a little sad, but simplicity, reliability, and vendor flexibility are way more important. At least, that's my opinion.
It sounds like the QPI situation is a complete mess. Even if you were able to make all currently existing variants work right now, it seems like next week a vendor might make a new chip that won't work.
Also, The P2 has 512k shared RAM, you can fill that in 1/20th of a second (50ms) at 10MB/s using SPI. QPI would get that down to 12.5ms (1/80th of a second). The read size of an initial startup chunk that sets the pins correctly for any external hardware (thinking reset condition needing to get pins to safe states), would likely be what 2k? 4k? Let's go with 8k. That 8k would take 781.25us (less than 1 ms) in SPI, and 195.3125us in QPI. So what real world situation is going to fail over the difference of a half millisecond?
Especially when that comes after how many milliseconds of reset time for the P2 already?
One question I have that could be a problem... Say you have a flash chip part that can do QPI, but you have it hooked up in 3 wire mode. Is it still possible to send the commands to cause the part to enter QPI mode? Thus making it so you have to power cycle to get things back to working? Seems like if it's possible to get the chip into a bad state even with 3 wire mode, then that doesn't really solve the problem.
An 'enter-QPI' command could be sent with the 3-wire hookup, but nobody would do that, because it wouldn't be usable.
The argument for QPI is (only?) that it enables 4x faster reading for apps which will want to read the flash on a continuous basis, after booting.
IMHO, the space for Eeprom/Flash/OTP should only be minimal. I am just talking about sufficient space to replace the Boot ROM - isn't that about 2-4KB?
Then the various boot SPI chips, SD, serial, all become moot. Obviously we will need to be abe to program the internal eeprom/flash/otp initially.
My example case was kind of directed at jmg who seems to feel that people won't even use the chip at all if it doesn't support QPI mode at boot to get the fastest possible boot from reset. Presumably to handle critical hardware states or whatever. He may be right, but if your situation hangs on the thread of microseconds after reset, then the P2 isn't going to be a good choice no matter how fast it reads the flash.
Yes, it would be nice if we could have 40MB/s reads from large flash chips, but I think 10MB/s is sufficient for most needs. I think the only way you could support QPI on boot is to limit what flash parts can be used with the P2 for booting, which is bad. It also could be a problem down the line when the supported parts are no longer available and newer parts no longer work the same way (which seems to have already been the case with flash chips and QPI mode).
Re: entering QPI mode while hooked up 3 wire. Yeah it would be stupid to do, but could happen via software bug. I guess that's not too terrible, they just have to power cycle when they have that bug. Then fix their bug.
Err no, not what I have said.
The discussion is not about QPI at boot, the plan always was to boot in 1 bit mode.
The problem is closing the door to ALL QSPI uses, by forcing a 3 pin mode, and then users have to add another Flash part to get QSPI.
That will seem like a ugly kludge/oversight to many users.
Parallax designed a Whizz Bang MCU but then nobbled it, to 1/4 of possible Flash bandwidth ?!
Of course, smarter users will apply the age-old trick of using a resistor between DI and DO, to emulate 3 bit mode, but still permit QPSI use, if they want.
Only now, guess what ? They might have that part in QSPI when a soft reset arrives.
So even 3 pin mode does need to think about QSPI exit.
I don't think this problem can be solved by ignoring it, and selecting a subset, as that subset is an illusion.
Check into what ESP8266 does, as they have set the expectation companies can support both, by delivering that.
See above, you can have a 3 wire-boot part, in Quad mode, in a perfectly legal, no-bugs design.
ie you have created a problem, but not solved anything....
Issues with on-die NV, are that adds process steps, even if only a small area is used.
It is also quite hard to test for on-die operation.
If OnSemi had an OTP process that could swap-in for the ROM, at zero added risk and zero added die area, maybe...
but OTP often have strange Vpp caveats.
I'd agree that on-die flash is not practical at this stage, but you could ask about stacked die, and what is needed to at least allow for that ?
Why does it add 14ms ? or cost unused pins ?
In a default 3 pin mode start-up, a simple read-presence check, should take microsecond region times.
ie if something is wired as 3 pin, you can detect that without wigging any more pins ?
Cases of no-flash would be managed in the Pin-Map, but you do need to allocate some pins to boot anyway.
What about powering the flash chip with the Prop's reset line?
When reset is pulled low, flash chip is powered off
Just have a strong pullup on reset - if it is a 3.3v signal (I don't remember)
v = ir, 3.3 = 0.025*r, R=132 ohms
Ok, it does not account for software reset, but perhaps that could pull reset pin low internally?
It is up to the user to worry about any boot issues with the chip being stuck in 4-bit mode.
Looking at the data open in front of me
Fremont FT24H16
Adesto AT25SF80
Winbond W25Q80
ISSI IS25LQ080 (added)
All have a common Read Device ID Command, and all have 0xff (or 0xffff) as a Single-pin reset mode, using just IO0
The Winbond part has Sticky modes, but uses M4=0 to hold in that mode, ie M4=1, will exit.
( That happens when 0xff is clocked in on IO0, even in StickyQ mode.)
Peter tested some common reset strings, ( & Enable Reset (66h) & Reset (99h) of larger parts ) and devices seem to tolerate 'not my reset' just fine.
That means you can detect a 3-pin connected memory, and save pins, if you want to.
You can also issue QSPI reset commands to that memory.
or, you can use 6 pin mode, and QuadSPI reset, then boot in 1bit mode, but use all the available speed in that Flash device you paid for, in your end product, without needing to add another device, and manage 2 memory images.
I think it just needs a simple list of 'Supported/tested Memory' to guide users, & some simple init strings.
If they use QPI in their design, we get warm-boot trouble. Remember, also, that QPI goes from a 3-pin to 6-pin requirement. Are there really going to be needs for a 4x faster ROM? - because that's really all it is - a ROM.
The only thing I can picture that would benefit from this is an app that constantly overlaid code or 'played' the data out a DAC to make a static video image. And it must be worth giving up 3 pins for.
ie You can support both 3 pin, and 6 pin modes, and if the ROM finds a 3 pin part, it can leave other pins alone.
By issue of Reset preambles, then Read Device ID, it can detect a part is present, in some microseconds.
That test works even on a blank device. It does not need to make sense of the ID, just that it is <> 0000/ffff
That's very close, but I think you do need reset preambles in there. They are quite simple.
Otherwise, soft reset (re)boot can fail. Boot read is always in 1-bit mode.
Device ID <> Blank seems a simple, quick means to detect a connected device.
Yes, so with the simple reset preamble to assist those who use QSPI mode we can then keep the boot simple. For those who want to run at the fastest possible rate I would suggest that they have a first stage booter which also switches to a higher frequency (remember that the P2 booter is only running at a measly 20MHz) and then use their QSPI mode if they so desire. The P2 booter needs to be kept simple because it is mask ROM and needs to be reliable, both now, and for many years.
I agree. ID'ing devices would be quick. Probably just look for not $00 and not $FF.
If not found, it can try 6 pin mode (assumes a quad connected device).
It might even be possible to read both SI_IO0(3 pin ID) and SO_IO1(6 pin ID), and make the next-step decision faster one pass.
Yup, the very first stub loaded, is likely to be small. From there, users can do what they like.
Agreed. 1-bit mode, read only, reset preambles, and device-present check, are about as simple as possible.
2 for serial, 3 (6?) for Flash some more if SD boot is in the mix.
I tend to run out of pins in my projects and often need to 're-use' pins 28-31 in the P1 for other purposes.
Now we are down to <90 multipurpose pins on the P2. All other do something at boot time. Sad.
And like with SD cards it seems QSPI is also vendor dependent and NOT 'reliable, both now, and for many years' like Peter stated so nicely.
Next year we might get hyper-flash using XQSPI with 8 pins or whatever.
It is sad that the P2 will not have any built in Flash/MRAM/EEPROM to be initially independent of external storage once programmed. That would solve all the boot issues.
But, please, keep the amount of pins used just for 'powering up and booting' as small as possible.
Enjoy!
Mike