TomNisbet / TommyPROM

Simple Arduino-based EEPROM programmer
https://tomnisbet.github.io/TommyPROM/
143 stars 29 forks source link

please add support for AT29C020 device (Atmel TSOP32 Flash) #52

Closed invictus737 closed 2 months ago

invictus737 commented 1 year ago

Kindly please extend the code to cover Atmel 29C020 devices

Thx! Chris

TomNisbet commented 1 year ago

AT29C020 are already supported using the default 28C code. See the docs here: https://tomnisbet.github.io/TommyPROM/prom-families/#29c-series

invictus737 commented 1 year ago

Hi,

are you sure? as Atmel AT29C020 is a 256bytes/sector device.

Regards, Chris

invictus737 commented 1 year ago

datasheet https://www.digchip.com/datasheets/download_datasheet.php?id=164019&part-number=AT29C020

prlaba commented 1 year ago

I tried an Atmel 29c020 (2M 256K x 8) with TommyProm and it didn't work. It's a flash with 256-byte sectors and must write an entire sector at a time (cannot write partial sectors). As best I can tell from reading the TommyPROM code, it writes whatever its own buffer size is (single bytes with using the Fill option).

I started working on revising the code to properly handle the Atmel flash chips (the 29c040 is another).

TomNisbet commented 1 year ago

You are correct. The Winbond 29C020 has a 128 byte sector but the Atmel is 256. I thought only the 040s used the larger sector size.

To support that, you will need to buffer up two packets of data to do a single write operation. You may need to strip some code out to free enough RAM.

prlaba commented 1 year ago

Tom, does the Nano have enough room to support a 256-byte buffer?

Also why would you need two buffers? Seems to me only one is needed.

To write a full sector you would load the buffer with the 256 bytes to be written, then write them, one at a time, each write within 150 msecs of the previous, then wait while the chip writes out the sector.

To write a partial sector, you would read all 256 bytes of the sector into the buffer, modify the bytes you want in the buffer (leaving the other bytes in the buffer unchanged), then write the individual bytes in buffer to the sector, per above.

TomNisbet commented 1 year ago

The nano has 2K of RAM, but I don't remember how much is free in the current build of TommyPROM. Unfortunately, I don't have access to any nanos at the moment, so I can't look at it. I suspect you could strip out a few features if more space is needed for the larger buffer.

Adding support for the 256 buffer could be fairly simple, depending on how many edge cases you want to support. The XModem protocol uses a fixed 128 byte buffer, so TommyPROM will receive the data for the EEPROM in 128 byte chunks. If you just want to support burning a whole chip and assume that the received data will be on sector boundaries, then the code extension is fairly simple:

Things get a lot more complicated if you want to support arbitrary writes to the chip. For example, if you try to write 1024 bytes starting at address 5 instead of at 0, then you need to read the existing data to a buffer and merge the newly received data with the existing chip contents for the first and last sectors. That's probably an odd enough case that it isn't worth doing. There's probably not enough RAM to support it either, because you would need 128 bytes for a receive buffer plus an additional 256 bytes for the read/write buffer.

prlaba commented 1 year ago

Thanks Tom, that all makes sense.

I agree, for programming the chip it's reasonable to assume that the start address is on a sector boundary. But if the size of the file being downloaded is not be a multiple of the sector size, the last sector to be written will be partial.

I don't know all the details of the XModem protocol. Is the 128-byte size fixed? Could you increase it to 256 bytes to match the flash's 256-byte sector size? If not you'd need to toggle the 256-byte buffer's load address between 0x00 and 0x8F as you input each 128 bytes of XModem data.

I'm not sure what XModem does if it receives less than 128 bytes. Zero the remaining bytes? Either way, you could end up with a multiple of 256 bytes of XModem data (no partial last sector) or multiple of 128 bytes (partial last sector). In the case of a partial last sector you could zero-fill the last 128 bytes of the sector.

But if you want other TommyPROM features, like Fill, to work correctly with flash, it would need to be able to write any number of bytes (up to the sector size) to a sector, starting at any offset within the sector. To do that it would need to first read the sector into the 256-byte buffer, modify the bytes to be written, then write the buffer to the sector.

TomNisbet commented 1 year ago

The 128 byte buffer size is fixed, so you would need to manage storing two packets worth of data into the write buffer and then burning it to the chip when the buffer fills.

I don't believe that XModem guarantees the contents of the buffer end if the data is not a multiple of 128 bytes. This isn't usually a problem and you can always pad your file if it is.