<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Sat, 30 Aug 2008 17:53:59 +0000 (GMT)
From   : debounce@... (Greg Cook)
Subject: FRAM....

On Wed, 27/8/08, Mark Haysman <jumbos.bazzar@...> wrote:
> Hi Folks.
> 
> I've been playing with some FRAM, namely the Ramtron
> FM1808. I've got a B 
> which runs fine with the 62256 SWR mod in socket 15,
> however, it plays up 
> when I pop a FRAM in there.
> 
> If I write a ROM to it and reset the machine, it crashes. I
> initially 
> thought that it's the way the FRAM latches addresses on
> the /CE pin maybe 
> that's causing it not to write correctly, but it
> appears not. I've wired a 
> switch to /OE so I can recover the machine when it hangs.

While I hope it's fixable, the outlook doesn't look good.  Although the FRAM
on the GoMMC is controlled through the onboard logic there are often reports
of firmware corruption and hangups on the GoMMC mailing list.

> I can write data into it with *SRWRITE or my own loader
> software, and read 
> the data back out and it's identical. I can do an SWR
> RAM test on it, and it 
> passes perfectly. I've even tried storing basic &
> MC programs in it, and 
> they load back perfectly and identical, but if I write a
> ROM in it, nothing, 
> just a crash with the cursor in the top left corner. This
> is with ROMs that 
> run perfectly if I use a regular 62256 in the same socket.
> I've even 
> confirmed that it's not getting corrupted by resets or
> power-on, as any data 
> I write into it is still there perfectly after several
> power on/off 
> sequences.
> 
> Any ideas?

As the bus timing requirements are stricter than for SRAM (see datasheet), 
I think this is a pattern sensitive glitch.  On hard reset the MOS scans 
the first KB of each ROM slot to disable duplicate copies of ROMs.  This 
involves instructions LDA (&FA),Y and CMP (&FA),Y which make two consecutive 
reads from FRAM when Y and ?&FA are both >0.  So /CS may not be going high
for long enough between the reads; pulling it up may help but it also depends
on the residual charge on lines A14/15.

The test is only performed on 'valid' ROMs with a copyright string; if this
is the cause then a manual scan should corrupt *any* data in the FRAM.

As readouts on FRAM are destructive, and given that the MOS trusts paged
ROMs to return from service calls I'd personally prefer Flash here; for GoMMC
which needs the RAM function I have a 'babysitter' EPROM which reprograms
it on power up.

I should give my usual advice that any system capable of bricking should
do *at least* a CRC-16 on the loaded firmware image before upgrading the Flash.

HTH,

Greg Cook
debounce@...
http://homepages.tesco.net/~rainstorm/




      
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>