SPI boot ROM compatibility tests
ManAtWork
Posts: 2,178
Has anybody already tested flash chips different from those used on the P2D2 and P2ES boards? (Winbond W25Q128)
I ask because I have a MX25V8035 here that doesn't work. I've already bothered Evanh a lot because the first suspicion was that the second stage bootloader failed when using dual pin read mode. But it turns out that the ROM bootloader of the P2 might have a problem. I verified the flash contents multiple times with TAQOZ to make sure the download/write to flash is working correctly.
When I connect a scope to the /CS and CLK signals I see the following:
1. a short low pulse (~2us) on /CS several ms after reset
2. another low phase on /CS with two clock pulses, then 8 then 16 CLK pulses
3. two 8-bit commands (reset enable + rest)
4. around 60us delay
5. two 8-bit commands plus 8 more CLK pulses
6. 9us delay, then /CS goes high and nothing more happens
Step 1 to 5 matches what is to be expected from Chip's code. But the loader seems to stop after having read the very first byte of data. Don't know what happens here.
The MX25V8035 might be just bad luck in decision. I've ordered some other chips from different manufacturers and will test them as soon as possible. The goal is to make a list of compatible devices and probably to find out what's wrong with the ones that don't work.
Update: current compatibility test results (09/28/2023)
simple flash and boot check passed:
Winbond W25Q80DV
Issi IS25LP080D (*)
Amic A25L080M
ON LE25V40
Adesto AT25SF041
XT25F08BSOIGU-S (thanks @Tubular for testing)
ZB25D40BTIG
P25Q16SH-SSH-IT
GD25Q80 (*)
(*) = testet with the flash file system, works if LAST_BLOCK is adjusted
Passed with limitations (pulldown at SO required):
GigaDevice GD25Q16
Adesto AT25SF321B (*)
AT25SF128A (additionally needs modified bootloader, see post #59)
Check failed:
Macronix MX25V8035 (read fails)
Microchip SST25VF080 (write fails)
ZD25WQ80BTIGT (Soic-8 150 mil)
I ask because I have a MX25V8035 here that doesn't work. I've already bothered Evanh a lot because the first suspicion was that the second stage bootloader failed when using dual pin read mode. But it turns out that the ROM bootloader of the P2 might have a problem. I verified the flash contents multiple times with TAQOZ to make sure the download/write to flash is working correctly.
When I connect a scope to the /CS and CLK signals I see the following:
1. a short low pulse (~2us) on /CS several ms after reset
2. another low phase on /CS with two clock pulses, then 8 then 16 CLK pulses
3. two 8-bit commands (reset enable + rest)
4. around 60us delay
5. two 8-bit commands plus 8 more CLK pulses
6. 9us delay, then /CS goes high and nothing more happens
Step 1 to 5 matches what is to be expected from Chip's code. But the loader seems to stop after having read the very first byte of data. Don't know what happens here.
The MX25V8035 might be just bad luck in decision. I've ordered some other chips from different manufacturers and will test them as soon as possible. The goal is to make a list of compatible devices and probably to find out what's wrong with the ones that don't work.
Update: current compatibility test results (09/28/2023)
simple flash and boot check passed:
Winbond W25Q80DV
Issi IS25LP080D (*)
Amic A25L080M
ON LE25V40
Adesto AT25SF041
XT25F08BSOIGU-S (thanks @Tubular for testing)
ZB25D40BTIG
P25Q16SH-SSH-IT
GD25Q80 (*)
(*) = testet with the flash file system, works if LAST_BLOCK is adjusted
Passed with limitations (pulldown at SO required):
GigaDevice GD25Q16
Adesto AT25SF321B (*)
AT25SF128A (additionally needs modified bootloader, see post #59)
Check failed:
Macronix MX25V8035 (read fails)
Microchip SST25VF080 (write fails)
ZD25WQ80BTIGT (Soic-8 150 mil)
Comments
The first trace is SO, the second is CLK.
I hope I have more luck with the other chips I've ordered. We'll see tomorrow.
BTW, shouldn't the /CS signal go high just after the reset command and before the 50us delay to complete and actually execute the command? I saw it stays low during the wait. Maybe the chip is not ready when the write disable and read status arrive because the reset procedure doesn't start before /CS goes high.
' ' ' SPI long/byte out ' spi_cmd8 mov pa,#8 'ready to send 8 bits spi_cmd drvh #spi_cs 'cs pin high rol pb,#24 'msb-justify byte drvl #spi_cs 'cs pin low .out rol pb,#1 wc 'get bit to send drvc #spi_di 'drive data-in pin to bit drvh #spi_ck 'drive clock pin high drvl #spi_ck 'drive clock pin low _ret_ djnz pa,#.out 'loop to output bits, return when done ' ' ' SPI byte in ' spi_in rep @.in,#8 'ready to input a byte drvh #spi_ck 'drive clock pin high drvl #spi_ck 'drive clock pin low testp #spi_do wc 'sample data-out pin ('testp' is from before 'drvh') rcl x,#1 'save data bit .in retThe Winbond chip were are using on the P2 Eval says in its datasheet that it requires at least 30us of time from when the reset begins with SPI_CS going high, before it can take another command. We are giving it about 160ns. I'm surprised this never caused a failure on our end. We've been using Winbond chips the whole time. Maybe they recover from reset in such a way that they work under these circumstances.
Until we can revise the silicon (ugh... expensive and takes months), we may just have to spec the Microchip flash. It's not expensive at $1.43 per 2100 units. The whole chip also erases in 50ms max, which is better than 200 seconds of the Winbond flash.
I am going to run a test to see how the Winbond flash we've been using responds to a read command immediately following a reset command sequence.
Here's the code:
The main reason will be because all commands still start as 1-bit data on DI only. So, no matter what mode you've used or targetting, the post-CS-low command method never changes.
But the bootcode sends the status-read anyway, and checks for the BUSY and WEL bits to be low. So if you have a pulldown resistor at SO, it will read $00 as the status response and should continue with the code, also if the Flash does not really respond. Maybe the following READ command works then again and the booter can load the code.
So I would try it with a pulldown, for example 4.7k at P58 (SO).
Andy
I guess that the time actually required to perform a reset depends on the previous state. If it was idle or reading it completes fast. If it comes out of an erase or write command it takes longer. We could test this by asserting /RES while running a large write operation. If it turns out to be true it has to be fixed. Otherwise the whole recover-out-of-any-state procedure is useless, even with the Winbond chip that is otherwise working. Reset could happen any time and booting should work in all cases.
The "takes months" part is no problem. I can live with the Winbond or Microchip flash for now. It takes at least until october until we get larger quantities of P2s anyway.
The "expensive" thing is different. I used up ~10,000 P1 units over the last 10 years. If I'm optimistic and plan for 10k P2s in the next 10 years using the big flash chips would cost $12,000 more than using a smaller one. The Adesto AT25SF041 costs only €0.20 even at low quantities, for example.
For sure, it does. It's listed on page 19 of the data sheet (Table "ID/Reset commands). It's described in Chapter 10-32 "Software reset".
Thanks, Andy, good idea. I'll try that.
Plus >> $80-100K
Would have to be a disaster for the above steps to be undertaken.
Please upload your copy.
PS: Attached is the newest I found.
Exactly. Next change is going to involve the following:
1) Add guard rings around the 1.8V N-wells to raise the threshold for voltage-induced latchup.
2) Fix the clock-switch glitch when switching away from PLL-post-divide-by-1.
3) Maybe lighten the integrator cap in the ADC to improve high-frequency conversions.
4) ?
If we get into the ROM:
1) Add the 'DRVH #spi_cs' instruction immediately after issuing the RESET command.
2) Use the streamer and smart-pin-transition mode technique to reduce time spent on SPI by 80% for fast booting.
3) ?
If we get into the Verilog (this is REALLY expensive):
1) Add a clock delay to the Goertzel result to internally align its operation. This can be programmed around now, actually.
2) Fix the SETQ+ALTx+RDLONG PTRx bug to properly update PTRx. Might have to add some 'ideal mode bit' - maybe not worth doing.
3) ?
The Winbond W25X20 is 256KB and is only $0.27 @1k units. It should work.
I've noticed that at least one HDMI encoder chip offers this...
It makes it easier to output QVGA screen buffer with VGA resolution...
This is mine. I've downloaded it from Farnell if I remember correctly.
Damn. I thought the ROM contents could be changed by only one mask.
I'm pretty sure we'll find another solution for me. I hope some of the flash chips work at least if reset from idle or read. Reset after write or erase is not so important for me. I have no data logger applications and if I had I could add an extra flash chip or SD card. My high volume applications are servo drives and CNC controllers. Write/erase occurs only for parameter storing and software updates.
I've found that it DOES depend on what was going on at the time of reset.
I jacked the P2 up to 200MHz, for an SPI_CK frequency of 100MHz, and did some tests to push things to the absolute limit. I had to increase the duration of SPI_CS high to get it to work. This is 10x faster than RCFAST (assuming RCFAST=20MHz).
I sent the following sequence of commands:
$06 - WRITE_ENABLE
$D8_01_00_00 - ERASE 64KB block at $01xxxx (doesn't disturb data in $00xxxx block)
$66 - RESET_ENABLE
$99 - RESET
$03_00_00_00 - READ from $000000
Expected data DID NOT come out:
Then, I changed the WRITE_ENABLE ($06) to WRITE_DISABLE ($04) to cause the ERASE command to be ignored.
Expected data DID come out:
So, on these Winbond chips, reset only takes time if it is cancelling an erase/write operation in progress.
Here is the program I used:
CON spi_cs = 61 spi_ck = 60 spi_di = 59 spi_do = 58 DAT org hubset ##%1_000000_0000001001_1111_10_00 'config PLL, 20MHz/1*10*1 = 200MHz waitx ##20_000_000 / 200 'allow crystal+PLL 5ms to stabilize hubset ##%1_000000_0000001001_1111_10_11 'switch to PLL drvh #spi_cs 'spi_cs high fltl #spi_ck 'reset smart pin spi_ck wrpin #%01_00101_0,#spi_ck 'set spi_ck for transition output, starts out low wxpin #1,#spi_ck 'set timebase to 1 clock per transition drvl #spi_ck 'enable smart pin drvl #spi_di 'spi_di low setxfrq clk2 'set streamer rate to clk/2 (use clk2 from loader) drvh #16 'trigger scope callpa #$06,#spi_cmd8 'write-enable (change to $04 for write-disable) callpa ##$000001D8,#spi_cmd32 'erase 64KB block at $010000 callpa #$66,#spi_cmd8 'reset-enable callpa #$99,#spi_cmd8 'reset callpa #$03,#spi_cmd32 'read $000000 wypin #256,#spi_ck 'start 256 spi_ck transitions jmp #$ ' ' ' SPI command 8-bit - use callpa ' spi_cmd8 drvh #spi_cs 'start new command waitx #4 drvl #spi_cs xinit bmode,pa '2 start outputting 8 bits to spi_di wypin #16,#spi_ck '2 start 16 spi_ck transitions _ret_ waitxfi '~16 wait for streamer to finish ' ' ' SPI command 32-bit - use callpa ' spi_cmd32 drvh #spi_cs 'start new command waitx #4 drvl #spi_cs xinit lmode,pa '2 start outputting 32 bits to spi_di wypin #64,#spi_ck '2 start 64 spi_ck transitions _ret_ waitxfi '~64 wait for streamer to finish ' ' ' Data ' clk2 long $4000_0000 'clk/2 nco value for streamer bmode long $4081_0008 + spi_di<<17 'streamer mode, 1-pin output, msb-first byte from s lmode long $4081_0020 + spi_di<<17 'streamer mode, 1-pin output, msb-first long from sYes, that's also important. I don't mind if the boot behaviour is somewhat sub-optimum, it only runs with a subset of possible chips and if reset must not be triggered during write or erase. I also don't take it to serious if I have to pay a little more for flash chips until this gets finally fixed.
But booting has to be absolutely reliable for "standard" reset cases.
Now that I see how RESET doesn't require any delay, unless a write is in progress, and how it runs back-to-back with SPI_CK cycling at 100MHz, I don't think thermal testing is necessary. There is no analog component to the matter. If RESET works without delays at 100MHz at room temperature, it will certainly work at 10MHz during booting - unless a write is in progress. Until we can update the ROM, we are going to have to live with the possibility that the P2 may not reboot on the first reset if a flash-write was in progress.
Haven't tried rebooting while writing to flash though...
Would a pullup resistor on CS help, so as to bring it high while chip is booting?
There must be a pull-up on SPI_CS for the ROM to even detect it.
Yes, good point.
Ok, somewhat acceptable. As I said I don't write to flash very often. It must have been extremly bad luck if a power failure happens exactly in the moment a user is updating the parameter file. And even if that happened he could power cycle it a second time and it should work again.