Shop OBEX P1 Docs P2 Docs Learn Events
SPI boot ROM compatibility tests — Parallax Forums

SPI boot ROM compatibility tests

ManAtWorkManAtWork Posts: 2,049
edited 2023-09-28 11:34 in Propeller 2
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)

«13

Comments

  • cgraceycgracey Posts: 14,133
    edited 2020-01-21 16:55
    ManAtWork, it seems that it's reading the WEL bit high after doing a WRITE_DISABLE command. It's taking the 'if_nz jmp #.fail' branch, thinking there's no SPI memory attached:
    '
    '
    ' Try to load from SPI memory
    '
    try_spi		drvh	#spi_cs			'drive spi_cs high
    		drvl	#spi_ck			'drive spi_ck low
    
    		neg	pb,#1			'set command bits to all 1's
    		drvh	#spi_do			'drive spi_do high in case quad/dual mode
    		callpa	#2,#spi_cmd		'send exit-quad command
    		callpa	#8,#spi_cmd		'send exit-quad command
    		callpa	#16,#spi_cmd		'send exit-dual command
    		fltl	#spi_do			'float spi_do
    
    		callpb	#$66,#spi_cmd8		'send reset-enable command
    		callpb	#$99,#spi_cmd8		'send reset command
    		waitx	##rc_max/20_000		'wait 50us
    
    		callpb	#$04,#spi_cmd8		'send write-disable command to clear WEL
    
    .wait		callpb	#$05,#spi_cmd8		'send read-status command
    		call	#spi_in			'get status
    		testbn	x,#1		wz	'if WEL high, no SPI memory (z=0)
    	if_nz	jmp	#.fail
    		testbn	x,#0		wz	'if BUSY high, wait for erase/write to finish
    	if_nz	jmp	#.wait
    
    		mov	pa,#32			'send read-from-start command
    		callpb	#$03,#spi_cmd
    
    		decod	y,#10			'ready to input $400 bytes from SPI
    		wrfast	#0,#0			'ready to write bytes to hub
    .data		call	#spi_in			'get byte
    		wfbyte	x			'store byte into hub
    		djnz	y,#.data		'loop for next byte (y=0 after)
    
    		rdfast	#0,#0			'ready to read longs from hub
    		rep	@.sum,#$100		'ready to read and sum $100 longs
    		rflong	z			'read long
    		add	y,z			'sum long
    .sum
    		cmp	y,csum		wz	'verify checksum, z=1 if okay
    		bitz	flags,#spi_ok		'if program verified, set spi_ok flag
    .fail
    
  • Ouch, you're right. The Macronix flash somehow seems to be upset by the exit-quad sequence. SO (P58) goes tri-state before or after the reset enable+reset commands and never comes back. The read status command is ignored.

    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.
    800 x 600 - 99K
  • cgraceycgracey Posts: 14,133
    edited 2020-01-21 18:35
    Here are the SPI routines that the code above calls Every time spi_cmd/spi_cmd8 is called, SPI_CS goes high then low:
    '
    '
    ' 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
    		ret
    
  • cgraceycgracey Posts: 14,133
    ManAtWork, yes, the SPI_CS should go high after the reset command. I forgot to do that! The reset command, instead, commences on the brief time before the write-disable command is issued. Not good. That may be what's causing your chip to not work.

    The 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.
  • cgraceycgracey Posts: 14,133
    I'm seeing ~12us from the start of RESET when the write-disable ($04) command is issued, until the read ($03) command is issued. That may be why it's working.
  • cgraceycgracey Posts: 14,133
    We need to run some tests to see if the flash doesn't boot at high temperatures.
  • cgraceycgracey Posts: 14,133
    edited 2020-01-21 20:42
    I did some looking at 128Mb flash chips on Digi-Key and I found that the Microchip SST26VF032B requires only a 20ns wait between RESET to READ:

    SST26VF032B.png

    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.
    683 x 133 - 17K
  • Cluso99Cluso99 Posts: 18,066
    Perhaps the boot rom is working because the flash hasnt ever been in dual/quad spi mode so the reset is not important on the winbond chips ???
  • cgraceycgracey Posts: 14,133
    It looks like the Winbond flash doesn't need any time after a RESET to begin a READ:

    Winbond_RESET.jpg

    Here's the code:
    CON	spi_cs = 61
    	spi_ck = 60
    	spi_di = 59
    	spi_do = 58
    
    DAT		org
    
    		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	#$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
    		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
    		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 s
    
    1251 x 1003 - 325K
  • evanhevanh Posts: 15,126
    edited 2020-01-21 22:41
    Cluso99 wrote: »
    Perhaps the boot rom is working because the flash hasnt ever been in dual/quad spi mode so the reset is not important on the winbond chips ???
    Somewhat off topic - With the two parts I've worked with (Winbond and Macronix), there isn't any release from dual/quad modes. Or maybe I should say they naturally always release on rising CS pin - Same completion as any other command. The only mode state bits are things like write protection and security bits.

    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.

  • AribaAriba Posts: 2,682
    From the datasheet it seems the MX25V8035 does not support the RESET command. Not sure what it does on not supported commands, but it has the effect, that the status read fails.

    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
  • cgracey wrote: »
    The 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.

    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.

  • cgracey wrote: »
    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 "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.
  • Ariba wrote: »
    From the datasheet it seems the MX25V8035 does not support the RESET command.

    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".

    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).

    Thanks, Andy, good idea. I'll try that.

  • Cluso99Cluso99 Posts: 18,066
    From what i recall, a ROM change or verilog change would delay at least 3 months for OnSemi to redo the layout (the ROM is not a mask layer). Then 6 months for a new set of samples, followed by another 6 months for production chips.
    Plus >> $80-100K

    Would have to be a disaster for the above steps to be undertaken.
  • evanhevanh Posts: 15,126
    edited 2020-01-22 10:53
    ManAtWork wrote: »
    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".
    I've now got three different editions of the datasheet but still only seeing same as Ariba.

    Please upload your copy.

    PS: Attached is the newest I found.
  • cgraceycgracey Posts: 14,133
    edited 2020-01-22 11:16
    Cluso99 wrote: »
    From what i recall, a ROM change or verilog change would delay at least 3 months for OnSemi to redo the layout (the ROM is not a mask layer). Then 6 months for a new set of samples, followed by another 6 months for production chips.
    Plus >> $80-100K

    Would have to be a disaster for the above steps to be undertaken.

    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) ?
  • cgraceycgracey Posts: 14,133
    ManAtWork wrote: »
    cgracey wrote: »
    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 "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.

    The Winbond W25X20 is 256KB and is only $0.27 @1k units. It should work.
  • RaymanRayman Posts: 13,800
    If you do ever redo the Verilog, it would be nice if the HDMI output could include a "pixel repeat" function.
    I've noticed that at least one HDMI encoder chip offers this...
    It makes it easier to output QVGA screen buffer with VGA resolution...
  • evanh wrote: »
    > 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".

    I've now got three different editions of the datasheet but still only seeing same as Ariba. Please upload your copy.

    This is mine. I've downloaded it from Farnell if I remember correctly.
  • Cluso99 wrote: »
    From what i recall, a ROM change or verilog change would delay at least 3 months for OnSemi to redo the layout (the ROM is not a mask layer). Then 6 months for a new set of samples, followed by another 6 months for production chips. Plus >> $80-100K

    Would have to be a disaster for the above steps to be undertaken.

    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.
  • cgraceycgracey Posts: 14,133
    edited 2020-01-22 12:22
    ManAtWork wrote: »
    cgracey wrote: »
    The 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.

    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.

    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:

    Winbond_RESET_after_WRITE_ENABLE_plus_ERASE_at_Fspi_ck_100MHz.jpg

    Then, I changed the WRITE_ENABLE ($06) to WRITE_DISABLE ($04) to cause the ERASE command to be ignored.

    Expected data DID come out:

    Winbond_RESET_after_WRITE_DISABLE_plus_ERASE_at_Fspi_ck_100MHz.jpg

    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 s
    
  • evanhevanh Posts: 15,126
    .
    ManAtWork wrote: »
    This is mine. I've downloaded it from Farnell if I remember correctly.
    Ah, the "F" suffix makes all the difference to what Goggle lists. That's a lot newer product from the non-F model. Speed is up, all the read modes are supported, the feature list is supported too. Looks just like the Winbond chip at first glance.
  • cgracey wrote: »
    We need to run some tests to see if the flash doesn't boot at high temperatures.

    Yes, 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.
  • cgraceycgracey Posts: 14,133
    ManAtWork wrote: »
    cgracey wrote: »
    We need to run some tests to see if the flash doesn't boot at high temperatures.

    Yes, 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.
  • If reliability is required, an external watchdog is probably a good idea, anyways. That'd take care of failed boot attempts, too.
  • evanhevanh Posts: 15,126
    Does that help with the MX chip as well? A later, or second, reset to allow longer for the programming to clear up? I think not.
  • RaymanRayman Posts: 13,800
    edited 2020-01-23 02:49
    FYI, my p2 board is using the SST26VF064B and seems to be fine.

    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?
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    FYI, my p2 board is using the SST26VF064B and seems to be fine.

    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.
  • ManAtWorkManAtWork Posts: 2,049
    edited 2020-01-23 08:17
    cgracey wrote: »
    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.

    Yes, good point.
    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.

    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.
Sign In or Register to comment.