EmbeddedRelated.com
Forums

External Memory Troubles

Started by will...@telus.net May 3, 2006
Hi everyone,
I'm new to this forum. I'm currently working on a project where I'm using my old MC68HC11EVBU that I got in school way back in 1998. I've been having trouble getting my expanded memory circuit to work. Everytime I try to load my .s19 file I get the message "(rom-6000)." I understand that it's saying that I'm trying to access and invalid address. I tried running the device from the EEPROM anyway and it didn't work; though I wasn't suprised by that. I believe I'm doing everything the same as before.
The memory circuit I'm using is different; I actually found a schematic for one on the internet and it looks sounds. I've prototyped the circuit on a breadboard (that was fun) and my program is using the same address ($6000) for the starting address of the program as the example that was with the schematic.
So I figured I'd go through the steps and such that I took and hope that someday can point out something I've done wrong. So here goes:
I'm using an SN74HC138N demux, SN74HC573AN D-Latch, and an AT28C64 8k x 8 EEPROM in my memory ciruit. The control lines I have connected as follows:
74HC138
Inputs
Signal Pin ID
R/!W A
AD13 B
AD14 C
AD15 !G2A
Ground !G2B
E G1
Outputs
Y7 to !Output Enable of the 28C64
Y9 to !Write Enable of the 28C64

74HC573AN
AS !LE
Ground !OE

28C64
Y7 !OE
Y9 !WE
Ground !CE I'm just using the one EEPROM chip so this can be enable always.
All the address/data lines are connected as they should be.

I hope that gives a basic idea of what I've got for the circuit.

For my EVBU I've cut the trace a J4 to initialize the device in normal expanded mode.
I'm also using a voltage regulator at U1 so I can run the device with 12V.
I tried observing the voltage on the R/!W line when I was attempting to upload my .s19 file to the device and external EEPROM and it would read 4.3V when idle and 4.5xV while the file is sending. Does this seem right? I figured the line would go low when writing to any EEPROM internal or external.

When I send the file (I'm using hyperterminal) this is the process I use:
At the BUFFALO prompt I enter: mm 102B, I then enter 35.
At this point I change the baud setting of the connection I'm using to 300. I then type load t and transfer the .s19 file. This process works great when I store a small test program between B600-B6FF. However, when I try the same program but add an extra few lines to use the extended memory I get the "(rom-6000)" error.
Here's the begin of my code:

start equ $6000
porta equ $00
portd equ $08
ddrd equ $09
pactl equ $26
regbas equ $1000
option equ $39
org $b600
jmp start
org start
lds #$0047
the rest of the code continues at this point...
So that's my situation, I must say I'm completely baffled. I don't remember having this much problem back in school. If anyone have some advice/suggestions I would greatly appreciate it.

Thanks,
William
William,

It appears your problem is that BUFFALO is trying to write your external
EEPROM as though it is external RAM. BUFFALO is working for the
internal EEPROM because it knows that the addresses $B600 to $B7FF are
EEPROM and uses a different (slow) programming method there than it does
elsewhere.

One might think that telling BUFFALO that $6000 to $7FFF also has EEPROM
and needs to use the slow programming method there. But, I do not think
it would work, because the BUFFALO programming method is for the 68HC11
EEPROM and knows none of the requirements of the AT28C64.

Therefore, I think YOU will have to write some programming code that is
compatible with the AT28C64. You would probably have to run it from
68HC11 RAM or EEPROM. (I would probably choose EEPROM so the RAM would
be available as an intermediate storage location between downloading the
.S19 and programming the external EEPROM.)

HTH,

Emmett Redd Ph.D. mailto:E...@missouristate.edu
Associate Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Dept (417)836-5131
SPRINGFIELD, MO 65897 USA

"When I was a child, I spake as a child, I understood as a child, I
thought as a child: but when I became a man, I put away childish
things," like being too embarrassed to ask questions which my peers
might think as stupid.

> -----Original Message-----
> From: m...
> [mailto:m...] On Behalf Of w...@telus.net
> Sent: Wednesday, May 03, 2006 3:45 PM
> To: m...
> Subject: [m68HC11] External Memory Troubles
>
> Hi everyone,
> I'm new to this forum. I'm currently working on a project
> where I'm using my old MC68HC11EVBU that I got in school way
> back in 1998. I've been having trouble getting my expanded
> memory circuit to work. Everytime I try to load my .s19 file
> I get the message "(rom-6000)." I understand that it's
> saying that I'm trying to access and invalid address. I
> tried running the device from the EEPROM anyway and it didn't
> work; though I wasn't suprised by that. I believe I'm doing
> everything the same as before.
> The memory circuit I'm using is different; I actually found
> a schematic for one on the internet and it looks sounds. I've
> prototyped the circuit on a breadboard (that was fun) and my
> program is using the same address ($6000) for the starting
> address of the program as the example that was with the schematic.
> So I figured I'd go through the steps and such that I took
> and hope that someday can point out something I've done
> wrong. So here goes:
> I'm using an SN74HC138N demux, SN74HC573AN D-Latch, and an
> AT28C64 8k x 8 EEPROM in my memory ciruit. The control lines
> I have connected as follows:
> 74HC138
> Inputs
> Signal Pin ID
> R/!W A
> AD13 B
> AD14 C
> AD15 !G2A
> Ground !G2B
> E G1
> Outputs
> Y7 to !Output Enable of the 28C64
> Y9 to !Write Enable of the 28C64
>
> 74HC573AN
> AS !LE
> Ground !OE
>
> 28C64
> Y7 !OE
> Y9 !WE
> Ground !CE I'm just using the one EEPROM chip so
> this can be enable always.
> All the address/data lines are connected as they should be.
>
> I hope that gives a basic idea of what I've got for the circuit.
>
> For my EVBU I've cut the trace a J4 to initialize the device
> in normal expanded mode.
> I'm also using a voltage regulator at U1 so I can run the
> device with 12V.
> I tried observing the voltage on the R/!W line when I was
> attempting to upload my .s19 file to the device and external
> EEPROM and it would read 4.3V when idle and 4.5xV while the
> file is sending. Does this seem right? I figured the line
> would go low when writing to any EEPROM internal or external.
>
> When I send the file (I'm using hyperterminal) this is the
> process I use:
> At the BUFFALO prompt I enter: mm 102B, I then enter 35.
> At this point I change the baud setting of the connection I'm
> using to 300. I then type load t and transfer the .s19 file.
> This process works great when I store a small test program
> between B600-B6FF. However, when I try the same program but
> add an extra few lines to use the extended memory I get the
> "(rom-6000)" error.
> Here's the begin of my code:
>
> start equ $6000
> porta equ $00
> portd equ $08
> ddrd equ $09
> pactl equ $26
> regbas equ $1000
> option equ $39
> org $b600
> jmp start
> org start
> lds #$0047
> the rest of the code continues at this point...
> So that's my situation, I must say I'm completely baffled. I
> don't remember having this much problem back in school. If
> anyone have some advice/suggestions I would greatly appreciate it.
>
> Thanks,
> William
>
>
w...@telus.net wrote:
> Hi everyone,
> I'm new to this forum.

Welcome! It's about dead around here, so it's always nice to
find another afficianado.

>
> I'm currently working on a project where I'm using my old
> MC68HC11EVBU
> that I got in school way back in 1998. I've been having trouble getting
> my expanded memory circuit to work. Everytime I try to load my .s19 file
> I get the message "(rom-6000)." I understand that it's saying that I'm
> trying to access and invalid address. I tried running the device from
> the EEPROM anyway and it didn't work; though I wasn't suprised by that.
> I believe I'm doing everything the same as before.

How about hitting return once in a while?

Also, since I see that you hit return infrequently, I presume you
may also be prone to top-posting. If you are, or if you don't
know what that means, please read this: http://ursine.ca/Top_Posting
before replying. You'll save me some irritation.

BUFFALO doesn't know that this is an external EEPROM, and does
an immediate read back. EEPROMs are set up to ensure that until
programming is complete they cannot read back as written.

> The memory circuit I'm using is different; I actually found a
schematic for one on the internet and it looks sounds. I've prototyped
the circuit on a breadboard (that was fun) and my program is using the
same address ($6000) for the starting address of the program as the
example that was with the schematic.

Instead of my trying to read all that gunk about how you have things
connected, how about you post the URL for the circuit, and we can
just look at it?

[snip]

> For my EVBU I've cut the trace a J4 to initialize the device in normal expanded mode.
> I'm also using a voltage regulator at U1 so I can run the device with 12V.
> I tried observing the voltage on the R/!W line when I was attempting
to upload my .s19 file to the device and external EEPROM and it would
read 4.3V when idle and 4.5xV while the file is sending. Does this seem
right? I figured the line would go low when writing to any EEPROM
internal or external.

Err, have you looked at the timing on that? It's going up and down
for each memory access, including the fetches of instructions for
BUFFALO execution. You'd have to look with a 'scope to see it
bouncing around, and you'd need either a fancy trigger or a
logic analyzer to ensure that the writes were to your external
device.

> When I send the file (I'm using hyperterminal) this is the process I use:
> At the BUFFALO prompt I enter: mm 102B, I then enter 35.
> At this point I change the baud setting of the connection I'm using
> to
300. I then type load t and transfer the .s19 file. This process works
great when I store a small test program between B600-B6FF. However, when
I try the same program but add an extra few lines to use the extended
memory I get the "(rom-6000)" error.

That's because BUFFALO "knows" that there is on-board EEPROM at locaion
$B600-$B7FF, but it does *not* know that you have slow memory at
location $6000. So, it converts the Srecord to a byte, writes the
byte to memory, and does an immediate read back. This gives a mismatch,
and there you are.

> Here's the begin of my code:

[snip]

> So that's my situation, I must say I'm completely baffled. I don't
remember having this much problem back in school. If anyone have some
advice/suggestions I would greatly appreciate it.

I hope what I wrote clarifies the situation, even if it doesn't
help much.

One way to do what you want is write your own little EEPROM
writer program. It'll be much faster, too.

Load your program into RAM at a location other than where it is
intended to be loaded. You can use BUFFALO 3.4 for this. You might
want to get the latest version and blow it to EPROM and replace
what is on your EVBU. IIRC, those old boards used something like
3.2 or even 2.4 BUFFALO. If you use 3.4 BUFFALO, you can specify
an offset for loading.

Then load your little writer into RAM somewhere else. Put it where
it is intended to load. Or, put it into the EEPROM at $B600 and
it'll "always" be there.

Then run your little writer. It should transfer a row at a time
(usually 16 bytes) and will be significantly faster than trying
to program byte-by-byte as BUFFALO does, even if you could get
it to do what you want (which you can't).

I've got some code somewhere I use for cloning copies of BUFFALO
onto EEPROM which does this. I put it into the $B600 EEPROM,
so you can, too. You'd want to jigger it up to take starting,
ending (or size) and destination addresses in RAM, say at
$0000, $0002, and $0004. I'll go looking and post back, if
you are interested.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
w...@telus.net wrote:

[that he had problems with writing and external EEPROM]

To the group as a whole: I hope this source isn't bigger
than irritates you. If so, then next time, I'll send
this stuff in a private e-mail.

I found my program to duplicate a ROM to an EEPROM. You'll
want either to edit the equates for SOURCE, END_SOURCE, and DEST, or
make it read from low RAM or something. Note the little
jump table at the beginning, which makes it easy to use
the BUFFALO CALL command. Also, the JMP SOURCE presumes
to do a cold start on BUFFALO. You'll want to change that.
This is a little thing I did in about 1/2 hour when I
needed a dup of BUFFALO.

You can copy to EEPROM, verify the contents against the
source, set the write protect bits in the EEPROM, or
clear them. The verify routine simply stores the location
of the first mismatch and the bad contents at locations
$0000 and $0002.

To use the protect/unprotect routines with variable
addresses, you'd need to load up X and Y with the computed
destination addresses, and used indexed writes.
Note that (UN)PROTECT may clobber some memory. I thought it
did at the time, anyway, so it copies again. You may
want to experiment with that.

The row size is 64 bytes, not 16. That's the row size
in the internal EEPROM. I guess I didn't recall that.

No checks are made that the destination address begins
on a row boundary. Make sure that the destination
address is divisible by 64. In fact, no checks are made
on anything at all!

So, program this into the internal EEPROM, suitably
modified, use BUFFALO to load your program to another
address than $6000 (run at 9600 BAUD!) and then use
this little program to copy to the external EEPROM.

Not even commented, sheesh!

I retain all rights, but permit use for non-commercial
purposes.

Here's the source...

*
* This program duplicates ROM from $E000 through $FFFF
* into EEPROM located at $8000, assuming an X28C64 or
* similar EEPROM. It uses the 64 byte page write mode,
* and checks for completion by using the toggle bit.
*

ORIGIN equ $B700 Place to put code

SOURCE equ $E000
END_SOURCE equ $0000
DEST equ $8000
BLOCK_SIZE equ 64

org ORIGIN

bra CopyRom
bra VerifyRom
bra ProtectRom
bra UnprotectRom

CopyRom:
ldx #SOURCE
ldy #DEST
Again:
cpx #END_SOURCE
bne Another

jmp SOURCE BUFFALO?
Another:
bsr CopyBlock Copy 64 bytes
bra Again

CopyBlock:
ldab #BLOCK_SIZE
CB1:
ldaa 0,x
staa 0,y
inx
iny
decb
bne CB1

dey Back up to last byte written
CB2:
cmpa 0,y Watch for write to complete
bne CB2

iny Forward to next byte to write

rts

VerifyRom:
ldx #SOURCE
ldy #DEST
VR1:
cpx #END_SOURCE
bne VR2

rts
VR2:
ldaa 0,x
cmpa 0,y
beq VR3

sty 0
staa 2
jmp SOURCE
VR3:
inx
iny
bra VR1

ProtectRom:
ldaa #$AA
staa DEST+$1555
ldaa #$55
staa DEST+$0AAA
ldaa #$A0
staa DEST+$1555
Rewrite:
ldx #SOURCE+$1540
ldy #DEST+$1540
bsr CopyBlock
rts

UnprotectRom:
ldaa #$AA
staa DEST+$1555
ldaa #$55
staa DEST+$0AAA
ldaa #$80
staa DEST+$1555
ldaa #$AA
staa DEST+$1555
ldaa #$55
staa DEST+$0AAA
ldaa #$20
staa DEST+$1555
bra Rewrite

HTH

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
On Wed, 2006-05-03 at 17:10 -0500, Mike McCarty wrote:
> I hope this source isn't bigger than irritates you.

I rather doubt that anyone would object to any amount of well-written
code.

It occurs to me that far more than comments, the Protect/UnprotectRom
code is screaming out for a macro assembler:

> mova #$AA,DEST+$1555
> mova #$55,DEST+$0AAA
> mova #$A0,DEST+$1555 ... etc.

--
Cheers,
Paul B.

On Wed, 2006-05-03 at 17:10 -0500, Mike McCarty wrote:
>> I hope this source isn't bigger than irritates you.
>
Wow! Those were some quick responses. And thanks for the code.

In case you're still curious the link to the circuit I found on the net is:
http://filebox.vt.edu/users/dtemple/us/CLASS%20STUFF/Micro/Project%20%233/Kalanick's%20Micro%20Lab%20%233.doc

It's a students lab document; the schematic is on page 7

I know that it was never that complicated back when I was in school. We were able to wire up the circuit and then just transfer/upload the file to the EVBU and it would be store in the external EEPROM. Of course it's been 7 years since I've looked at this so I'm probably just missing one small step.

If I can't get this figured out I have your suggestions to try. Thanks again.

Will
Paul B. Webster VK2BZC wrote:
> On Wed, 2006-05-03 at 17:10 -0500, Mike McCarty wrote:
>
>>I hope this source isn't bigger than irritates you.
> I rather doubt that anyone would object to any amount of well-written
> code.

I don't consider it well-written. It's something I tossed together
in about 1/2 hour in order to duplicate BUFFALO into some EEPROMs
I had a couple of years ago.

> It occurs to me that far more than comments, the Protect/UnprotectRom
> code is screaming out for a macro assembler:
>> mova #$AA,DEST+$1555

Aside from the fact that I don't like the destination on the
right, all this needs is an equate, not a macro.

Anyway, hope that code helped someone.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!