msrobots,
P2 only has 64 pins total, not 90+. Also, I don't think SD adds more on top of the 6 for QSPI (they overlap). Also if QSPI does end up being supported, you don't have to use it, and can still just use 4(or maybe 3) instead of 6 pins. Plus those SPI pins can overlap for multiple devices, needing only a CS pin for each.
Uups. 64 not 94. yes. Makes it even worse to loose pins.
Doesn't QSPI need the remaining pins to be driven at boot-up, instead of floating? Adding support for QSPI seems to need this, else we would not need to add anything.
A stupid question comes to my mind. Since smart pins can provide a pullup/pulldown feature, is it maybe possible to use some fuse bits to define a boot-up state for pins, so one time burned they would set pins not floating but to some known state, before anything loads?
Doesn't QSPI need the remaining pins to be driven at boot-up, instead of floating? Adding support for QSPI seems to need this, else we would not need to add anything.
Yes, but Chip has a 3 pin SPI option, which you can use if you do not need to use QSPI.
In that case, other pins do not need to be disturbed.
Once it does reset-preamble and Sig-Check for 'anyone there' and finds any flash device, it does not need to use more pins.
If 3 pin check, does not find any Sig at all, then it can try QSPI, in 1-bit mode.
A stupid question comes to my mind. Since smart pins can provide a pullup/pulldown feature, is it maybe possible to use some fuse bits to define a boot-up state for pins, so one time burned they would set pins not floating but to some known state, before anything loads?
Could save some external resistors...
Some other MCUs do have fuse-bits (flash) that configure Port Reset choices, and that is a good idea, but I think that is too late for the P2.
The PAD Ring design is done, and during RESET time, the pins float.
After RESET exit, they can be defined in software, but it takes some ms to start and run any SW.
How about some really out-of-the box thinking... Admittedly, this may be too late in the game to consider, but maybe it will spark an idea from someone else that's worth considering:
What if you had a flash chip that understood P2's serial boot protocol? It would have 4 data pins: 2 for programming the flash chip and/or pass-thru (where you connect your propplug), 2 for feeding the P2 loader. This would dramatically simplify the boot ROM, as it would only have to support serial boot. From there, the design becomes open-ended. A designer could load all 512KB from this chip, or the designer might load <2KB to bootstrap whatever other storage device they may be using (i2c, SPI, QPI, SD, Hyperbus, etc.) The advantage here is that the P2 now only requires pins 62-63 for booting, and the load time is proportional to the size of the image. Additionally, this flash chip would be programmable without using the P2.
From a practical perspective, you could probably take one of these crazy inexpensive, low-power, tiny MCUs with data flash and program it with the above functionality. If you wanted to avoid using two chips (MCU and external storage) and still get quick boots, you could get a slightly larger MCU and build a more complicated boot sequence: (1) serial load <2K bootstrap, (2) switch both MCU and P2 to higher-speed mode (SPI, QPI, etc.), (3) continue loading. And, of course, after loading, the MCU could technically become available for other uses (e.g. high-speed, high-resolution ADC).
Of course, it seems wrong to use another MCU to bootstrap the P2, but I suspect it would be impractical for Parallax to create a custom flash chip that could provide the same functionality.
The main point is... maybe trying to put more in the boot ROM is the opposite of what we should be doing. Or maybe not. As I said, this thought was a bit out there. It's more to get the mental juices flowing than anything else...
4.6Reset (/RESET)
The /RESET pin allows the device to be reset by the controller. For 8-pin packages, when QE=0, the IO3 pin can be configured either as a /HOLD pin or as a /RESET pin depending on Status Register setting. When QE=1, the /HOLD or /RESET function is not available for 8-pin configuration. On the 16-pin SOIC package, a dedicated /RESET pin is provided and it is independent of QE bit setting.
6.1.4 QPI Instructions
...
To enable QPI mode, the non-volatile Quad Enable bit (QE) in Status Register-2 is required to be set. When using QPI instructions, the DI and DO pins become bidirectional IO0 and IO1, and the /WP and /HOLD pins become IO2 and IO3 respectively
6.1.5 Hold Function
...
The Chip Select (/CS) signal should be kept active (low) for the full duration of the /HOLD operation to avoid resetting the internal logic state of the device.
6.1.6 Software Reset & Hardware /RESET pin
... Hardware /RESET pin has the highest priority among all the input signals. Drive /RESET low for a minimum period of ~1us (tRESET*) will interrupt any on-going external/internal operations, regardless the status of other SPI signals (/CS, CLK, IOs, /WP and/or /HOLD).
7.1.10Quad Enable (QE) – Volatile/Non-Volatile Writable
The Quad Enable (QE) bit is a non-volatile read/write bit in the status register (S9) that allows Quad SPI and QPI operation. When the QE bit is set to a 0 state (factory default for part number with ordering options “IG”,”IP” and “IF”), the /WP pin and /HOLD are enabled. When the QE bit is set to a 1(factory default for Quad Enabled part numbers with ordering option “IQ”), the Quad IO2 and IO3 pins are enabled, and /WP and /HOLD functions are disabled.
QE bit is required to be set to a 1 before issuing an “Enter QPI (38h)” to switch the device from Standard/Dual/Quad SPI to QPI, otherwise the command will be ignored. When the device is in QPI mode, QE bit will remain to be 1. A “Write Status Register” command in QPI mode cannot change QE bit from a “1” to a “0”.
7.1.13 /HOLD or /RESET Pin Function (HOLD/RST) – Volatile/Non-Volatile Writable The HOLD/RST bit is used to determine whether /HOLD or /RESET function should be implemented on the hardware pin for 8-pin packages. When HOLD/RST=0 (factory default), the pin acts as /HOLD; when HOLD/RST=1, the pin acts as /RESET. 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.
The Winbond (and ISSI) differentiate between QuadSPI and QPI, the former accept commands only on DI while the latter uses also for commands 4b mode. In QPI shared RESET on IO3 is not available while it works in QuadSPI.
There is a register bit to set to chose between HOLD or RESET. It defaults to HOLD.
To enter QPI you first need to set a register (QE) and than issue an enter command in 1b mode. To exit from QPI the command must of course be in 4b mode.
A RESET (sw or hw) will revert the chip back to standard SPI but because of the non-volatile nature of QE the only available hw reset is the dedicated pin of 16pin parts, because the QE=1 disables the shared hw reset on pin IO3
While in standard/dual/quadSPI mode with QE=0 a low condition on IO3 while CS is hogh will reset the part
Hold (HOLD) or Reset (Reset)
...
Reset functionality is present instead of Hold in devices with a dedicated part number. See Section 16: Ordering information.
...
When Reset (Reset) is driven High, the memory is in the normal operating mode. When Reset (Reset) is driven Low, the memory will enter the Reset mode. In this mode, the output is high impedance.
Driving Reset (Reset) Low while an internal operation is in progress will affect this operation (write, program or erase cycle) and data may be lost.
In the Extended SPI protocol, during the QOFR, QIOFR, QIFP and the Quad Extended Fast Program (QIEFP) instructions, the Hold (Reset) / DQ3 is used as an input/output (DQ3 functionality). In QIO-SPI, the Hold (Reset) / DQ3 pin acts as an I/O (DQ3 functionality), and the HOLD (Reset) functionality disabled when the device is selected. When the device is deselected (S signal is high), in parts with Reset functionality, it is possible to reset the device unless this functionality is not disabled by mean of dedicated registers bits. The HOLD (Reset) functionality can be disabled using bit 3 of the NVCR or bit 4 of the VECR.
You need to order the flash with RESET instead of HOLD, but the function is enabled by default and you can disable it using the registers.
2.3 Hardware Reset (RESET#)
The RESET# input provides a hardware method of resetting the device to standby state, ready for receiving a command. When RESET# is driven to logic low (VIL) for at least a period of tRP, the device:
terminates any operation in progress,
tristates all outputs,
resets the volatile bits in the Configuration Register,
resets the volatile bits in the Status Registers,
resets the Bank Address Register to 0,
loads the Program Buffer with all 1s,
reloads all internal configuration information necessary to bring the device to standby mode,
and resets the internal Control Unit to standby state. RESET# causes the same initialization process as is performed when power comes up and requires tPU time. RESET# may be asserted low at any time. To ensure data integrity any operation that was interrupted by a hardware reset should be reinitiated once the device is ready to accept a command sequence.
When RESET# is first asserted Low, the device draws ICC1 (50 MHz value) during tPU. If RESET# continues to be held at VSS the device draws CMOS standby current (ISB).
RESET# has an internal pull-up resistor and should be left unconnected in the host system if not used.
The RESET# input is not available on all packages options. When not available the RESET# input of the device is tied to the inactive state, inside the package.
2.9 Hold (HOLD#) / IO3 / RESET#
... The HOLD# input and function is available when enabled by a configuration bit SR2[5] =0. ... If the CS# input is driven to the logic high state while the device is in the Hold condition, the interface logic of the device will be reset.
... The HOLD# function is not available when the Quad mode is enabled (CR1[1] =1). .... A configuration bit SR2[5] may be set to 1 to replace the HOLD# / IO3 functions with the IO3 / RESET# functions. Then the IO3 / RESET# may be used to initiate the hardware reset function. The IO3 / RESET# input is only treated as RESET# when the device is not in Quad-I/O mode, CR1[1] = 0, or when CS# is high. When Quad I/O mode is in use, CR1[1]=1, and the device is selected with CS# low, the IO3 / RESET# is used only as IO3 for information transfer. When CS# is high, the IO3 / RESET# is not in use for information transfer and is used as the RESET# input. By conditioning the reset operation on CS# high during Quad mode, the reset function remains available during Quad mode.
When the system enters a reset condition, the CS# signal must be driven high as part of the reset process and the IO3 / RESET# signal is driven low. When CS# goes high the IO3 / RESET# input transitions from being IO3 to being the RESET# input. The reset condition is then detected when CS# remains high and the IO3 / RESET# signal remains low for tRP.
The HOLD#/IO3 or IO3/RESET# signals have an internal pull-up resistor and may be left unconnected in the host system if not used for Quad mode or the reset function.
When Quad mode is enabled, IO3 / RESET# is ignored for tCS following CS# going high. This allows some time for the memory or host system to actively drive IO3 / RESET# to a valid level following the end of a transfer. Following the end of a Quad I/O read the memory will actively drive IO3 high before disabling the output during tDIS. Following a transfer in which IO3 was used to transfer data to the memory, e.g. the QPP command, the host system is responsible for driving IO3 high before disabling the host IO3 output. ...
3.3.4 Hardware (Warm) Reset
Some of the device package options provide a RESET# input. When RESET# is driven low for tRP time the device starts the hardware reset process. The process continues for tRPH time. Following the end of both tRPH and the reset hold time following the rise of RESET# (tRH) the device transitions to the Interface Standby state and can accept commands. ...
A configuration option is provided to allow IO3 to be used as a hardware reset input when the device is not in Quad mode or when it is in Quad mode and CS# is high. When IO3 / RESET# is driven low for tRP time the device starts the hardware reset process. ...
5.3.3 IO3 / RESET# Input Initiated Hardware (Warm) Reset The IO3 / RESET# signal functions as a RESET# input when enabled by SR2[5]=1 and CS# is high for more than tCS time or when Quad Mode is not enabled (CR1V[1]=0). The IO3 RESET# input provides a hardware method of resetting the flash memory device to standby state. ... When the IO3 / RESET# feature and Quad mode are both enabled, IO3 / RESET# is ignored for tCS following CS# going high, to avoid an unintended Reset operation. ... When the device is not in quad mode or when CS# is high, and the IO3 / RESET# transitions from VIH to VIL for > tRP, the device terminates any operation in progress, makes all outputs high impedance, ignores all read/write commands and resets the interface to standby state. The hardware reset process requires a period of tRPH to complete. During tRPH, the device will reset register states in the same manner as power-on reset but, does not go through the full reset process that is performed during POR. If the POR process did not complete correctly for any reason during power-up (tPU), RESET# going low for tRP will initiate the full POR process instead of the hardware reset process and will require tPU to complete the POR process. ...
Cypress also allows for sw selection between HOLD or RESET functions. It only have standard/dual/quadSPI and do not support QPI. Reset works while in multiIO modes.
I've been reading about this HOLD#/RESET#/DQ3 issue.
1) If I am reading right, this alternate RESET# option is set by a non-volatile bit for the Winbond and Mircron parts.
2) For the ISSI part, I see this note: "For RESET# pin option instead of HOLD# pin, call Factory."
3) 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.
4) 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.
To answer:
1) Winbond have an internal no-volatile bit to select between HOLD or RESET, for Micron it depends on ordering code 1-2=hold; 3-4=reset
2) ISSI doesn't support hw reset (shared nor dedicated), only sw reset available.
3) Yes, but you should not confuse standard/dual/quadSPI with QPI(Quad Peripheral Interface). The former receives commands on single line while exchanges data on 1/2/4 lines. The latter uses 4 lines for both commands and data.
4) For certain manufacturers (eg winbond) requires to program the part once (non-volatile) to select between HOLD or RESET shared function. This don't have to be part of the ROM. The user that needs to use QSPI will change this bit once with a program loaded to P2 ram.
For other manufacturers that availability of HOLD or RESET depends on the ordering code (eg micron).
So I still think that the safest way is to use the hw reset. The ROM code should drive the shared reset pulse, if the user will chose a 16-pin part with dedicated reset pin he will figure out how to drive it.
Regarding the 3/4/6 pin interface I think you can use a 3 pin interface with this assumptions/fulfillments:
- a resistor is connected between DI and DO that allows for direct DO connection to a second pin (P57)
- if you do not recognise a 3 wire device you should first issue a reset pulse with CS (P61) high on IO3 (P59) and repeat boot in standard SPI
- even in case of 3 wires the DI/DO signal is on P56 thus alloving for further expansion to 6 wire interface with properly aligned nibbles.
- clock is of course on P60
Using the RESET you do not have to bother for anything: issue a reset, wait a bit and start booting in standardSPI, with any device.
This scheme allows any brand in standard/dual/quadSPI. For the ones that want to use also the QPI will bought a 16-pin part with dedicated RESET or they will power cycle the device based on your reset pulse (CS high, IO3 low): how is a designer problem, you don't have to worry about this, just give the information.
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.
If you use eg an external uC supervisor/watchdog IC the user have no control when the reset will be issued. So no way to revert back to SPI prior to the next boot. That means that multiIO is not usable. A simple reset pulse could solve this problem and alleviates the boot code from issuing proper sw reset/exit codes for various flash chips.
Now think about the QuadSPI requirement with all prohibitions issued by the people:
- only 3 wire flash that prevents QSPI/QPI use
- no SD boot
A system that want fast flash with possibility for field upgrades and/or removable storage will end out having 2 flash chips and a SD socket ... I can't give any opinion over this because my english is not good enough to express all this nonsense.
BTW while others are mentioning double-die P2 chips with in-built eeprom/flash/opt have you ever considered a fram? Cypress offers also wafer/die parts: http://www.cypress.com/products/f-ram-and-nvsram-wafer-and-die-support
... and if all the ram will be non-volatile we will not have any issue regarding flash and other storage media. Now 20ns (translates to 50MHz) perhaps a bit slow for the main hub ram but perhaps other faster manufacturers/technologies exists that I am not aware of.
issue WRITE_DISABLE ($04)
issue READ_STATUS ($05)
if WEL (bit 1) = 1, abort flash boot
if BUSY (bit 0) = 1, loop to READ_STATUS
issue READ ($03)
read $F8 longs into LUT $100..$1F7
read 32 bytes for signature
verify signature
if failed, abort flash boot
jump to $300 (LUT $100)
The purpose of the WRITE_DISABLE is to make a contrast between WEL and BUSY (from READ_STATUS), in case a 'program' or 'erase' is still in progress, from before a warm reset. If WEL=1 after WRITE_DISABLE, something is wrong or there is no flash chip connected, so exit. However, if WEL=0 and BUSY=1, a program/erase must be in progress and will be waited through. This eliminates the need for various 'reset' commands, which vary by vendor, and allows any program/erase in progress to complete.
If both WEL=0 and BUSY=0, it should be okay to load data, assuming a flash chip is even connected. The SHA-256/HMAC signature will tell us, for sure, if there was a flash chip and if it had good data in it. In case everything checks out, a jump to $300 occurs, turning control over to the new loader code. That code can simply turn on the crystal and PLL and resume loading from $400 in the flash chip, using smart pins to really get things sped up.
I know this inhibits QPI (somewhat), and certainly discourages it. For most all applications, a 40MB/s ROM is just not needed over a 10MB/s ROM, and so is not worth disturbing three more pins on reset for. I think, anyway.
Regarding the 3/4/6 pin interface I think you can use a 3 pin interface with this assumptions/fulfillments:
- a resistor is connected between DI and DO that allows for direct DO connection to a second pin (P57)
- if you do not recognise a 3 wire device you should first issue a reset pulse with CS (P61) high on IO3 (P59) and repeat boot in standard SPI
- even in case of 3 wires the DI/DO signal is on P56 thus alloving for further expansion to 6 wire interface with properly aligned nibbles.
- clock is of course on P60
Sounds fine to me, to also issue a Pulse on a possible reset pin, as one part of the reset preamble process.
I have been reading the S25FL116K / 132K / 164K spec.
The HOLD# and WP# (IO3 and IO2) have internal resistors allowing these pins to float (ie not connected).
This then gives us a standard 4 wire SPI connection. Provided the pins are allocated correctly by the prop, the user can use Quad mode if they choose.
I very much dislike the option of joining DI and DO by any means.
My preference is for the ROM boot code to check for FLASH and if not found, check for SD. Provided you choose FLASH or SD then the same pins can be used.
As I said before, I do not want any flash on my boards, just microSD.
All this might be simply resolved if OnSemi have flash/EEPROM/OTP standard cells that can be placed on the die for minimal cost. We only require enough space for boot code.
Programming could even be part of the Parallax testing procedure, including boot variants if desired. This question has not even been asked. It could even be as simple as swapping LUT for FLASH/EEPROM/OTP on COG#0 on boot/reset and executing it - no serial loader from ROM or time to load it!
I know this inhibits QPI (somewhat), and certainly discourages it.
The above is fine but it does not have to stop at 3 bit, and abort.
There is no need to paint the P2 into a subset corner, by skipping QSPI.
It should first check for 3 bit connected Flash and then try Quad, and if you really want to skip flash entirely for Serial-only apps (rare) then the pin-boot mapping can include that.
The user gets full control, and they can choose how many pins to allocate to flash.
This would dramatically simplify the boot ROM, as it would only have to support serial boot.
I'm not sure that small is that critical here, the ROM is easily tested, and flexible easily trumps small, when it comes to booting any device.
What is important to avoid, is crippling the end-uses of what is a extremely flexible P2, by taking shortcuts in the ROM.
How about some really out-of-the box thinking... Admittedly, this may be too late in the game to consider, but maybe it will spark an idea from someone else that's worth considering:
What if you had a flash chip that understood P2's serial boot protocol? It would have 4 data pins: 2 for programming the flash chip and/or pass-thru (where you connect your propplug), 2 for feeding the P2 loader. This would dramatically simplify the boot ROM, as it would only have to support serial boot. From there, the design becomes open-ended. A designer could load all 512KB from this chip, or the designer might load <2KB to bootstrap whatever other storage device they may be using (i2c, SPI, QPI, SD, Hyperbus, etc.) The advantage here is that the P2 now only requires pins 62-63 for booting, and the load time is proportional to the size of the image. Additionally, this flash chip would be programmable without using the P2.
From a practical perspective, you could probably take one of these crazy inexpensive, low-power, tiny MCUs with data flash and program it with the above functionality.....
... It's more to get the mental juices flowing than anything else...
Worth thinking about, and I can see merit in a variant of this, which would be a ONE-PIN Boot support.
There will be P2 applications where even serial / flash pins are a load users prefer to avoid, and the smallest possible boot is one-pin.
You can get 16kB Flash MCUs now, for 28c/1k, which is a lot of P2 code.
As in 3-pin Flash, checking for presence of one-pin device, is quick and small.
Such One-pin code could use substantial parts of the UART protocol.
Addit: One-pin-present check could be as simple as sending a single-bit ping, (nom 8.68us for 115200, supported on the 28c MCU) on one pin, set to modest drive, and listen for (eg) a 0x55 echo, with ~175us timeout.
( Which one of RXD, or SPI_CS or SPI_CK pin ? - I'd guess the corner 'flash' pin for lowest pin-impact )
Any conventional part connected would ignore the pulse, a One-Pin boot slave, gives the echo.
It could even be as simple as swapping LUT for FLASH/EEPROM/OTP on COG#0 on boot/reset and executing it - no serial loader from ROM or time to load it!
Very unlikely. ROM is an IP block.
Any change from ROM, needs a means to program the memory, and most cells need not just the memory but also charge pumps for erase.
OTP might save on erase options, but even this still needs some yield coverage.
- ie if your OTP has one bad cell, do you want to scrap a whole P2 ?
I could see extra (niche) markets for an OTP version, (XMOS have a OTP cell ) but maybe on P3 ?
ROM is simple, one-way, and reliable (hopefully), with highest yields.
I have been reading the S25FL116K / 132K / 164K spec.
The HOLD# and WP# (IO3 and IO2) have internal resistors allowing these pins to float (ie not connected).
This then gives us a standard 4 wire SPI connection. Provided the pins are allocated correctly by the prop, the user can use Quad mode if they choose.
I very much dislike the option of joining DI and DO by any means.
My preference is for the ROM boot code to check for FLASH and if not found, check for SD. Provided you choose FLASH or SD then the same pins can be used.
As I said before, I do not want any flash on my boards, just microSD.
All this might be simply resolved if OnSemi have flash/EEPROM/OTP standard cells that can be placed on the die for minimal cost. We only require enough space for boot code.
Programming could even be part of the Parallax testing procedure, including boot variants if desired. This question has not even been asked. It could even be as simple as swapping LUT for FLASH/EEPROM/OTP on COG#0 on boot/reset and executing it - no serial loader from ROM or time to load it!
I have been reading the S25FL116K / 132K / 164K spec.
The HOLD# and WP# (IO3 and IO2) have internal resistors allowing these pins to float (ie not connected).
This then gives us a standard 4 wire SPI connection. Provided the pins are allocated correctly by the prop, the user can use Quad mode if they choose.
I very much dislike the option of joining DI and DO by any means.
My preference is for the ROM boot code to check for FLASH and if not found, check for SD. Provided you choose FLASH or SD then the same pins can be used.
As I said before, I do not want any flash on my boards, just microSD.
All this might be simply resolved if OnSemi have flash/EEPROM/OTP standard cells that can be placed on the die for minimal cost. We only require enough space for boot code.
Programming could even be part of the Parallax testing procedure, including boot variants if desired. This question has not even been asked. It could even be as simple as swapping LUT for FLASH/EEPROM/OTP on COG#0 on boot/reset and executing it - no serial loader from ROM or time to load it!
Cluso, have you been working on SD booting?
I have been on this every spare moment I have had. I am not happy with the initialisation that I have as it needs to run twice and I haven't found the key to this yet even though it always runs on from eeprom boot fine. I want it to be bullet proof !
BUT I have spent a huge amount of time over the past 2 weeks just trying to get Windows 10 to play nicely with Outlook (Office 365). Outlook fails on launch since the recent update. MS have beeen helping to diagnose the problem as no access to my old emails and access to my new ones via webmail in not fun. Rollback W10, deleting and reinstalling Office 365, and loading MS test programs and sending log files.
Anyway, I found a workaround that works in my case since I have a metered connection, while MS tries to find and solve the problem.
.... I am not happy with the initialisation that I have as it needs to run twice and I haven't found the key to this yet even though it always runs on from eeprom boot fine. I want it to be bullet proof !
A possible idea, is I noticed the larger parts spec a delay of 30us (?!) from Dual-byte Reset (66h,99h) command.
(What is the part doing, that needs 30us ??)
Seems these parts get more complex than simple memories, SD may be similar/worse.
A slow init step, could explain needing 2 passes ?
I have been reading the S25FL116K / 132K / 164K spec.
The HOLD# and WP# (IO3 and IO2) have internal resistors allowing these pins to float (ie not connected).
This then gives us a standard 4 wire SPI connection. Provided the pins are allocated correctly by the prop, the user can use Quad mode if they choose.
I very much dislike the option of joining DI and DO by any means.
My preference is for the ROM boot code to check for FLASH and if not found, check for SD. Provided you choose FLASH or SD then the same pins can be used.
As I said before, I do not want any flash on my boards, just microSD.
All this might be simply resolved if OnSemi have flash/EEPROM/OTP standard cells that can be placed on the die for minimal cost. We only require enough space for boot code.
Programming could even be part of the Parallax testing procedure, including boot variants if desired. This question has not even been asked. It could even be as simple as swapping LUT for FLASH/EEPROM/OTP on COG#0 on boot/reset and executing it - no serial loader from ROM or time to load it!
Cluso, have you been working on SD booting?
I have been on this every spare moment I have had. I am not happy with the initialisation that I have as it needs to run twice and I haven't found the key to this yet even though it always runs on from eeprom boot fine. I want it to be bullet proof !
BUT I have spent a huge amount of time over the past 2 weeks just trying to get Windows 10 to play nicely with Outlook (Office 365). Outlook fails on launch since the recent update. MS have beeen helping to diagnose the problem as no access to my old emails and access to my new ones via webmail in not fun. Rollback W10, deleting and reinstalling Office 365, and loading MS test programs and sending log files.
Anyway, I found a workaround that works in my case since I have a metered connection, while MS tries to find and solve the problem.
Sounds like it's moving forward well.
Sorry about your Win 10 problems. I don't know about you, but I get so worn down with idiotic computer behavior that it almost makes me not want to work, sometimes; hence, my pipe dream of having the Prop2 self-hosting, to leave the diseased state of personal computing behind. Meanwhile, web-based IDE's are becoming popular, which seem even more tenuous.
Sorry about your Win 10 problems. I don't know about you, but I get so worn down with idiotic computer behavior that it almost makes me not want to work, sometimes; hence, my pipe dream of having the Prop2 self-hosting, to leave the diseased state of personal computing behind. Meanwhile, web-based IDE's are becoming popular, which seem even more tenuous.
I don't like the idea that I require an internet connection to do anything. I'd rather have a local option.
I have been on this every spare moment I have had. I am not happy with the initialisation that I have as it needs to run twice and I haven't found the key to this yet even though it always runs on from eeprom boot fine. I want it to be bullet proof !
BUT I have spent a huge amount of time over the past 2 weeks just trying to get Windows 10 to play nicely with Outlook (Office 365). Outlook fails on launch since the recent update. MS have beeen helping to diagnose the problem as no access to my old emails and access to my new ones via webmail in not fun. Rollback W10, deleting and reinstalling Office 365, and loading MS test programs and sending log files.
Anyway, I found a workaround that works in my case since I have a metered connection, while MS tries to find and solve the problem.
Sorry, I've been caught up in a job but I will try and jump into this in the next couple of days. I do know that I have had to issue dummy writes just for the extra few clocks that some cards need as some systems output a continuous clock, even when they are not accessing the card.
issue WRITE_DISABLE ($04)
issue READ_STATUS ($05)
if WEL (bit 1) = 1, abort flash boot
if BUSY (bit 0) = 1, loop to READ_STATUS
issue READ ($03)
read $F8 longs into LUT $100..$1F7
read 32 bytes for signature
verify signature
if failed, abort flash boot
jump to $300 (LUT $100)
The purpose of the WRITE_DISABLE is to make a contrast between WEL and BUSY (from READ_STATUS), in case a 'program' or 'erase' is still in progress, from before a warm reset. If WEL=1 after WRITE_DISABLE, something is wrong or there is no flash chip connected, so exit. However, if WEL=0 and BUSY=1, a program/erase must be in progress and will be waited through. This eliminates the need for various 'reset' commands, which vary by vendor, and allows any program/erase in progress to complete.
If both WEL=0 and BUSY=0, it should be okay to load data, assuming a flash chip is even connected. The SHA-256/HMAC signature will tell us, for sure, if there was a flash chip and if it had good data in it. In case everything checks out, a jump to $300 occurs, turning control over to the new loader code. That code can simply turn on the crystal and PLL and resume loading from $400 in the flash chip, using smart pins to really get things sped up.
I know this inhibits QPI (somewhat), and certainly discourages it. For most all applications, a 40MB/s ROM is just not needed over a 10MB/s ROM, and so is not worth disturbing three more pins on reset for. I think, anyway.
Couldn't the code be slightly modified:
issue READ_STATUS ($05)
if BUSY (bit 0) = 1, loop to READ_STATUS
if WEL (bit 1)=1 & !fRst, set fRst, issue hw_rst_pls(P59), wait_tRst, restart_procedure
if WEL (bit 1)=1 & fRst, abort flash boot
Using the RESET you do not have to bother for anything: issue a reset, wait a bit and start booting in standardSPI, with any device.
HW reset is useful, but you should also do the other reset-preambles, in case the part does not have Pin-reset ability. Not all do.
In case the part is missing the hw reset it will most probably not be used in multIO so nothing to reset except a pending write(program/erase) as Chip is already doing.
Anyway, if someone wants to use cheaper parts, without hw reset option, in multiIO mode he can provide circuitry to power-cycle the flash driven by the "!RST & CS" signals.
Sorry about your Win 10 problems. I don't know about you, but I get so worn down with idiotic computer behavior that it almost makes me not want to work, sometimes; hence, my pipe dream of having the Prop2 self-hosting, to leave the diseased state of personal computing behind. Meanwhile, web-based IDE's are becoming popular, which seem even more tenuous.
I don't like the idea that I require an internet connection to do anything. I'd rather have a local option.
Seconded.
And i'm not anti. Where those options exist, I will use them at times. Options are good. But, running local is what I trust, and I can secure a state and keep it. That's the most important thing.
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...
Worth thinking about, and I can see merit in a variant of this, which would be a ONE-PIN Boot support.
I really love this idea.
Yes, easy to check & skip over, but lets users get all all those smart pins !!
I'll start a new P2 Boot tree suggestion thread, that merges the comments/suggestions in this one.
issue READ_STATUS ($05)
if BUSY (bit 0) = 1, loop to READ_STATUS
if WEL (bit 1)=1 & !fRst, set fRst, issue hw_rst_pls(P59), wait_tRst, restart_procedure
if WEL (bit 1)=1 & fRst, abort flash boot
and P56 being used instead of P59 for DI&DO?
The WRITE_DISABLE is needed to create a contrast with BUSY. If no chip is connected, WEL and BUSY will both read high or low, as nothing is driving a state change. To have WEL=0 and then BUSY=1 means that a part is really connected, and it is busy in an erase/write operation, so it is necessary to wait for completion before attempting to read the boot loader. This gets around the need for any reset mechanism or commands.
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.
Comments
P2 only has 64 pins total, not 90+. Also, I don't think SD adds more on top of the 6 for QSPI (they overlap). Also if QSPI does end up being supported, you don't have to use it, and can still just use 4(or maybe 3) instead of 6 pins. Plus those SPI pins can overlap for multiple devices, needing only a CS pin for each.
Doesn't QSPI need the remaining pins to be driven at boot-up, instead of floating? Adding support for QSPI seems to need this, else we would not need to add anything.
A stupid question comes to my mind. Since smart pins can provide a pullup/pulldown feature, is it maybe possible to use some fuse bits to define a boot-up state for pins, so one time burned they would set pins not floating but to some known state, before anything loads?
Could save some external resistors...
Enjoy!
Mike
In that case, other pins do not need to be disturbed.
Once it does reset-preamble and Sig-Check for 'anyone there' and finds any flash device, it does not need to use more pins.
If 3 pin check, does not find any Sig at all, then it can try QSPI, in 1-bit mode.
Some other MCUs do have fuse-bits (flash) that configure Port Reset choices, and that is a good idea, but I think that is too late for the P2.
The PAD Ring design is done, and during RESET time, the pins float.
After RESET exit, they can be defined in software, but it takes some ms to start and run any SW.
What if you had a flash chip that understood P2's serial boot protocol? It would have 4 data pins: 2 for programming the flash chip and/or pass-thru (where you connect your propplug), 2 for feeding the P2 loader. This would dramatically simplify the boot ROM, as it would only have to support serial boot. From there, the design becomes open-ended. A designer could load all 512KB from this chip, or the designer might load <2KB to bootstrap whatever other storage device they may be using (i2c, SPI, QPI, SD, Hyperbus, etc.) The advantage here is that the P2 now only requires pins 62-63 for booting, and the load time is proportional to the size of the image. Additionally, this flash chip would be programmable without using the P2.
From a practical perspective, you could probably take one of these crazy inexpensive, low-power, tiny MCUs with data flash and program it with the above functionality. If you wanted to avoid using two chips (MCU and external storage) and still get quick boots, you could get a slightly larger MCU and build a more complicated boot sequence: (1) serial load <2K bootstrap, (2) switch both MCU and P2 to higher-speed mode (SPI, QPI, etc.), (3) continue loading. And, of course, after loading, the MCU could technically become available for other uses (e.g. high-speed, high-resolution ADC).
Of course, it seems wrong to use another MCU to bootstrap the P2, but I suspect it would be impractical for Parallax to create a custom flash chip that could provide the same functionality.
The main point is... maybe trying to put more in the boot ROM is the opposite of what we should be doing. Or maybe not. As I said, this thought was a bit out there. It's more to get the mental juices flowing than anything else...
There is a register bit to set to chose between HOLD or RESET. It defaults to HOLD.
To enter QPI you first need to set a register (QE) and than issue an enter command in 1b mode. To exit from QPI the command must of course be in 4b mode.
A RESET (sw or hw) will revert the chip back to standard SPI but because of the non-volatile nature of QE the only available hw reset is the dedicated pin of 16pin parts, because the QE=1 disables the shared hw reset on pin IO3
While in standard/dual/quadSPI mode with QE=0 a low condition on IO3 while CS is hogh will reset the part
Micron p.17 ( N25Q128Ab]3/4[/b... ) You need to order the flash with RESET instead of HOLD, but the function is enabled by default and you can disable it using the registers.
Cypress p.10..11, 23, 33 Cypress also allows for sw selection between HOLD or RESET functions. It only have standard/dual/quadSPI and do not support QPI. Reset works while in multiIO modes.
To answer:
1) Winbond have an internal no-volatile bit to select between HOLD or RESET, for Micron it depends on ordering code 1-2=hold; 3-4=reset
2) ISSI doesn't support hw reset (shared nor dedicated), only sw reset available.
3) Yes, but you should not confuse standard/dual/quadSPI with QPI(Quad Peripheral Interface). The former receives commands on single line while exchanges data on 1/2/4 lines. The latter uses 4 lines for both commands and data.
4) For certain manufacturers (eg winbond) requires to program the part once (non-volatile) to select between HOLD or RESET shared function. This don't have to be part of the ROM. The user that needs to use QSPI will change this bit once with a program loaded to P2 ram.
For other manufacturers that availability of HOLD or RESET depends on the ordering code (eg micron).
So I still think that the safest way is to use the hw reset. The ROM code should drive the shared reset pulse, if the user will chose a 16-pin part with dedicated reset pin he will figure out how to drive it.
Regarding the 3/4/6 pin interface I think you can use a 3 pin interface with this assumptions/fulfillments:
- a resistor is connected between DI and DO that allows for direct DO connection to a second pin (P57)
- if you do not recognise a 3 wire device you should first issue a reset pulse with CS (P61) high on IO3 (P59) and repeat boot in standard SPI
- even in case of 3 wires the DI/DO signal is on P56 thus alloving for further expansion to 6 wire interface with properly aligned nibbles.
- clock is of course on P60
Using the RESET you do not have to bother for anything: issue a reset, wait a bit and start booting in standardSPI, with any device.
This scheme allows any brand in standard/dual/quadSPI. For the ones that want to use also the QPI will bought a 16-pin part with dedicated RESET or they will power cycle the device based on your reset pulse (CS high, IO3 low): how is a designer problem, you don't have to worry about this, just give the information.
Now think about the QuadSPI requirement with all prohibitions issued by the people:
- only 3 wire flash that prevents QSPI/QPI use
- no SD boot
A system that want fast flash with possibility for field upgrades and/or removable storage will end out having 2 flash chips and a SD socket ... I can't give any opinion over this because my english is not good enough to express all this nonsense.
BTW while others are mentioning double-die P2 chips with in-built eeprom/flash/opt have you ever considered a fram? Cypress offers also wafer/die parts: http://www.cypress.com/products/f-ram-and-nvsram-wafer-and-die-support
... and if all the ram will be non-volatile we will not have any issue regarding flash and other storage media. Now 20ns (translates to 50MHz) perhaps a bit slow for the main hub ram but perhaps other faster manufacturers/technologies exists that I am not aware of.
If you do a 'CLKSET D/#' with bit 8 set, it causes a hardware reset. That's the only way to reboot from software.
Here is what I want to do, because it will work with every part out there:
Pin61 = SPI_CS
Pin60 = SPI_CK
Pin59 = SPI_DI and SPI_DO (tied together)
Boot procedure:
The purpose of the WRITE_DISABLE is to make a contrast between WEL and BUSY (from READ_STATUS), in case a 'program' or 'erase' is still in progress, from before a warm reset. If WEL=1 after WRITE_DISABLE, something is wrong or there is no flash chip connected, so exit. However, if WEL=0 and BUSY=1, a program/erase must be in progress and will be waited through. This eliminates the need for various 'reset' commands, which vary by vendor, and allows any program/erase in progress to complete.
If both WEL=0 and BUSY=0, it should be okay to load data, assuming a flash chip is even connected. The SHA-256/HMAC signature will tell us, for sure, if there was a flash chip and if it had good data in it. In case everything checks out, a jump to $300 occurs, turning control over to the new loader code. That code can simply turn on the crystal and PLL and resume loading from $400 in the flash chip, using smart pins to really get things sped up.
I know this inhibits QPI (somewhat), and certainly discourages it. For most all applications, a 40MB/s ROM is just not needed over a 10MB/s ROM, and so is not worth disturbing three more pins on reset for. I think, anyway.
Looking forward to the next FPGA build.
Sounds fine to me, to also issue a Pulse on a possible reset pin, as one part of the reset preamble process.
HW reset is useful, but you should also do the other reset-preambles, in case the part does not have Pin-reset ability. Not all do.
The HOLD# and WP# (IO3 and IO2) have internal resistors allowing these pins to float (ie not connected).
This then gives us a standard 4 wire SPI connection. Provided the pins are allocated correctly by the prop, the user can use Quad mode if they choose.
I very much dislike the option of joining DI and DO by any means.
My preference is for the ROM boot code to check for FLASH and if not found, check for SD. Provided you choose FLASH or SD then the same pins can be used.
As I said before, I do not want any flash on my boards, just microSD.
All this might be simply resolved if OnSemi have flash/EEPROM/OTP standard cells that can be placed on the die for minimal cost. We only require enough space for boot code.
Programming could even be part of the Parallax testing procedure, including boot variants if desired. This question has not even been asked. It could even be as simple as swapping LUT for FLASH/EEPROM/OTP on COG#0 on boot/reset and executing it - no serial loader from ROM or time to load it!
There is no need to paint the P2 into a subset corner, by skipping QSPI.
It should first check for 3 bit connected Flash and then try Quad, and if you really want to skip flash entirely for Serial-only apps (rare) then the pin-boot mapping can include that.
The user gets full control, and they can choose how many pins to allocate to flash.
What is important to avoid, is crippling the end-uses of what is a extremely flexible P2, by taking shortcuts in the ROM.
Worth thinking about, and I can see merit in a variant of this, which would be a ONE-PIN Boot support.
There will be P2 applications where even serial / flash pins are a load users prefer to avoid, and the smallest possible boot is one-pin.
You can get 16kB Flash MCUs now, for 28c/1k, which is a lot of P2 code.
As in 3-pin Flash, checking for presence of one-pin device, is quick and small.
Such One-pin code could use substantial parts of the UART protocol.
Addit: One-pin-present check could be as simple as sending a single-bit ping, (nom 8.68us for 115200, supported on the 28c MCU) on one pin, set to modest drive, and listen for (eg) a 0x55 echo, with ~175us timeout.
( Which one of RXD, or SPI_CS or SPI_CK pin ? - I'd guess the corner 'flash' pin for lowest pin-impact )
Any conventional part connected would ignore the pulse, a One-Pin boot slave, gives the echo.
Any change from ROM, needs a means to program the memory, and most cells need not just the memory but also charge pumps for erase.
OTP might save on erase options, but even this still needs some yield coverage.
- ie if your OTP has one bad cell, do you want to scrap a whole P2 ?
I could see extra (niche) markets for an OTP version, (XMOS have a OTP cell ) but maybe on P3 ?
ROM is simple, one-way, and reliable (hopefully), with highest yields.
Cluso, have you been working on SD booting?
I have been on this every spare moment I have had. I am not happy with the initialisation that I have as it needs to run twice and I haven't found the key to this yet even though it always runs on from eeprom boot fine. I want it to be bullet proof !
BUT I have spent a huge amount of time over the past 2 weeks just trying to get Windows 10 to play nicely with Outlook (Office 365). Outlook fails on launch since the recent update. MS have beeen helping to diagnose the problem as no access to my old emails and access to my new ones via webmail in not fun. Rollback W10, deleting and reinstalling Office 365, and loading MS test programs and sending log files.
Anyway, I found a workaround that works in my case since I have a metered connection, while MS tries to find and solve the problem.
(What is the part doing, that needs 30us ??)
Seems these parts get more complex than simple memories, SD may be similar/worse.
A slow init step, could explain needing 2 passes ?
Sounds like it's moving forward well.
Sorry about your Win 10 problems. I don't know about you, but I get so worn down with idiotic computer behavior that it almost makes me not want to work, sometimes; hence, my pipe dream of having the Prop2 self-hosting, to leave the diseased state of personal computing behind. Meanwhile, web-based IDE's are becoming popular, which seem even more tenuous.
Sorry, I've been caught up in a job but I will try and jump into this in the next couple of days. I do know that I have had to issue dummy writes just for the extra few clocks that some cards need as some systems output a continuous clock, even when they are not accessing the card.
Couldn't the code be slightly modified: and P56 being used instead of P59 for DI&DO?
Edit:
Chip, please consider also this kind of products/substitutes of the main flash:
CY14V101PS
AvalancheTechnology SPSRAM and SPNOR devices
In case the part is missing the hw reset it will most probably not be used in multIO so nothing to reset except a pending write(program/erase) as Chip is already doing.
Anyway, if someone wants to use cheaper parts, without hw reset option, in multiIO mode he can provide circuitry to power-cycle the flash driven by the "!RST & CS" signals.
Seconded.
And i'm not anti. Where those options exist, I will use them at times. Options are good. But, running local is what I trust, and I can secure a state and keep it. That's the most important thing.
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...
Nice parts, but no data ? I've asked for data sheets.
I'll start a new P2 Boot tree suggestion thread, that merges the comments/suggestions in this one.
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.
Some of those parts are pretty neat, but they signal at 1.8V, which won't work for the Prop2.