P2 Boot Decision Tree Suggestions
jmg
Posts: 15,175
Now the ROM is finalising, with SerialLoad and FlashLoad core parts done, it is a good time to step back and look at how the decision tree could work, to give users the most flexible P2 they expect...
Here is some pseudo code, that merges suggestions from the SPI thread.
To keep code compact & simple, the pin map step selects the pins uses within Serial and Flash code.
ie sometimes OUT and IN are on the same pin, sometimes they are separate pins.
This allows any Boot-cost from 1-pin, up. A critical aspect of this, is Other-Mode exit, at Boot.
ie even if the part is in Quad/Dual mode, when RST applies, Boot needs to still succeed.
SD is included, assumes code can fit & test.
( Failing ROM fit or test pass on SD, a user could use 1-pin mode to load any SD driver, from a ~28c MCU)
Here is some pseudo code, that merges suggestions from the SPI thread.
To keep code compact & simple, the pin map step selects the pins uses within Serial and Flash code.
ie sometimes OUT and IN are on the same pin, sometimes they are separate pins.
This allows any Boot-cost from 1-pin, up. A critical aspect of this, is Other-Mode exit, at Boot.
ie even if the part is in Quad/Dual mode, when RST applies, Boot needs to still succeed.
Suggested preambles, Function Send_1b_CS (NClocks, DataLJ) ' sends N clocks, Data DIO0, with std CS frame Function Send_1b_CLK (NClocks, CS,DataIO0) ' non frame send, SD clears Send_1b_CS(8,$ff) ' classic M4 exit Quad command, as in NXP etc Send_1b_CS(16,$ffff) ' classic M4 exit Dual command Send_1b_CS(2,$ff) ' nibble coverage, in case any parts lack the above, assumes Pullups on DIO3..DIO0. Parts listed below do not need this. ' << by here, BUS should be back in Single-bit mode. PollBusy ' confirm device connected, and confirm is not Busy ' Optional firm reset - for some newer, larger parts. Send_1b_CS(8,$66) ' newer 66H,99H command pair Send_1b_CS(8,$99) ' newer 66H,99H command pair Wait(>40us) ' does more than a pin-mode change PollBusy ' unclear if poll busy can be used for 40us timing ' check device ID for <> 00,ff as connected device. SD: tbfAbove covers DIO0 data, if a SPI part is quad-wired, and flipped into 1-SPI mode, HOLD# and WP# need to be Hi, managed either by external pullups, or internal pullups, or (less desirable) hard CMOS drive to 1.
SD is included, assumes code can fit & test.
( Failing ROM fit or test pass on SD, a user could use 1-pin mode to load any SD driver, from a ~28c MCU)
// Proposed Boot-Tree for P2, has just 2 main routines, SerialLoad and FlashLoad
// Pin mapping selects the pin-impacts of those routines
// Can vary from a smallest possible 1-pin, to 3 pins (Flash3P only) to 4 pins (FlashQuad connected)
// plus possible Combination of 2 pins for RXD.TXD & +2 on QSPI user choice.
//
// Simple, fast echo-read-back type tests determine which branch to use.
// The physical connection is detected and that determines the branch chosen.
//
//
if Test_Present_OnePin // Echo? => Minimal 1-Pin useage Boot mode, external cheap MCU
SelectMap TXD,RXD OnePin // MCU's own boot handles update path
SerialLoad
elseif PinMode=SkipFlash // No flash, or overrule flash cases (debug, updates)
SelectMap TXD,RXD TwoPin
SerialLoad
elseif Test_Present_i2c // Optional ? i2c step ?
SelectMap SCL,SDA TwoPin
i2cLoad
elseif Test_Present_Flash3P // Lowest pin-count flash, 3 pins, _Excludes_ QSPI
SelectMap SDI,SDO OnePin
FlashLoad
elseif Test_Present_Flash4P // _Allows_ PCB layout for QSPI(6p), boots in 1b SPI
SelectMap SDI,SDO TwoPin
FlashLoad
elseif Test_Present_SD //
SelectMap SDI,SDO SDPin
FlashLoadSD
else
DefaultLoad // No flash found (SerialLoad2Pin?)
// also DefaultLoads on Blank/fail load of present flash
Test_Present_Flash3P // Nothing coming back on SDO=SDI ?
SWResetPreamble (0xff,0xffff,0x66,0x99,{SIO3=\_/=},wait,0xAB,wait)
return (ReadID(3P,0x90) <> 0x0000,0xffff)
Test_Present_Flash4P // Reads in std 4 pin SPI, HOLD/WP = pullups, drives just 3 pins
SWResetPreamble (0xff,0xffff,0x66,0x99,{SIO3=\_/=},wait,0xAB,wait)
PulseNominated RST pin, wait // for those subset parts that _do_ have RST
return (ReadID(4P,0x90) <> 0x0000,0xffff)
FlashLoad
uses READ_STATUS ($05)
uses READ_DATA ($03)
Comments
Application usage of 1-Pin Boot via small MCU :
* Maximal P2 smart pin usage, a design can now use 63 pins
* Low impact load of USB or SD or RF-Link (etc) boot2 drivers, for future Soft-boot-updates
* Can include a Watchdog for free
* Can augment ADC/DAC of P2
* Can use without, or with, SPI flash, with no change to P2 pin count. (MCU bridges SPI-1P)
Small pin count, low cost simple MCUs, for Serial 1P memory emulation.
(Focus on Memory size, then package size)
Most include a serial boot loader, so can also do 1Pin to UART bridge.
Vendor CodeSize Part number fOscMhz,Tol Capture MaxBaud Package Appx price, 1k Nuvoton 16kB N79E715 22.118,3%VT T2_f/4 691200 SO16N 28c Nuvoton 16kB N76E885 22.118,2%VT T2_f/1 1.38M TSSOP28,20 42c (28p) Nuvoton 16kB N76E003 tbf tbf 1.38M tbf tbf (<< 42c) SyncMOS 16kB SM39R16A3 1.38M MSOP10 tbf SiLabs 2kB EFM8BB1 24.5,2%VT PCA_f/1 ~3M QFN20 3mm 33c SiLabs 8kB EFM8BB1 24.5,2%VT PCA_f/1 ~3M SO16N 42c SiLabs 16kB EFM8BB2 40,2%VT PCA_f/1 ~6M QFN20 3mm 55c SiLabs 64kB EFM8BB3 48,2%VT PCA_f/1 ~6M QFN24 3mm 0.99 +12b ADC, 12b DAC Infineon 64kB XMC1100 tbf TSSOP16 1.12 Price climbs with code size, as RAM & peripherals tend to climb too, but there is Serial Flash which can be added to extend the 1P loader, for modest amounts ... Reset Via 1-bit Fremont 4Mbit FT25H04S-RT SO8 13.5c/3k 0xff/0xffff Fremont 16Mbit FT25H16S-RT SO8 18.6c/3k 0xff/0xffff Adesto 4Mbit AT25SF041-SSHD-T SO8 18.7c/3k 0xff/0xffff Winbond 32Mbit W25Q32 SO8 40c/3k 0x66+0x99 Micron 32Mbit N25Q032A SO8 38c/3k 0xff (XIP confirmation bit) Macronix 16MB MX25R1635F USON2x3 76c/3k 0x66+0x99 SST 16Mbit SST26VF016B SO8 1.28/3k ok 5.8, (fails 5.5)Added: one older part, which would exclude itself on price alone, also excludes on failing to specify 100% 1-bit exit coverage.
Wait..SST26VF016B Data is contradictory, digging further it does have a XIP M4 confirmation bit, so 0xff should exit QuadMode, using just DIO0.
"When M[7:0] is any value other than 0AXH, the device expects the next instruction initiated to be a command instruction. To reset/exit the Set Mode configuration, execute the Reset Quad I/O command, FFH. "
Data sheet links:
SiLabs:
http://www.silabs.com/Support Documents/TechnicalDocs/EFM8BB1-DataSheet.pdf
http://www.silabs.com/Support Documents/TechnicalDocs/EFM8BB3-DataSheet.pdf
Nuvoton:
http://www.nuvoton.com/hq/products/microcontrollers/8bit-8051-mcus/low-pin-count-8051-series/Data-Sheet/?__locale=en&resourcePage=Y
SyncMOS:
http://www.syncmos.com.tw/products_file/ISSFD-M065_G_SM39R16A3-Datasheet(EN).pdf
http://www.syncmos.com.tw/paper_file/ISSFA-0249_I_SyncMos-Products-Selection Guide(EN).pdf
Addit: Handshake and AutoBAUD notes
Most MCUs have calibrated Osc, but the value varies 16MHz / 22.1184Mhz / 24.5MHz
The P2 defaults at roughly 20MHz during boot.
A single-bit pulse from P2 is all that is needed to wakeup and Echo, but that may constrain later baud choices.
Better may be Two chars adjacent eg 0xfe x 2, will allow a choice of Hi-Time capture, (8 Baud times), or inter-char time, 10 baud times. Two bits low, is highly baud-deviation tolerant, & 2 chars gives enough time to measure each sides clocks with reasonable precision.
Default phase 1 boot would be 115200 or 57600 region, but supporting a gear-change once PLL is enabled, gives more choices.
eg P2 sends 0xfe,0xfe, and waits. 1-Wire echos 0x55* (or whatever P2 expects as AutoBaud char) on second 0xfe, and the baud can be derived from that interchange.
P2 side, 20M is /174 for 115200, for appx 0.57% baud granularity.
PLL of 80M supports ~800k with 1% Baud granularity, or higher with NCO Fractional Baud links.
1.38MHz seems a reasonable PLL baud speed ?
* Expanding : A first fixed char of 0xfe gives a nice 8b high pulse, for possible timing, and a 10b Char interspace.
The second byte does not have to be 0xfe, it can be maybe 0xff..0xfc, for some degree of mode flip.
eg Baud-speed change, or 1-wire pgm from P2, are possible.
--- P2 Crystal-less designs, with better precision
P2 Osc Cal options: A 2 char One-Pin serial trigger can resolve to
(1/50M)/(10/115200) = 230ppm /SysCLK
(1/24.5M)/(10/115200) = 470ppm /SysClk 10 sysclks is ~0.5%
Measurement precision is good, meaning scope is there to Calibrate the P2 20MHz against MCU CalOsc, for crystal-less designs, if needed.
Many MCUs can also CLKOUT, which allows the CalOsc to drive the PLL, to the CalOsc precision (added above)
The way to get half-duplex/one-wire operation is to use slightly different textual commands that tell the loader to use pin 63, instead of pin 62 as a serial output for response.
Some small checks on timing would be needed to ensure the reply does not arrive on top of an incomming char, & enough turn-around time is allowed for.
Use EEPROM 24C32 (4KB) or 24C64(8KB). These are now available in SOT23-5 and WSC4 (4pin BGA 0.8mm square) and TSSOP8 (8pin 0.65mm pitch).
Pricing from 0.19c upwards. These are pin/software compatible with 24C256 and 24C512.
OnSemi make these too, so perhaps Parallax could get a good deal on them with the P2.
Some of the SOT23-5 and WSC4 are new releases. There is also DFN8 parts too.
Yes, that gives a 2-pin choice, I've added that to the tree.
This adds i2cLoad code, and requires more code space for i2c layer, so it may be down to a ROM size question.
Complicated ? - Only to those who have never seen an elseif ..
It's actually quite a simple, fall-thru tree, if you read it carefully.
It is a simple reflection of the way users may expect to use Prop2.
Some will want lowest-pin-cost Boot, perhaps to a USB loader, others will want fastest Memory bandwidth, and still others may want Serial-only operation. Many will be content with 3 Pin SPI.
All can be quite simply covered.
Optional to me are i2c and SD, but that's likely more from ROM-Space effects.
For the next FPGA release, I'm going to have just serial and 3-wire SPI flash support. It's easiest for now. This whole boot matter could take a lot of development time to do right. What I have now is working and solid.
You can claim all you want that it's simple. You are clearly glossing over many things and making many assumptions. Your scheme cannot be made 100% bullet proof. Especially in a reasonable time frame. This is unsafe to put into a boot ROM of a LONG lifetime MCU.
No vender supports QSPI the same way, even within their own products. Even if Chip did work out all the various things that need to be done to reset all the current chips, next week some vender will come out with yet another new way. This is something that should be in software not hardware or the fixed ROM.
You proposal is much more complex than what Chip already has working. It IS complicated compared to what Chip wants to do.
But what do I know, you seem to think I'm an idiot that doesn't understand elseif chains or can't read your posts.
We'll see about the boot tree. For now, I've got what I described all working. One thing I'd like to add is the half-duplex serial. I think if a "*" follows a command, I can key off that and go half-duplex.
1. Chip has the responsibility of making design decisions around the P2, whether they are right or wrong, ideal or not. While we all get to be involved and see this chip get made, he needs to follow his instincts and come up with the right approach. Make decisions, Chip! jmg has made many useful contributions and will hopefully continue to do so.
2. The project needs to be finished. This is an overriding consideration. Usually, at the end of a design process, we're removing specifications instead of adding them in order to meet the release schedule. I'm not involved in any real deep engineering like the P2, but it's still clear to me that any engineering vision must also be financially productive. To me, this seems like something new again.
Ken Gracey
Of course, but Chip cannot be everywhere. Some of the coverage stuff can be looked at by others, and is.
This is not really 'new', but it certainly is focused on end markets and P2 adoption.
The P2 already has a Boot Decision tree, just a very limited one.
Certainly one worth testing as-is, as Chip proposed above.
The Boot tree here, simply takes what users will reasonably expect, and applies that to the code Chip has already developed.
It is really the just interface between the real world, and the core boot code.
It uses simple, Physical connected tests to determine what the user actually has connected.
The core code already supports both SPI and Serial, and that code is easily shared (as Chip has mentioned, Serial is already essentially half duplex)
i2c and SD are more optional, but they have been suggested by others, so I added those.
(Some are working on SD code, so I think that should at least have a place-keeper in the ROM.)
One-Pin boot is a simple pin-remap variant of the existing Serial Loader.
It is easily and quickly 'Are you connected' tested. No => Simple continue to next Connected test.
Likewise, 3P and 4P SPI, are pin-remap's of the same SPI code, with the same preambles.
What they allow, is a clean means to connect a QuadSPI part, in Quad mode, for User-code to use Quad.
A critical shortcoming of the 3P only Boot, is that excludes QuadSPI, and to me P2 QuadSPI use, is commercially significant.
Note the ESP8266 can support QuadSPI flash devices. Users will expect this in P2.
I am less worried about corner cases, than about supporting the mainstream QuadSPI parts, and those most likely to be used by P2 customers are the ones I've focused on.
It is quite common for MCU vendors to give a list of compatible and tested parts, and the code I document above is enough for most designer to check if their new (not listed) QuadSPI part, should work.
Most will choose the 'most-available and cheapest larger than P2 image Flash' .
( & it will certainly be QSPI capable) Those I believe I have covered.
... and yet ESP8266 manages what you claim is 'too difficult' for ROM ?
(Note that the present 3Pin proposal, excludes even your 'should be in software', without consuming more pins, or bumping the BOM - Reality: some band-aids cannot be applied later )
Sure, reset varies, but I have already included above, common reset preambles, tested by others.
Chip does not need to 'work this out'.
As for future divergence fears, my reading of data clearly differs from yours. I see a trend to a more common reset scheme, not any divergence. (very) older parts tend to not document this. Newer ones do.
A small MCU can do pretty much anything, "*" is easy.
I used an Echo-Response variant above, as that allows smallest pin impact (just 1 pin), and fastest Skip
- it is done before the SPI code, and uses one SPI pin for the half-duplex.
I guess if you use one SPI pin for the currently included Skip-SPI-Boot tree decision, and then use Standard Serial RX, that costs 2 pins, which is better than what we have now.
Maybe the MCU can drive that Skip-SPI Boot, to give something less that a totally lost pin.
If that Skip-SPI Boot pin is pulsed briefly, as part of the Skip-test, the MCU can even be ready with a command, for fastest loading.
Addit: If you include the software reset preambles above, even in 3 Pin mode, that allows some testing of QSPI parts on real P2 boards. No flow changes, or new Tree branches needed
Users can deliberately place the parts into quad/dual/power down modes, then reboot, and check what happens.
For a part not in Quad mode, the preambles are merely redundant.
1. I don't like the requirement of external parts. As I intend to always have SD on my designs, this is the reason for wanting direct boot from SD. A socket is ~35c and 8GB microSD <$4.
2. If a FLASH chip must be used, then a small package is a priority. QSPI connection layout is a preference, even if the boot code does not use it, hence the pin out suggestions of D0:D3 on P56:P59, CLK on P60, /CS on P61. This also works for SD (and allows for the fast mode later).
3. P62:P63 are SO:SI (TXD:RXD)
Now for some "out there" thinking...
* As I suggested, cheap I2C EEPROMs are available in tiny packages (smaller to same as P1). Perhaps they could co- exist with SPI/QSPI or SD - need to think about the hardware as I currently share P1I2C pins.
* A cheap micro has been suggested as containing the boot code. While I don't like another brand (and code) micro on my board, I considered this years ago on P1.
There are really cheap micros out there with reasonable FLASH and USB. Maybe this is an avenue to sell a pre-programmed (or partially programmed) micro. Maybe this is for another thread topic to find an appropriate micro? This could make a simple loader and minimal pin count booter.
unsafe != too difficult.
Also, I'd be careful saying the ESP8266 has it solved.
Ken,
We are in 1000% agreement.
The path you advocate, excludes it. - Which rather contradicts Ken's "any engineering vision must also be financially productive."
Yup, exactly. See above note.
I have also seen web blogs, around reflow mounting of (micro?) SD Cards, so they are trending to become 'just another part'.
Do you mean someone would connect to both i2c and Flash, on common pins ?
I was expecting an either/or usage in the above decision tree, which I sequence test-connect based on Pin-Count order.
That means i2c is presence tested, after 1-Pin, but before 3-Pin SPI.
Agreed, it is a little more admin, but I see it as a solution for those who really want 1-Pin boot, and they will take a little more effort to get that. The One-Pin code is going to be small, and stable.
I've done a proof of concept here, that comes in at just 20 bytes to Stream-Out, and ~53 bytes including Serial/Clk Inits.
Sure, once the Simplex Serial option is in there, there are plenty of options for what goes into that Micro.
It can also connect to SPI Flash, allowing 1-pin SPI booting, for example.
I have tried to allow for Baud-rate changes in the 1-Pin link, as first-boot is from 20MHz, low spec Osc, but later links can be PLL, higher accuracy allowing quite a boost in Baud. A choice of 2 seems simplest. Boot ROM needs only work on one.
In that sense, the larger QSPI Flash parts, are very similar to SD, as they will have a lot more than just a 1-page P2 code image.
I think you are taking my support of what Chip wants to do as me only wanting that. I personally would be fine with 4 pin mode being used, but still only doing what Chip has done so far in the ROM code. The only difference from Chips plan, is that Chip feels 3 pin mode discourages people using QPI mode more. So, they won't get into bad states which require power cycling to recover. 4 pin mode allows for people to do QPI if they want, and they have to deal with the reset situations themselves if they have the flash in QPI mode and a reset happens.
It's less than ideal, but it works reliably for SPI, and is essentially done. We can get a chip made with it and people can start using it. Later in the P2 family we can have more flushed out ROM code that handles more including QSPI recover, SD card, etc.
Even if you could connect SD SDI to SDO (which I would be wary of..), I find this on SE, re SDIO modes...
["An SD card comes up by default in 1-bit SD mode, but can be changed into 4-bit mode after startup. If necessary, the card can also be switched into SPI mode, which is always 1-bit wide. The bus width in SD mode can be anywhere from 1 to 4-bits (see 6.2.1). There isn't any 8-bit SD mode, because there aren't enough pins on the SD card to support it. There is an 8-bit SD mode for MMC (MultiMediaCard) cards which have more pins.
I don't see where anyone would want to run in SD mode with less than four data lines, unless they were limited for I/O lines. So let's forget about that."]
To me that says you do need to cover Quad-mode-exit commands, in order to support SD-Boot, and you get QuadSPI mode for free then.
I'd expect most to use some sort of cache read, mainly because of the overhead of an address-change in SPI.
For this, I would expect a dual-focus of developers supporting both HyperRAM/HyperFLASH, for top performance, and QuadSPI for mid-level performance.
16MB QuadSPI parts are sub 20c, and that is already much larger than P2 RAM, so many will start thinking about how they can best get at that memory, just sitting there....
That last bit, is where the fish-hooks lie.....
Only you can't actually kick the can down the road, as you advocate.
"deal with the reset situations themselves" is easy to say, but the reality is, you cannot fix later in SW, what you cannot boot from!!
Quad exists already in the real world, users will expect it, and the part I find hardest to comprehend here is, adding the Quad reset preambles is not rocket science!!.
Peter tested some, in less time than it took me to type this. Quite the opposite of 'complicated', or 'unsafe'.