I think any of the 16MB flash chips which take 3-byte addresses should work. In my flash programmer, I only used the 4KB and 64KB block-erase commands, avoiding the 32KB block-erase command, since not all chips support it. I used at least four different data sheets. I think we've been using Winbond chips, since they are the most available and affordable.
If you just want to boot your code and don't care about future SSD use of the extra 15.5MB, you can use a 512KB flash, or even a much smaller one, as long as it's big enough to hold your code.
Like Jon said, though, Parallax will always use a 16MB flash for future reasons.
Why do 16Mb chips have to be used when 512Kb would do.
Anything with a 3 byte address can be used , but notice that the cheapest flash parts start above 512k, so currently 2~4MBit Flash is the lowest cost at about 7c/500
What makes me think is that the 16Mb Flasch uses a 3 byte addressing.
Or does that not play a role in the data transfer, on the part of P2
It only needs the 3-byte address for programming, actually, using our flash programmer that is downloaded from PNut/PropTool. For booting, a standard read command $03 is issued and bits are read out of the flash chip. Any SPI flash chip can do that and is, therefore, bootable. So, the 3-byte address is really just a programming issue, not a booting issue.
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
simple flash and boot check passed:
Winbond W25Q80DV
Issi IS25LP080D
Amic A25L080M
ON LE25V40
Adesto ST25SF041
I discovered the problem with the Microchip flash chip.
When given the Bulk-Erase command ($D8), it does not always erase 64KB, like the others. The first and last blocks are erasable in only 8KB or 32KB chunks, with the 64KB blocks in the middle:
So, if we only used the Sector-Erase command ($20), which only erases 4KB, our flash loader would properly program the chip, but very slowly. This chip will boot okay, but our current flash programmer won't program it, due to this erasure peculiarity.
If your download is under 16KB, then the flash programmer in PNut will just issue 4KB Sector-Erase ($20) commands, instead of any Bulk-Erase ($D8) commands.
I discovered the problem with the Microchip flash chip.
When given the Bulk-Erase command ($D8), it does not always erase 64KB, like the others. The first and last blocks are erasable in only 8KB or 32KB chunks, with the 64KB blocks in the middle:
So, if we only used the Sector-Erase command ($20), which only erases 4KB, our flash loader would properly program the chip, but very slowly. This chip will boot okay, but our current flash programmer won't program it, due to this erasure peculiarity.
Thanks Chip. It's probably the same as I discovered using the S25FL256 when trying to do a chip erase with TAQOZ. I needed to do 4K erase blocks.
BTW this is the part on one of the RetroBlade2's I sent to you/Ken. It has internal pullups on WP and HOLD pins.
This is an embed external element. It can be deleted using the delete key or the backspace key. To view the full element, press the preview button below.
Comments
I think any of the 16MB flash chips which take 3-byte addresses should work. In my flash programmer, I only used the 4KB and 64KB block-erase commands, avoiding the 32KB block-erase command, since not all chips support it. I used at least four different data sheets. I think we've been using Winbond chips, since they are the most available and affordable.
I've used SST26VF064BT from Microchip and it works.
Why do 16Mb chips have to be used when 512Kb would do.
16MB chips do have to be used -- Parallax anticipated application storage on the flash, and given the low cost of these devices went with 16MB.
If you just want to boot your code and don't care about future SSD use of the extra 15.5MB, you can use a 512KB flash, or even a much smaller one, as long as it's big enough to hold your code.
Like Jon said, though, Parallax will always use a 16MB flash for future reasons.
Anything with a 3 byte address can be used , but notice that the cheapest flash parts start above 512k, so currently 2~4MBit Flash is the lowest cost at about 7c/500
Hello cgracey,
in fact I only need the code for one COG. :)
The rest is reloaded via a WLAN modul from FTP.
What makes me think is that the 16Mb Flasch uses a 3 byte addressing.
Or does that not play a role in the data transfer, on the part of P2
jrm, da habe wir uns überschnitten.
danke
500 sind ein bisschen zu viel vom guten.
Ich brauch nur 3. :)
It only needs the 3-byte address for programming, actually, using our flash programmer that is downloaded from PNut/PropTool. For booting, a standard read command $03 is issued and bits are read out of the flash chip. Any SPI flash chip can do that and is, therefore, bootable. So, the 3-byte address is really just a programming issue, not a booting issue.
If you need less than 500, check this link :)
https://lcsc.com/products/FLASH_501.html
OK now I understand some things better.
For the programming process, a program is loaded on the P2.
- 3 byte addressing
- 4KB or 64KB block-erase commands
What is still missing is the minimum clock frequency
OK here I found the W25Q128JVSIM.
4x W25Q128JVSIM + Shipping
4 * 1.91 + 4.93 = US$ 12.75
Thanks now I know what to look for.
What is still missing is the minimum clock frequency
I think it' the P2's RCFAST divided by two. That's up to 25 MHz, so the flash should at least support 12.5 MHz
As ManAtWork found out, there are chips that don't work. See here:
SPI boot ROM compatibility tests
What is still missing is the minimum clock frequency
The P2 boots with the internal RCfast oscillator (20+ MHz), the SPI clock is a fraction of that, so the slowest parts should more than fast enough.
Andy
This is correct.
I will review the Microchip datasheet.
Just for reference, I had an issue with FTDI's EVE3 GPU chip not working with my flash chip...
Like with P2, there was no table of supported chips to be found anywhere...
When I asked support about it, they gave me this list:
Appears to support every type of chip I know of, except the Microchip type I was using...
But, this was only for QPI mode. My chip did appear to work in SPI mode...
I discovered the problem with the Microchip flash chip.
When given the Bulk-Erase command ($D8), it does not always erase 64KB, like the others. The first and last blocks are erasable in only 8KB or 32KB chunks, with the 64KB blocks in the middle:
So, if we only used the Sector-Erase command ($20), which only erases 4KB, our flash loader would properly program the chip, but very slowly. This chip will boot okay, but our current flash programmer won't program it, due to this erasure peculiarity.
Ok, good to understand the reasons. Thanks, Chip
Microchip worked for me, but maybe I was using the flexprop toolchain
If your download is under 16KB, then the flash programmer in PNut will just issue 4KB Sector-Erase ($20) commands, instead of any Bulk-Erase ($D8) commands.
I just flashed a 291 kB binary using FlexProp to Microchip flash and it appears to have worked...
Thanks Chip. It's probably the same as I discovered using the S25FL256 when trying to do a chip erase with TAQOZ. I needed to do 4K erase blocks.
BTW this is the part on one of the RetroBlade2's I sent to you/Ken. It has internal pullups on WP and HOLD pins.
On the problem with the ChipErase, binn I with my programmer also already encountered.
Some were only deleted after repeated ChipErase.
I suspect that here the software write protection makes problems.
If I remember correctly, the program is transferred to write on the chip, from the PC to the P2.
Maybe in the programming tool, a preselection of problem chips, the situation could relax something.