Using the 9S08AW family to download and store data to a SPI flash??

[baddad]

Has anyone tried using one of the 9S08AW devices for downloading data from a serial port into an SPI serial Flash (16Mb or 32Mb)?

I'm hoping to download large amounts of data from the serial port via hyperterm, storing as much as I can in RAM, then writing the blocks out to SPI Flash.

Any suggestions on the best way to perform any of this would be appreciated.

BadDad

Message Edited by baddad on 2007-05-18 02:44 PM

[ballen]

This is my first post to this forum, but I've been doing this kind of thing for a long time.

Specifically, what kind of suggestions are you looking for? Since the hardware to do this pretty much built into the micro, I assume you're looking for s/w ideas, but how you structure the s/w depends on a lot of factors - data rate, baud rate, language, processor speed, write speed of the flash chip, etc. To do a complete timing evaluation of all these factors and come up with a design is a fair amount of work...

B.

[baddad]

I'm planning to use a 16Mb serial SPI flash device from Intel (25FxxxS33).  It can run from DC to 33Mhz.

I plan to read a hex file from the SCI port and program it into one of three flash devices on the board.  I also need to be able to program one of the flash devices from another one which is on the same board.

Using C and a 9S08AW32 uC @ 3.3V, I want to transfer the data as fast as possible.

Speed on the SCI port will be determined by how fast I can write a block of data out the SPI port, before my input buffer overflows.

Writing from device to device; Since these flash devices support a "hold" function, I am hoping I can use the hardware SPI port with separate chipselect and hold to each device, to read in a chunk of data, place that device in hold mode, while I write that chunk into another device.  Ping ponging back ana forth until all the data is written.

I'm just looking for any advice on possible problems with this setup and suggestions on a good way to structure the software.

Thanks,

BadDad

[bigmac]

Hello BadDad,

Since the flash devices have a maximum page size of 256 bytes, I would assume that you will need to maintain a RAM buffer of this size to accumulate the data received via SCI.  This would seem to give maximum efficiency.  However, this might be modified by other considerations.

When you refer to a "hex file", do you mean a file that uses "Intel hex" format, or some other ASCII based format?  (S19 format would also be a possibility.)  If so, the number of formatted data bytes per line may also influence the approach taken, and the RAM buffer size needed.  Another approach would be to write each line to flash as it is received and verified, and would use a smaller buffer, sufficient for the amount of data per line.  This buffer is probabably in addition to the SCI receive buffer required for the "raw" ASCII data.  This approach would also provide the possibility of error detection and resend on a line by line basis.

It is probable that the SCI baud rate will determine the actual throughput, especially if the transmission time for each line is greater than the maximum page program time of 10 milliseconds.

For device to device transfers, the buffer size should preferably be 256 bytes, with a page of data read from one device, and then the data written to the other device.  This should be simpler than attempting to simultaneously communicate with multiple SPI devices  The worst case throughput would be limited to 256 bytes per 10 milliseconds, the page program time.

This discussion assumes that the flash sector is already erased - this would require an additional period of 4 seconds maximum for a 64kb sector.

Regards,

Mac

[celsoken]

Hello BadDad,

In recent past we implemented serial dataflash interface in C for HC908AP series. The interesting stuff in dataflash is low cost and internal double ram buffer, so the ammount of processor ram you will need is due to protocol handshaking procedures, e.g. 2x128 bytes for xmodem.

I hope it helps,

cheers,

Celso