The serial loader actually is ONE bit (pin 63 = rx). There's no need to monitor tx (pin 62) if you don't care about pass/fail.
But you could easily optionally map Tx onto Rx ? - to make a true one-pin, with pass/fail, and post-boot uses ....
Because the 1P loader focuses on Flash-displace, the question is does that best map onto RX pin, or one of the Flash pins (eg the one used to skip flash load, for UART-next ) ?
That frees the RX and TX pins for optional user and debug use, and keeps the boot-only path cleaner.
1-pin cases might not have any RX.TX pins, it could use ALL 63 remaining pins for user product code, and communicate on the half-duplex 1P link.
1-pin also allows low impact load of SD and USB drivers for broader future boot options..
The serial loader actually is ONE bit (pin 63 = rx). There's no need to monitor tx (pin 62) if you don't care about pass/fail.
But you could easily optionally map Tx onto Rx ? - to make a true one-pin, with pass/fail, and post-boot uses ....
Because the 1P loader focuses on Flash-displace, the question is does that best map onto RX pin, or one of the Flash pins (eg the one used to skip flash load, for UART-next ) ?
That frees the RX and TX pins for optional user and debug use, and keeps the boot-only path cleaner.
1-pin cases might not have any RX.TX pins, it could use ALL 63 remaining pins for user product code, and communicate on the half-duplex 1P link.
1-pin also allows low impact load of SD and USB drivers for broader future boot options..
What we have is so simple, already, in this textual loader. I don't know how to make anything simpler. I mean, a single-wire protocol would have to have some kind of timing inference, right?
About making Rx bidirectional, this would work with the PropPlug, as there's a 150-ohm series resistor on Rx, but the Prop123 boards have no resistive relief for that signal, so that would not be good. I can see using the current protocol in half-duplex on pin 61, maybe.
What we have is so simple, already, in this textual loader. I don't know how to make anything simpler. I mean, a single-wire protocol would have to have some kind of timing inference, right?
Not sure what you are asking.
The small MCUs have uarts, and calibrated RC osc, but the P2 already has an autobaud scheme as the 20MHz Boot Osc is of poor precision (much worse than the small MCUs 1~2% calibrates).
Code wise, the MCU looks very like a USB-UART bridge.
For 1-pin, you map RX and TX to the same physical pin, & check you have no timing collisions, so can run half-duplex ok. The code also needs to ignore the TX, if it is captured.
About making Rx bidirectional, this would work with the PropPlug, as there's a 150-ohm series resistor on Rx, but the Prop123 boards have no resistive relief for that signal, so that would not be good. I can see using the current protocol in half-duplex on pin 61, maybe.
The Duplex-boot choice would remain, as many user apps would require full duplex serial after boot.
To keep things simple, there is a question of where to map the 1-pin link.
I tend to favour using a SPI pin, as that allows default/documented TX.RX pins, and the 1-pin is really a memory-replacement, rather than a serial port replacement.
About using P56 instead of P59. It is no trouble to reverse-orient the DQ pins, as what you write comes back out the same way. Using the REV instruction to reverse command data would be necessary, though. This keeps the pin allocation tight, up against the top.
But this require a REV for each nibble you have to transmit/receive, or at least one per byte prior to split it to nibbles.
In case the part is missing the hw reset it will most probably not be used in multIO ...
Err ?? Quite a strange sweeping claim. Plenty of part have no HW reset and do have QuadIO.
Also, there is nothing about a hw reset, that says you cannot also use SW reset commands - which gives a sane superset operation.
No problems with doing both, if someone wants to...
I know there is multiIO parts without hw reset.
I meant: if someone wants to use moltiio he will buy parts with hw reset for safe boot. If he uses the parts withour reset function it is then his problem if it doesn't work.
This because imho the hw reset is easy to do (just a pulse on a pin) and is standard among various devices, you are not required to bother how to issue a "standard" sw reset accepted by all the devices regardless of the mode they are running in.
I know there is multiIO parts without hw reset.
I meant: if someone wants to use moltiio he will buy parts with hw reset for safe boot. If he uses the parts withour reset function it is then his problem if it doesn't work.
This because imho the hw reset is easy to do (just a pulse on a pin) and is standard among various devices, you are not required to bother how to issue a "standard" sw reset accepted by all the devices regardless of the mode they are running in.
But that is very restrictive indeed.
You have chosen by omission of the simple SW strings, to constrain ALL P2 users to only SOME parts, and in many cases an obtuse subset, that may not come the same next order.
Reset Pin option: Contact factory ?!
Note also that Reset pin excludes QUAD SPI modes, so you have painted users into an even smaller corner.
Demanding a HW reset pin is far too limiting, with bonus fish-hooks, but an optional reset pulse, I am fine with.
Or, maybe possible to use RESn to turn on/off external transistor to supply SPI power?
Could p2 pull down RESn during soft reset?
You mean make the RESn pin like a standard I/O pin with a pullup so it is pulled high as an input on power up and can drive external circuitry low as an output? Not a bad idea.
Not in the current completed PAD ring layout, I believe, but the general idea is useful.
Some MCUs do drive their reset pins, so that watchdog and software reset events can externally signal.
Power cycling needs a little care, as there can be varying power-up delays.
I have seen power-removal watchdogs, which could cycle power to both P2 and SPI/SD.
Given the price of niche watchdog parts, this watchdog may be better designed with a tiny, general purpose MCU.
Not in the current completed PAD ring layout, I believe, but the general idea is useful.
Some MCUs do drive their reset pins, so that watchdog and software reset events can externally signal.
Power cycling needs a little care, as there can be varying power-up delays.
I have seen power-removal watchdogs, which could cycle power to both P2 and SPI/SD.
Given the price of niche watchdog parts, this watchdog may be better designed with a tiny, general purpose MCU.
Not an expert in this area but it seems to me that having a single transistor pull a pin low to reset external hardware without resetting the P2 should not require much logic.
Or, maybe possible to use RESn to turn on/off external transistor to supply SPI power?
Could p2 pull down RESn during soft reset?
You mean make the RESn pin like a standard I/O pin with a pullup so it is pulled high as an input on power up and can drive external circuitry low as an output? Not a bad idea.
Chip has said that P2 can't drive RESn, it's only an input.
Normally Supervisors IC (eg Maxim has many variants), that gives you early power fail interrupt and reset circuitry, if they not have a RES_IN and RES_OUT, the RES(OUT) have a weak series resistor between the driver and physical pin so they can detect a changing condition on reset line and start their reset delay under which the reset line is kept low.
It will be nice if the sw reset command could drive low the RESn pin. This is one thing I've queried already in 2009 for P1 in and interesting topic started by PhiPi . I hoped the this was fixed in P2 but seems that the reset circuitry is remained the same.
I know there is multiIO parts without hw reset.
I meant: if someone wants to use moltiio he will buy parts with hw reset for safe boot. If he uses the parts withour reset function it is then his problem if it doesn't work.
This because imho the hw reset is easy to do (just a pulse on a pin) and is standard among various devices, you are not required to bother how to issue a "standard" sw reset accepted by all the devices regardless of the mode they are running in.
But that is very restrictive* indeed.
You have chosen by omission of the simple SW strings, to constrain ALL P2 users to only SOME parts, and in many cases an obtuse subset, that may not come the same next order.
Reset Pin option: Contact factory** ?!
Note also that Reset pin excludes*** QUAD SPI modes, so you have painted users into an even smaller corner.
Demanding a HW reset pin is far too limiting, with bonus fish-hooks, but an optional reset pulse, I am fine with.
*Restrictive: it depends. If you do not want to bother you buy a part with hw_reset. If you buy one without you can not use QSPI or add some circuitry that with CS and !RST power cycle the part. But hw_reset works for all the parts that suport it the samw way.
**From the datasheet I've locked at some parts have internal non-volatile register to choose one of the two functions: hold or reset.
Other parts have that "switch" in the ordering code so you purchase the part with hold or with reset.
*** No, the RESET low with CS not active (high) is always working, for all the parts in SPI/DSPI(SDI)/QSPI(SQI). You should not confuse QPI with QSPI(SQI). The former uses 4b for everything, the later always receive commands in 1b while exchanges data in 4b.
BTW: Even if its true that QPI disables HOLD/RESET shared pin, it needs a non-volatile preset in a register and an enabling (volatile) command under 1b mode to become active. And after a sw_reset or power-cycle it goes back to SPI (while keeping shared pin functions disabled because of the non-volatile nature of the preset register. Anyway also for QPI mode, on 16pin parts, the dedicated hw_reset pin always works, in any mode, with highest priority.
Chip doesn't want to bother with sw_reset codes and wants to set on a 3 wire communication. This will prevent any chance to use multiIO. The resistor between DI and DO is not enough in case of P2 internal sw_reset. I just want that if no flash is detected (because it could be in wrong mode) a pulse is issued on a pin (so that it can be reset/power-cycled up to developer to chose parts/circuitry that will sweet the job) and then the flash-boot is tried again.
PS:
But at the end, I do not want that it seems I am forcing for reset thing. I just give some suggestions (in my bad english, so I sometimes repeat myself in different way/words) to overcome what Chip think is risky/difficult /non-standard.
There are many gurus un this forum and whatever solution will be adopted for me is fine, unless it will prevent user-code to use multi-IO for flash. I will most probably use some kind of RAM based storage (NV/F/M) like today I am using the FM31L278 in place of eeprom on P1for many things. So the multi-IO is not only a read but also a write gain for me.
Assuming the RESn reset pulse is long enough to also reset the SQI flash chip to SPI mode when RESn is applied to gate of p-mosfet to power SQI chip, the only real issue is software reset.
But, in that case you would just have to make sure that before your code resets the Prop, it first commands SQI chip to revert to SPI mode.
So, this scheme can still work even if the P2 can't pull down RESn on software reset...
RE: "Chip has said that P2 can't drive RESn, it's only an input."
I am aware that it is only an input currently, but it could be changed to a digital I/O pin that defaults to an input on power up. Once powered up code running on the P2 could pull the pin low to reset external hardware connected to the reset line without resetting the propeller. I did design a circuit to do that on a Z80 system using 7400 chips way back when, and it was pretty simple. Although I have no experience with chip design I cannot see it being all that much more difficult than it was using 7400 chips.
...
But, in that case you would just have to make sure that before your code resets the Prop, it first commands SQI chip to revert to SPI mode.
hehe, yes, you just need clairvoyant code, that know it is about to get a watchdog reset, & first commands SQI chip to revert to SPI mode. This is why the ROM itself needs to have those simple reset preambles included.
RE: "Chip has said that P2 can't drive RESn, it's only an input."
I am aware that it is only an input currently, but it could be changed to a digital I/O pin that defaults to an input on power up. Once powered up code running on the P2 could pull the pin low to reset external hardware connected to the reset line without resetting the propeller. I did design a circuit to do that on a Z80 system using 7400 chips way back when, and it was pretty simple. Although I have no experience with chip design I cannot see it being all that much more difficult than it was using 7400 chips.
Yes and no.
Yes, you can add a NMOS pin Out cell, with redesign of the Ring cells.
Now, you need to selected what to drive that from ?. All pins are allocated.
So you design a new buried reset-out-node FF, that also resets, to avoid lock-up..
Now, you run your HW.
There is a CAP on RST pin, and the new FET ramps that Cap down, until the Vtl schmitt threshold is reached, then reset trips, the FET drive removes, and RST pin ramps up . Internal RST pulse is Vth-Vtl time. P2 runs.
What is at the RST pin ? - not a clean square pulse, but a less than full swing, sawtooth wave.
You need to hope the lowest voltage, is enough to also trigger other connected hardware. Not a good situation.
This can be improved, with added internal timer, that delays past the Vtl, to give time to reach ~ 0V, then release RST.
Even with all this, reset pin drive is not a magic bullet, so I'd tend to avoid this pathway, from here.
PS:
But at the end, I do not want that it seems I am forcing for reset thing. I just give some suggestions (in my bad english, so I sometimes repeat myself in different way/words) to overcome what Chip think is risky/difficult /non-standard.
I am fine with adding Pulse RST as part of preamble, but I would not want only pin-reset.
Too many parts lack that feature, and on those that do have it, it is not 100% mode active.
*Restrictive: it depends. If you do not want to bother you buy a part with hw_reset. If you buy one without you can not use QSPI or add some circuitry that with CS and !RST power cycle the part. But hw_reset works for all the parts that suport it the samw way.
Thanks, you have confirmed how restrictive this is.
*** No, the RESET low with CS not active (high) is always working, for all the parts in SPI/DSPI(SDI)/QSPI(SQI).
The Winbond data I have, explicitly says Reset does not trump QuadSPI. ie when in QuadSPI mode, reset pin feature is ignored.
"However, /HOLD or /RESET functions are only available when QE=0. If QE is set to 1, the /HOLD and /RESET functions are disabled, the pin acts as a dedicated data I/O pin."
Not that is QE, not OE, and QE is the QuadEnable mode bit.
This same data sheet DOES specify a clear software reset pathway.
It does not mention CS=H case. This is why reset-pin alone is not enough, & SW preamble is needed.
As above, that preamble can easily include a RST pulse step.
The Winbond data I have, explicitly says Reset does not trump QuadSPI. ie when in QuadSPI mode, reset pin feature is ignored.
"However, /HOLD or /RESET functions are only available when QE=0. If QE is set to 1, the /HOLD and /RESET functions are disabled, the pin acts as a dedicated data I/O pin."
Not that is QE, not OE, and QE is the QuadEnable mode bit.
This same data sheet DOES specify a clear software reset pathway.
It does not mention CS=H case. This is why reset-pin alone is not enough, & SW preamble is needed.
As above, that preamble can easily include a RST pulse step.
The Winbond part you are referring to works in StandardSPI, DualSPI and QuadSPI with QE=0. This modes uses 1bit commands (on DI or IO0). The dualSPI and QuadSPI uses IO1..IO3 only to exchange data/parameters. This means that you have always at least 8 clocks for IO0(DI) and then all the two/four lines are driven (with nibbles in case of quad mode)
When you switch QE=1 you disable the shared functions (hold/reset) and only enable(allow for) QPI mode. But you are still in SPI. You need to give the EnterQPI command in 1bit(SPI) mode to activate QPI.
From now on you are in QPI and all the commands and data are exchanged using 4bit mode (IO0..IO3). Both commands and data/parameters are transmitted/exchanged with nibbles requiring 2 clocks per byte. So to exit QPI you need a 4bit command (2 clocks). After the ExitQPI (or with cold/warm reset sw or hw (in case of 16pin device) you are back in SPI (1bit) even if QE=1, until the next EnterQPI command is transmitted.
BTW, QPI supports 66/99 but I think you should give them in 4bit, as per QPI instructions table.
Just posted a link in boot decision tree thread that details how NXP solved this problem.
Basically, they require that $FF resets SQI to SPI.
They list several vendors that support this.
So, I'd consider this a solved problem...
Okay! That is good to know. We could do that, too. Does anyone know if that covers the Winbond parts? They are the most well-stocked and least-expensive manufacturer at Digikey.
One remaining issue is: Do we drive HOLD# and WP# high on booting if we test for a 4-pin connection, or suppose pull-ups will be in place?
Boot from SPIFI:
LPC1800/4300 devices support boot from flash.The boot code sets the SPIFI clock to 32 MHz at the beginning of the boot process and checks for the type of SPI flash device. If the detected device is unknown, the SPIFI clock is reduced to 18 MHz,otherwise device boot with a SPIFI clock of 32MHz
Any device that can accept a 03 read serial opcode after receiving an FF opcode is expected to boot successfully.
A device that switches to quad opcodes and doesn't return after an 0xff reset to serial mode might not boot after a reset.
Device
Boot Support
Exit from no opcode mode
Comments
Chingis
PM25LD040, PM25LD010C, PM25LD020C, PM25LD512C, PM25LD256C, PM25LQ032C
Yes
MX25L12835F, MX25L25635F
Yes
These devices take longer time to be ready after power on. You may need to delay the startup of LPC18xx/LPC43xx.One way to achieve this sequence is to delay RESETN signal of LPC18xx/LPC43xx.
Micron
M25PX80, M25PX16, M25PX32, M25PX64, M25P10, M25P16, M25P32, M25P64, M25P80
Yes
N25Q032A, N25Q064A, N25Q128A, N25Q256A
No*
LPC18xx/LPC43xx support cold boot with these devices. May not boot when LPC18xx/LPC43xx is reset and serial flash is in no Opcode mode. In case of planned reset, MCU can get serial flash out of No Opcode mode before resetting itself.
Spansion
S25FL032P, S25FL064P, S25FL128S, S25FL256S, S25FL256S, S25FL129P, S25FL004K, S25FL008K
S25FL016K, S25FL032K, S25FL064K, S25FL116K, S25FL132K, S25FL164K,S25FL127S
Yes
One remaining issue is: Do we drive HOLD# and WP# high on booting if we test for a 4-pin connection, or suppose pull-ups will be in place?
I would enable the 100k Pullup driver on all 6 possible Flash Pins and then just send $FF in 1bit SPI mode. This will be seen from the Flash as $FF $FF $FF $FF if it is in QPI mode (IO1..3 are high because of the Pullups). After that the Flash is in SPI mode.
Next byte should be $AB = Out of DeepPowerDown. This allows to hold the Flash in Sleep if you not need it after boot.
Then can start the first Read command $03 (or $0B which is more common).
Thats all, A Lattice Ultra FPGA for example does only send the $AB command and then reads the configuration with $0B commands.
The 100k Pullups on CS# and CLK allow to check alternative boot modes later (SD, USB...) selected with a 10k Pulldown.
Just posted a link in boot decision tree thread that details how NXP solved this problem.
Basically, they require that $FF resets SQI to SPI.
They list several vendors that support this.
So, I'd consider this a solved problem...
Okay! That is good to know. We could do that, too. Does anyone know if that covers the Winbond parts? They are the most well-stocked and least-expensive manufacturer at Digikey.
One remaining issue is: Do we drive HOLD# and WP# high on booting if we test for a 4-pin connection, or suppose pull-ups will be in place?
Should work also for winbond.
If you suppose the device being in 4bit QPI mode (where commands must also be sent in 2 clocks) and you transmit "FF" only on DI(IO0) , then all the remaining 3 signals (IO1..IO3) must be high to form an "F" nibble. I think 3 weak pull-up resistors can be on this pins so you can consider a standardSPI communication. The only think is the CS must go high after 2 clocks.
So you can transmit 2 bits (ones) first, then pulse high CS (this will transmit FF in two nibbles with the helping pull-ups) and then transmit all the "FF" packet (8 bits). This should take the device out from QPI also.
Okay! That is good to know. We could do that, too. Does anyone know if that covers the Winbond parts? They are the most well-stocked and least-expensive manufacturer at Digikey.
Yes, 0xff covers most smaller parts, quad-exit.
You do need to also include 0xffff, to cover dual-exit, and 0x66,0x99 to cover newer, larger parts.
All that is simple to do, and this is then solved.
The Winbond & Macronix data I have, does not mention your 'QPI', but they do give wave forms showing a 1-bit 0x66,0x99 reset, so I am following the vendor data here.
Given the strict adjacent command caveats they apply, to me that makes this a separate reset state engine. Makes sense.
Keeps it away from any Dual-Quad modes.
Comments
But you could easily optionally map Tx onto Rx ? - to make a true one-pin, with pass/fail, and post-boot uses ....
Because the 1P loader focuses on Flash-displace, the question is does that best map onto RX pin, or one of the Flash pins (eg the one used to skip flash load, for UART-next ) ?
That frees the RX and TX pins for optional user and debug use, and keeps the boot-only path cleaner.
1-pin cases might not have any RX.TX pins, it could use ALL 63 remaining pins for user product code, and communicate on the half-duplex 1P link.
1-pin also allows low impact load of SD and USB drivers for broader future boot options..
What we have is so simple, already, in this textual loader. I don't know how to make anything simpler. I mean, a single-wire protocol would have to have some kind of timing inference, right?
About making Rx bidirectional, this would work with the PropPlug, as there's a 150-ohm series resistor on Rx, but the Prop123 boards have no resistive relief for that signal, so that would not be good. I can see using the current protocol in half-duplex on pin 61, maybe.
The small MCUs have uarts, and calibrated RC osc, but the P2 already has an autobaud scheme as the 20MHz Boot Osc is of poor precision (much worse than the small MCUs 1~2% calibrates).
Code wise, the MCU looks very like a USB-UART bridge.
For 1-pin, you map RX and TX to the same physical pin, & check you have no timing collisions, so can run half-duplex ok. The code also needs to ignore the TX, if it is captured.
The Duplex-boot choice would remain, as many user apps would require full duplex serial after boot.
To keep things simple, there is a question of where to map the 1-pin link.
I tend to favour using a SPI pin, as that allows default/documented TX.RX pins, and the 1-pin is really a memory-replacement, rather than a serial port replacement.
I meant: if someone wants to use moltiio he will buy parts with hw reset for safe boot. If he uses the parts withour reset function it is then his problem if it doesn't work.
This because imho the hw reset is easy to do (just a pulse on a pin) and is standard among various devices, you are not required to bother how to issue a "standard" sw reset accepted by all the devices regardless of the mode they are running in.
You have chosen by omission of the simple SW strings, to constrain ALL P2 users to only SOME parts, and in many cases an obtuse subset, that may not come the same next order.
Reset Pin option: Contact factory ?!
Note also that Reset pin excludes QUAD SPI modes, so you have painted users into an even smaller corner.
Demanding a HW reset pin is far too limiting, with bonus fish-hooks, but an optional reset pulse, I am fine with.
Give P2 internal control over a power supply pin..
Mess up symmetry though...
Could p2 pull down RESn during soft reset?
You mean make the RESn pin like a standard I/O pin with a pullup so it is pulled high as an input on power up and can drive external circuitry low as an output? Not a bad idea.
We could connect RESn to a p-channel mosfet's gate to apply power to SQI flash chip as long as it's high.
When RESn goes low, Prop resets and SQI power gets toggled, hopefully long enough to reset to SPI mode.
Only issue is soft reset. In that case, we'd need to Prop to pull down RESn in order to cycle power on the flash chip...
That would certainly guarantee that soft and hard reset behaved identically and be relatively simple to implement.
Not in the current completed PAD ring layout, I believe, but the general idea is useful.
Some MCUs do drive their reset pins, so that watchdog and software reset events can externally signal.
Power cycling needs a little care, as there can be varying power-up delays.
I have seen power-removal watchdogs, which could cycle power to both P2 and SPI/SD.
Given the price of niche watchdog parts, this watchdog may be better designed with a tiny, general purpose MCU.
Not an expert in this area but it seems to me that having a single transistor pull a pin low to reset external hardware without resetting the P2 should not require much logic.
Chip has said that P2 can't drive RESn, it's only an input.
Normally Supervisors IC (eg Maxim has many variants), that gives you early power fail interrupt and reset circuitry, if they not have a RES_IN and RES_OUT, the RES(OUT) have a weak series resistor between the driver and physical pin so they can detect a changing condition on reset line and start their reset delay under which the reset line is kept low.
It will be nice if the sw reset command could drive low the RESn pin. This is one thing I've queried already in 2009 for P1 in and interesting topic started by PhiPi . I hoped the this was fixed in P2 but seems that the reset circuitry is remained the same.
**From the datasheet I've locked at some parts have internal non-volatile register to choose one of the two functions: hold or reset.
Other parts have that "switch" in the ordering code so you purchase the part with hold or with reset.
*** No, the RESET low with CS not active (high) is always working, for all the parts in SPI/DSPI(SDI)/QSPI(SQI). You should not confuse QPI with QSPI(SQI). The former uses 4b for everything, the later always receive commands in 1b while exchanges data in 4b.
BTW: Even if its true that QPI disables HOLD/RESET shared pin, it needs a non-volatile preset in a register and an enabling (volatile) command under 1b mode to become active. And after a sw_reset or power-cycle it goes back to SPI (while keeping shared pin functions disabled because of the non-volatile nature of the preset register. Anyway also for QPI mode, on 16pin parts, the dedicated hw_reset pin always works, in any mode, with highest priority.
Chip doesn't want to bother with sw_reset codes and wants to set on a 3 wire communication. This will prevent any chance to use multiIO. The resistor between DI and DO is not enough in case of P2 internal sw_reset. I just want that if no flash is detected (because it could be in wrong mode) a pulse is issued on a pin (so that it can be reset/power-cycled up to developer to chose parts/circuitry that will sweet the job) and then the flash-boot is tried again.
PS:
But at the end, I do not want that it seems I am forcing for reset thing. I just give some suggestions (in my bad english, so I sometimes repeat myself in different way/words) to overcome what Chip think is risky/difficult /non-standard.
There are many gurus un this forum and whatever solution will be adopted for me is fine, unless it will prevent user-code to use multi-IO for flash. I will most probably use some kind of RAM based storage (NV/F/M) like today I am using the FM31L278 in place of eeprom on P1for many things. So the multi-IO is not only a read but also a write gain for me.
But, in that case you would just have to make sure that before your code resets the Prop, it first commands SQI chip to revert to SPI mode.
So, this scheme can still work even if the P2 can't pull down RESn on software reset...
I am aware that it is only an input currently, but it could be changed to a digital I/O pin that defaults to an input on power up. Once powered up code running on the P2 could pull the pin low to reset external hardware connected to the reset line without resetting the propeller. I did design a circuit to do that on a Z80 system using 7400 chips way back when, and it was pretty simple. Although I have no experience with chip design I cannot see it being all that much more difficult than it was using 7400 chips.
Yes and no.
Yes, you can add a NMOS pin Out cell, with redesign of the Ring cells.
Now, you need to selected what to drive that from ?. All pins are allocated.
So you design a new buried reset-out-node FF, that also resets, to avoid lock-up..
Now, you run your HW.
There is a CAP on RST pin, and the new FET ramps that Cap down, until the Vtl schmitt threshold is reached, then reset trips, the FET drive removes, and RST pin ramps up . Internal RST pulse is Vth-Vtl time. P2 runs.
What is at the RST pin ? - not a clean square pulse, but a less than full swing, sawtooth wave.
You need to hope the lowest voltage, is enough to also trigger other connected hardware. Not a good situation.
This can be improved, with added internal timer, that delays past the Vtl, to give time to reach ~ 0V, then release RST.
Even with all this, reset pin drive is not a magic bullet, so I'd tend to avoid this pathway, from here.
Too many parts lack that feature, and on those that do have it, it is not 100% mode active.
Agreed. This seems an important point to stress.
Thanks, you have confirmed how restrictive this is.
The Winbond data I have, explicitly says Reset does not trump QuadSPI. ie when in QuadSPI mode, reset pin feature is ignored.
"However, /HOLD or /RESET functions are only available when QE=0. If QE is set to 1, the /HOLD and /RESET functions are disabled, the pin acts as a dedicated data I/O pin."
Not that is QE, not OE, and QE is the QuadEnable mode bit.
This same data sheet DOES specify a clear software reset pathway.
It does not mention CS=H case. This is why reset-pin alone is not enough, & SW preamble is needed.
As above, that preamble can easily include a RST pulse step.
Basically, they require that $FF resets SQI to SPI.
They list several vendors that support this.
So, I'd consider this a solved problem...
The Winbond part you are referring to works in StandardSPI, DualSPI and QuadSPI with QE=0. This modes uses 1bit commands (on DI or IO0). The dualSPI and QuadSPI uses IO1..IO3 only to exchange data/parameters. This means that you have always at least 8 clocks for IO0(DI) and then all the two/four lines are driven (with nibbles in case of quad mode)
When you switch QE=1 you disable the shared functions (hold/reset) and only enable(allow for) QPI mode. But you are still in SPI. You need to give the EnterQPI command in 1bit(SPI) mode to activate QPI.
From now on you are in QPI and all the commands and data are exchanged using 4bit mode (IO0..IO3). Both commands and data/parameters are transmitted/exchanged with nibbles requiring 2 clocks per byte. So to exit QPI you need a 4bit command (2 clocks). After the ExitQPI (or with cold/warm reset sw or hw (in case of 16pin device) you are back in SPI (1bit) even if QE=1, until the next EnterQPI command is transmitted.
BTW, QPI supports 66/99 but I think you should give them in 4bit, as per QPI instructions table.
Okay! That is good to know. We could do that, too. Does anyone know if that covers the Winbond parts? They are the most well-stocked and least-expensive manufacturer at Digikey.
One remaining issue is: Do we drive HOLD# and WP# high on booting if we test for a 4-pin connection, or suppose pull-ups will be in place?
Boot from SPIFI:
LPC1800/4300 devices support boot from flash.The boot code sets the SPIFI clock to 32 MHz at the beginning of the boot process and checks for the type of SPI flash device. If the detected device is unknown, the SPIFI clock is reduced to 18 MHz,otherwise device boot with a SPIFI clock of 32MHz
Any device that can accept a 03 read serial opcode after receiving an FF opcode is expected to boot successfully.
A device that switches to quad opcodes and doesn't return after an 0xff reset to serial mode might not boot after a reset.
Device
Boot Support
Exit from no opcode mode
Comments
Chingis
PM25LD040, PM25LD010C, PM25LD020C, PM25LD512C, PM25LD256C, PM25LQ032C
Yes
Giga Device
GD25Q80
Yes
Macronix
MX25L6435E, MX25L8006E, MX25L1606E, MX25L8035E, MX25L1633E, MX25L3235E, MX25L6435E, MX25L12835E, MX25L25635E, MX1635E
Yes
MX25L12835F, MX25L25635F
Yes
These devices take longer time to be ready after power on. You may need to delay the startup of LPC18xx/LPC43xx.One way to achieve this sequence is to delay RESETN signal of LPC18xx/LPC43xx.
Micron
M25PX80, M25PX16, M25PX32, M25PX64, M25P10, M25P16, M25P32, M25P64, M25P80
Yes
N25Q032A, N25Q064A, N25Q128A, N25Q256A
No*
LPC18xx/LPC43xx support cold boot with these devices. May not boot when LPC18xx/LPC43xx is reset and serial flash is in no Opcode mode. In case of planned reset, MCU can get serial flash out of No Opcode mode before resetting itself.
Spansion
S25FL032P, S25FL064P, S25FL128S, S25FL256S, S25FL256S, S25FL129P, S25FL004K, S25FL008K
S25FL016K, S25FL032K, S25FL064K, S25FL116K, S25FL132K, S25FL164K,S25FL127S
Yes
SST(Microchip)
SST25VF064,SST25VF016
Yes
Winbond
W25Q80BV,W25Q16DV,W25Q32FV,W25Q64FV,W25Q128FV,W25Q256FV
Yes
Remarks: To boot from serial flashes, it is recommended that customers fully characterize the timing in their applications.
Winbond does have a new 512M-bit device that doesn't work, a W25M.
I found something from Cypress that also says Winbond will work but some Micron and maybe all Cypress don't:
http://www.cypress.com/file/197681/download
I would enable the 100k Pullup driver on all 6 possible Flash Pins and then just send $FF in 1bit SPI mode. This will be seen from the Flash as $FF $FF $FF $FF if it is in QPI mode (IO1..3 are high because of the Pullups). After that the Flash is in SPI mode.
Next byte should be $AB = Out of DeepPowerDown. This allows to hold the Flash in Sleep if you not need it after boot.
Then can start the first Read command $03 (or $0B which is more common).
Thats all, A Lattice Ultra FPGA for example does only send the $AB command and then reads the configuration with $0B commands.
The 100k Pullups on CS# and CLK allow to check alternative boot modes later (SD, USB...) selected with a 10k Pulldown.
Andy
Should work also for winbond.
If you suppose the device being in 4bit QPI mode (where commands must also be sent in 2 clocks) and you transmit "FF" only on DI(IO0) , then all the remaining 3 signals (IO1..IO3) must be high to form an "F" nibble. I think 3 weak pull-up resistors can be on this pins so you can consider a standardSPI communication. The only think is the CS must go high after 2 clocks.
So you can transmit 2 bits (ones) first, then pulse high CS (this will transmit FF in two nibbles with the helping pull-ups) and then transmit all the "FF" packet (8 bits). This should take the device out from QPI also.
You do need to also include 0xffff, to cover dual-exit, and 0x66,0x99 to cover newer, larger parts.
All that is simple to do, and this is then solved.
Your call.
Another choice is to have a 6 pin step, if the 4 pin does not detect a device
Given the strict adjacent command caveats they apply, to me that makes this a separate reset state engine. Makes sense.
Keeps it away from any Dual-Quad modes.