Alternatives to Atmel Flash AT25FS010?

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
User avatar
GeorgeIoak
Active Member
Posts: 56
Joined: Wed May 19, 2010 9:42 pm

Post by GeorgeIoak »

I thought I would update everyone on this forum about this part. I did order the SST SST25VF010A-33-4C-SAE and was about to use but sent an email to my XMOS contact and he replied back with the following:

This is one of the few parts we don’t support, as it doesn’t support page writes.
Here is a similar part from Winbond which we do support W25X10BVSNIG

He is compiling a list of approved parts and as soon as I get it I will post back for everyone. The Winbond part that he recommended is available at DigiKey but it is not supported by any other distributor.


misterten
Member++
Posts: 19
Joined: Mon Aug 08, 2011 10:06 am

Post by misterten »

So, where's the list? :roll:

I am not that familiar to Flashes: Atmel has got some device families such like DataFlash, Block Erase, Quad I/O Block Erase and 1.8V Block Erase. Is the AT25DF021 e.g. which belongs to Block Erase Family compatible for use instead of the AD25FS010 which belongs to DataFlash Family?

--- cut ---

okay, just found the list here. But why does there exist a library? Do I have to recompile when using another Flash? I thought it would not matter when instruction set and pin compatbility where given...!? :?

Thanks
MaxFlashrom
Experienced Member
Posts: 82
Joined: Fri Nov 05, 2010 2:59 pm

Post by MaxFlashrom »

segher wrote:SPI flash is an industry standard, every chip uses the same basic protocol.

Pick a chip you like, and then check the pinout, the voltages, the power consumption,
and make sure the command 03 is "read data" (or "slow read") (this is the only command
the xmos devices use to boot from the flash).

Pretty much the same procedure as you would use for finding an alternative part for
anything -- read the datasheets :-)


Segher
It's true that the boot loader only uses slow read. The problem is that there is some variation in command sets/internal buffer architecture/size of eraseable & programmable blocks and particularly in sector sizes. The XMOS tools need to be told how to recognise a device along with its sector sizes/write-commands/sector locking mechanism, for devices that are not in its built-in list. This is important to xflash, which people usually use to program their flash devices(at least during development). Also if people want to use the XMOS flashlib API at run-time within their programs the program needs to know this. Flash lib tries to interrogate the flash device for a unique ID to work out what it is. Unfortunately even this recognition mechanism is not always the same, especially for older devices. This can be problematic.

If one has a flash device externally programmed by some other tool/process and your program does not need to use the flash API then, as you say, all you need to worry about is its support for slow read.

Regards
Max.