From: Daniel Kahlin (tlr_at_stacken.kth.se)
Date: 2003-01-26 10:43:16
Hi,
I don't think it is true that you must write the flash in sequence, but
you usually have to be able to write commands to specific areas in the
flash. Thus you must know (atleast partly) how the addresses of the flash
are mapped.
Also note that in Flash (and EEPROM) you can only write '0'-bits, thus
a byte that you are about to write to has to be 0xff (or atleast have no
bits that should be '1' already set to '0').
Regards
/Daniel Kahlin
On Sun, 26 Jan 2003, Gideon Zweijtzer wrote:
> Hi Marko!
>
> With Flash, you cannot exchange all address lines. Depending on the
> actual chip you are using, you should leave the sectors in tact, and
> program them one by one. This means that you will have to leave the
> higher address lines connected un-shuffled.
>
> I hope that solves the problem. Which Flash are you using? An Am29F040?
>
> Gideon
>
> -----Original Message-----
> From: owner-cbm-hackers@cling.gu.se
> [mailto:owner-cbm-hackers@cling.gu.se] On Behalf Of Marko Mäkelä
> Sent: Saturday, January 25, 2003 20:18
> To: cbm-hackers@cling.gu.se
> Subject: Odd flash behaviour
>
> Hi all,
>
> I have made some experiments with the VIC-20 cartridge prototype, which
> only has 512 kilobytes of flash ROM. I've started writing a flashing
> utility
> that can successfully clear the chip. (I've verified it by reading 8
> kilobytes of $ff from the chip.)
>
> However, when I program 8 kilobytes of the chip (that would be random
> locations in the chip, since I have shuffled the address lines to
> simplify
> the circuit board), some bytes that should be $ff are instead $fe or
> $fd.
>
> The embedded programming algorithm in the chip does not report any
> errors,
> and my program also checks that after programming a byte, it must read
> back
> the same within 256 retries. I also tried a modification that would
> skip
> any $ff bytes, but it didn't change anything. All other bytes than
> these
> $ff's are programmed correctly. Has anyone else had similar experience?
> Any ideas or suggestions?
>
> The next logical step is to read the whole chip (off the system) and
> check
> if the remaining 512-8 kilobytes of the chip are $ff, as they should. I
> hope they are, since anything else would indicate a hardware problem.
>
> Marko
>
> Message was sent through the cbm-hackers mailing list
>
>
> Message was sent through the cbm-hackers mailing list
>
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.4.