Uploading software to external RAM on HC11
Alex Wiecek
I've been playing with the HC11 for quite a while now, writing
numerous routines for the chip. Unfortunately, the 256 bytes of RAM
that I have available on the A8 falls a "little" short of what I'm
trying to write now.
As such, I decided to use an external RAM to store the program, but
because of this configuration a few questions come to mind:
1. How do I upload the software to the SRAM chip? I'm using ASM11 for
programming, compiling and uploading. Can I still use ASM11 to upload
the program to the processor or do I have to program the SRAM (battery
backed) on an EEPROM programmer (I've got Chipmaster 2000) and then
plug it into the circuit?
2. How do I tell the HC11 where to find the new program? I'm assuming
the HC11 will be looking for it at location $0000 where the internal
RAM resides but in fact the new software will be at a totally
different place.
Any help would be greatly appreciated...
Alex
Leif Holmgren
>
> 1. How do I upload the software to the SRAM chip? I'm using ASM11 for
> programming, compiling and uploading. Can I still use ASM11 to upload
> the program to the processor
I don't know what ASM11 but the general procedure would be that you will
have to upload a small boot-loader program into the first 256 bytes.
This boot-loader can then load your "real" program into external RAM.
> 2. How do I tell the HC11 where to find the new program? I'm assuming
> the HC11 will be looking for it at location $0000 where the internal
> RAM resides but in fact the new software will be at a totally
> different place.
The boot-loader you first upload should do a branch to the location
where you have stored the program.
I use a very nice little software called JBUG11 that includes
boot-loaders for different HC11 variants and a debugger so that you can
trace and single-step the code. JBUG11 can be found at:
http://freespace.virgin.net/john.beatty/Jbug11_main.html
Good Luck
/Leif
Albert Lee Mitchell
> Alex Wiecek wrote:
> >
> > 1. How do I upload the software to the SRAM chip? I'm using ASM11 for
> > programming, compiling and uploading. Can I still use ASM11 to upload
> > the program to the processor
>
> I don't know what ASM11 but the general procedure would be that you will
> have to upload a small boot-loader program into the first 256 bytes.
> This boot-loader can then load your "real" program into external RAM.
>
> > 2. How do I tell the HC11 where to find the new program? I'm assuming
> > the HC11 will be looking for it at location $0000 where the internal
> > RAM resides but in fact the new software will be at a totally
> > different place.
>
> The boot-loader you first upload should do a branch to the location
> where you have stored the program.
Leif has it right if you're using the standard system, but there is
another option, investigate the MODA and MODB pins. In the right
configuration this invokes an internal bootstrap firmware within the 6811.
My recollection is hazy but I think it's limited to some byte size like
256 bytes so you have to write/load an intermediate bootloader to load a
larger program.
The second caveat is that the baud rate is usually non-standard, at least
with most standard crystal frequencies. But it is quite feasible to load
a large program with absolutely no ROM of any kind.
Our Version 3 s/w utilized this technique even allowing bootloading of a
tweaked version of Motorola's BUFFALO monitor program into RAM. Our 6811
SBC's ran at 10Mhz so the serial Baud rate was something weird like 7816
baud but it's not that difficult to set your communications program to
that value if you write it yourself. Once bootstrapped your code should
reset the baud rate to a more standard value.
-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc. The Embedded Systems Experts
http://www.amresearch.com (916) 780-7623
----------------------------------------------------------------------
Alex Wiecek
> Alex Wiecek wrote:
> >
> > 1. How do I upload the software to the SRAM chip? I'm using ASM11 for
> > programming, compiling and uploading. Can I still use ASM11 to upload
> > the program to the processor
>
> I don't know what ASM11 but the general procedure would be that you will
> have to upload a small boot-loader program into the first 256 bytes.
> This boot-loader can then load your "real" program into external RAM.
>
a number of years ago I did play around with my friend's EV board that
had a bootloader loaded into the ROM called BUFALO. I believe it
served as the bootloader program.
> > 2. How do I tell the HC11 where to find the new program? I'm assuming
> > the HC11 will be looking for it at location $0000 where the internal
> > RAM resides but in fact the new software will be at a totally
> > different place.
>
> The boot-loader you first upload should do a branch to the location
> where you have stored the program.
>
machine code and I want to replace the SRAM (which acts as a temporary
software storage at this moment until the code is finalized) with an
EEPROM and I want the whole circuit work all by itself from the get go
(reset). How does it know where to look for the software if there is
nothing in the internal RAM to vector it to the EEPROM location?
> I use a very nice little software called JBUG11 that includes
> boot-loaders for different HC11 variants and a debugger so that you can
> trace and single-step the code. JBUG11 can be found at:
> http://freespace.virgin.net/john.beatty/Jbug11_main.html
>
> Good Luck
> /Leif
Thanks for the link Leif. This seems like an interesting piece of
software as the ASM11 is a little cumbersome and sometimes flaky on
the upload.
Thanks again,
Alex
Alex Wiecek
> > where you have stored the program.
>
> Leif has it right if you're using the standard system, but there is
> another option, investigate the MODA and MODB pins. In the right
> configuration this invokes an internal bootstrap firmware within the 6811.
> My recollection is hazy but I think it's limited to some byte size like
> 256 bytes so you have to write/load an intermediate bootloader to load a
> larger program.
>
Hi Albert.. thank you for the response. Yes, at the moment MODA and
MODB are both grounded (I believe) which uploads the software into the
internal RAM.
And yes, you're right - it is limited to 256 bytes which, in my case,
is a little too small for the application I'm trying to write.
> The second caveat is that the baud rate is usually non-standard, at least
> with most standard crystal frequencies. But it is quite feasible to load
> a large program with absolutely no ROM of any kind.
>
> Our Version 3 s/w utilized this technique even allowing bootloading of a
> tweaked version of Motorola's BUFFALO monitor program into RAM. Our 6811
> SBC's ran at 10Mhz so the serial Baud rate was something weird like 7816
> baud but it's not that difficult to set your communications program to
> that value if you write it yourself. Once bootstrapped your code should
> reset the baud rate to a more standard value.
>
At the moment, I'm using a 4192 kHz crystal and I'm able to
communicate with the chip at 4800 baud. According to the specs I have
here, it would seem that with this crystal plugged in, I should be
able to communicate with it at 9600 baud but for some strange reason
the chip doesn't want to talk to the laptop at this rate, and as such
I had to drop it to 4800 where it seems happy.
So the consensus is to load up a intermediate program into the memory
to allow it to transfer larger programs into the external RAM. Well,
it's a good thing I asked the question because I would've been pulling
hairs right about now. :)
Thanks again!
Best Wishes.
Alex
Thierry C. (NOOS)
Still playing with HC11 MCUs, I'd like to give you extra informations
that could help you (see inline text).
> [...]
> > The boot-loader you first upload should do a branch to the location
> > where you have stored the program.
... and update first the SMOD and MDA bits from the HPRIO register in order
to switch to another operating mode (remember that MODA and MODB only set it
on reset) : either to extended mode, or even to special test mode (maybe not
too dangerous for the chip if you don't set the test options in the
registers, but has the advantage to let some registers unlocked from their
time-protected writing mechanism).
> OK, this begs a question: let's say that I'm happy with the final
> machine code and I want to replace the SRAM (which acts as a temporary
> software storage at this moment until the code is finalized) with an
> EEPROM and I want the whole circuit work all by itself from the get go
> (reset). How does it know where to look for the software if there is
> nothing in the internal RAM to vector it to the EEPROM location?
At this point, you need to run your code directly after a power-on reset.
For this, you'll need to update your program to set all the interrupt
vectors in a nonvolatile location (external EEPROM or the internal EPROM or
EEPROM, provided you can map it to the end of the address space) so that the
starting address of your program is hard-coded in $FFFE-$FFFF (power-on
reset) and the other interrupt vectors are somewhere just before, rather
than being initialized by software to point on the RAM pseudo-vectors.
Back to the (E)EPROM setting and programming :
- you need to make it appear at the end of the address space (because the
interrupt vectors are looked up there) : either you can relocate the
internal EPROM (or the EEPROM but I'm not sure for this MCU reference) by
setting some configuration registers, or you can map the external EEPROM to
the end of the memory by using an appropriate address-decoding logic : here
is a simple example http://martial.benoit.free.fr/newhc11f1.html (the link "
schéma ZIPé " will give you the schematic ; the other one on this page
doesn't work on IE). Unfortunately the site's owner seems to have gone away
for further informations like programming the EEPROM.
To program one of the nonvolatile memory, you can use JBug11 for the A8
internal EPROM. But if you need to program your external EEPROM, it won't
help you because it isn't compatible with the EEPROM automated writing
mechanism. In this case, if you've got an EEPROM programmer, you may
transfer easily your program on it. Otherwise you'll need a little software
to upload it. The website owner has got one (it only works for the addresses
between $8000 and $FFFF). I've tried it, but since the Windows (Visual
Basic) version often exits with runtime errors, I reverse-engineered his old
Basic-based version and my own VB one (rather good error checking but
annoying limitations in baud rates caused by the use of the MSComm control
for the serial communication) but I re-used his bootloaders as is. You can
ask me for it if you need.
> > I use a very nice little software called JBUG11 that includes
> > boot-loaders for different HC11 variants and a debugger so that you can
> > trace and single-step the code. JBUG11 can be found at:
> > http://freespace.virgin.net/john.beatty/Jbug11_main.html
Very good software in my opinion too !
Hope I haven't been too much off-topic and I brought you the required help
without having repeated things you already know.
--
Thierry C.
to e-mail me, just remove the words "spam" and "sucks" from the From field's
address
Leif Holmgren
> Leif Holmgren <nob...@nowhere.com> wrote in message news:<3FA57628...@nowhere.com>...
>
>>Alex Wiecek wrote:
>
> Hi Leif... thank you for the reply. You have jogged my memory a bit as
> a number of years ago I did play around with my friend's EV board that
> had a bootloader loaded into the ROM called BUFALO. I believe it
> served as the bootloader program.
I have never used the BUFFALO monitor myself but I believe it can do a
lot more than just act as a bootloader. If you do a net-search you might
be able to find it somewhere so that you can put it into a PROM and use
as you like.
> OK, this begs a question: let's say that I'm happy with the final
> machine code and I want to replace the SRAM (which acts as a temporary
> software storage at this moment until the code is finalized) with an
> EEPROM and I want the whole circuit work all by itself from the get go
> (reset). How does it know where to look for the software if there is
> nothing in the internal RAM to vector it to the EEPROM location?
Without reading up on this I can't tell you exacly how to do it and I
have all my HC11 manuals packed down due to a rebuild of my private
workshop. If i'm not mistaken there is a really small amount of on-chip
EEPROM where config register and boot vectors are located, but I might
confuse this with some other chip. Anyway, there are different operating
modes the chip can enter depending on the MOD-pins, just as Albert
mentioned. Check the HC11 documentation for more information.
> Thanks for the link Leif. This seems like an interesting piece of
> software as the ASM11 is a little cumbersome and sometimes flaky on
> the upload.
JBUG11 is indeed very useful but so far does not contain an internal
assembler or simulator, and does not allow for source-level debugging
for those not writing code in assembler. This may change as the sources
are available and someone hinted on the JBUG mailing list a few days ago
that he was thinking about adding an assembler.
When I started using JBUG11 there was one minor problem. The amount of
stack available after loading the talker is very small. <10 bytes. So if
your program uses a few JSR's you very fast get into trouble. I rewrote
one of the existing talkers to put the stack in exteral RAM instead,
which solved my problems. If there are no newer talkers available I
could send you one that works.
/Leif
Alex Wiecek
> > a number of years ago I did play around with my friend's EV board that
> > had a bootloader loaded into the ROM called BUFALO. I believe it
> > served as the bootloader program.
>
> I have never used the BUFFALO monitor myself but I believe it can do a
> lot more than just act as a bootloader. If you do a net-search you might
> be able to find it somewhere so that you can put it into a PROM and use
> as you like.
>
Hello Leif, sorry for the delay here...
I have used BUFFALO in the past and I remember it was a snap trying to
upload a program into the hc11's external memory.
I should do more research as to where I could find it, etc.
> > OK, this begs a question: let's say that I'm happy with the final
> > machine code and I want to replace the SRAM (which acts as a temporary
> > software storage at this moment until the code is finalized) with an
> > EEPROM and I want the whole circuit work all by itself from the get go
> > (reset). How does it know where to look for the software if there is
> > nothing in the internal RAM to vector it to the EEPROM location?
>
> Without reading up on this I can't tell you exacly how to do it and I
> have all my HC11 manuals packed down due to a rebuild of my private
> workshop. If i'm not mistaken there is a really small amount of on-chip
> EEPROM where config register and boot vectors are located, but I might
I did some more reading on the subject. It turns out it's quite simple
and it depends on the condition of the MODA and MODB pins. The on
board EEPROM contains reset vectors that can be programmed to just
about anything to point to the external memory. This EEPROM can be
disabled but then you'd have to provide reset vectors on the external
memory at locations FFFE-FFFF
> confuse this with some other chip. Anyway, there are different operating
> modes the chip can enter depending on the MOD-pins, just as Albert
> mentioned. Check the HC11 documentation for more information.
>
Done... :)
> JBUG11 is indeed very useful but so far does not contain an internal
> assembler or simulator, and does not allow for source-level debugging
> for those not writing code in assembler. This may change as the sources
> are available and someone hinted on the JBUG mailing list a few days ago
> that he was thinking about adding an assembler.
>
Yes, that would make it a very nice utility.
> When I started using JBUG11 there was one minor problem. The amount of
> stack available after loading the talker is very small. <10 bytes. So if
> your program uses a few JSR's you very fast get into trouble. I rewrote
> one of the existing talkers to put the stack in exteral RAM instead,
> which solved my problems. If there are no newer talkers available I
> could send you one that works.
>
You brought up an interesting point...
Aside from trying JBUG, I was actually able to program the external
SRAM using a Chipmaster EEPROM programmer. The test software on the
EEPROM works great except one problem:
This works
LOOP LDAA #$41
STAA $1030
BRA LOOP
But this doesn't:
LOOP LDAA #$41
STAA $1030
JMP LOOP
One is using relative branching, the other a direct jump. Both are
essentially doing the same thing but the one using the JMP (or even
JSR) doesn't work.
WOuld this have something to do with the stack (or lack thereof?)
Alex
Leif Holmgren
Alex Wiecek wrote:
> You brought up an interesting point...
>
> Aside from trying JBUG, I was actually able to program the external
> SRAM using a Chipmaster EEPROM programmer. The test software on the
> EEPROM works great except one problem:
>
> This works
>
> LOOP LDAA #$41
> STAA $1030
> BRA LOOP
>
> But this doesn't:
>
> LOOP LDAA #$41
> STAA $1030
> JMP LOOP
>
> One is using relative branching, the other a direct jump. Both are
> essentially doing the same thing but the one using the JMP (or even
> JSR) doesn't work.
> WOuld this have something to do with the stack (or lack thereof?)
No, this is something different.
The first code works because it assembles into position independent
code. This set of instructions can be placed anywhere and executed. The
branch instruction just directs the program counter to a few steps back.
The second example likely does not work because you have not told the
assembler where the code is going to be placed. My guess is that it
would guess it will be placed at $0000, which mean that the JMP LOOP
instruction would take the CPU somewhere the program is not. You need a
ORG directive for the assembler in this case.
BSR would work a few times for the same reason, it makes a subroutine
call relative to the current Program Counter but JSR would not work
because it would jump to somewhere strange.
Even BSR would fail after a while when the stack hits your program and
overwrites it.
Find a way to make your assembler output a listing. Then you can see in
the list file where the assembler assumes the code is ending up. With
the assembler I use you add -l to the command line and it will generate
a listfile. The product I use to edit and assemble most of my HC11 code
is called MiniIDE and can be found at http://www.mgtek.com/miniide/
It contains a editor with syntax highlighting and a "built-in" assembler
for HC11 and HC12.
/Leif
Alex Wiecek
> > essentially doing the same thing but the one using the JMP (or even
> > JSR) doesn't work.
> > WOuld this have something to do with the stack (or lack thereof?)
>
> No, this is something different.
>
> The first code works because it assembles into position independent
> code. This set of instructions can be placed anywhere and executed. The
> branch instruction just directs the program counter to a few steps back.
>
> The second example likely does not work because you have not told the
> assembler where the code is going to be placed. My guess is that it
> would guess it will be placed at $0000, which mean that the JMP LOOP
> instruction would take the CPU somewhere the program is not. You need a
> ORG directive for the assembler in this case.
>
can be placed pretty much anywhere due to its relative nature (ie. go
up or down a few steps as opposed to go to a specified address)
However, I manually edited the machine code to make sure that the JMP
or JSR instructions point to the proper address, the one that needs to
be executed next.
I couldn't use the ORG command because my Chipmaster programmer would
put the program at the location specified by the ORG command, instead
of putting it starting at address $0000 (EEPROM location $0000 is
equivalent to HC11 location $E000 in my case). Just FYI, Chipmaster is
a standalone memory programmer and as such I had to adjust the
addressing appropriately - yes I know, too tedious.
> BSR would work a few times for the same reason, it makes a subroutine
> call relative to the current Program Counter but JSR would not work
> because it would jump to somewhere strange.
>
> Even BSR would fail after a while when the stack hits your program and
> overwrites it.
>
> Find a way to make your assembler output a listing. Then you can see in
> the list file where the assembler assumes the code is ending up. With
I did that and all addresses seemed to be in order. Obviously they
aren't or the program would work. I'll try to send you the snippet of
the code in my next message.
> the assembler I use you add -l to the command line and it will generate
> a listfile. The product I use to edit and assemble most of my HC11 code
> is called MiniIDE and can be found at http://www.mgtek.com/miniide/
> It contains a editor with syntax highlighting and a "built-in" assembler
> for HC11 and HC12.
>
Wow... this is a nice program. Obviously it's much nicer than the
little ASM11 that I'm using. I'll have to migrate over to it along
with the JBug.
thanks
alex
Alex Wiecek
> stack available after loading the talker is very small. <10 bytes. So if
> your program uses a few JSR's you very fast get into trouble. I rewrote
> one of the existing talkers to put the stack in exteral RAM instead,
> which solved my problems. If there are no newer talkers available I
> could send you one that works.
>
> /Leif
Leif,
I started playing some more with JBUG program...
I've got a couple of questions, however:
- can I use this to modify the contents of my external RAM, which
happens to be sitting at E000-FFFF.
- I don't see a need for improved talker (ie. with greater stack
memory) due to the fact that once the program is uploaded into the RAM
(assuming that's possible) all I need to do is move MODA and MODB pins
to +5 and reset. This should force the HC11 to look for the reset
vector that happens to be on the external memory, and then execute the
program. At this point I have the entire 256 byte of on-chip RAM
available for temporary storage, stack, etc...
Comments?
thanks,
ALex
Leif Holmgren
> happens to be sitting at E000-FFFF.
Yes. But you will have to do the following:
- Assemble your code into a .S19-file
- Set JBUG11-config as follows:
Under Settings - General
Mark Alter HPRIO after reboot, write E5 in the box (byte to send)
Under Settings - Memory map
Add a new row under RAM "Extern=E000-FFFF"
- Reboot your board (You should see a progress bar in JBUG that
indicates that the bootloader is downloading)
- Select File -> Load S19 MCU, and mark your file.
The program should now upload to your system. I see now that there is an
option to upload binary files aswell, but I do not know how this works
as I have never used it. I assume you will be asked for an adress where
the file should be loaded.
> - I don't see a need for improved talker (ie. with greater stack
> memory) due to the fact that once the program is uploaded into the RAM
> (assuming that's possible) all I need to do is move MODA and MODB pins
> to +5 and reset.
If you write bug-free software from start this should be fine. If you
want to use singlestepping, breakpoints and other things this will not work.
Also note that there is an option in JBUG for automatically rebooting
the board. This works only if you have some additional pin connected
from the serial port to the reset line. If you alter the MOD-pins JBUG
might try to reset the board when it should no so in this case,
disconnect the serial port after downloading your code.
/Leif
Alex Wiecek
thank you very much for your help and patience. The board now works
flawlessly.
I am able to load and run software without the need for my Chipmaster
programmer, which actually has bitten the dust a couple of days ago.
The reset option is great too, however I have to find a different way
to reset the board remotely.... and I mean remotely, as the intention
here is to locate the circuit hundreds of feet away from the laptop
and have them communicate using a current loop link. Using this
technique, we can only make use of tx and rx pins (it's a 2 wire
link).
In any case, important thing is that it now works and I have no need
to plug/unplug the SRAM from the board in order to reprogram it.
Once again, thank you for your help Leif.
Alex
Leif Holmgren <nob...@nowhere.com> wrote in message news:<3FB7FD5C...@nowhere.com>...
Leif Holmgren
> Hi Leif...
>
> thank you very much for your help and patience. The board now works
> flawlessly.
> I am able to load and run software without the need for my Chipmaster
> programmer, which actually has bitten the dust a couple of days ago.
> The reset option is great too, however I have to find a different way
> to reset the board remotely.... and I mean remotely, as the intention
> here is to locate the circuit hundreds of feet away from the laptop
> and have them communicate using a current loop link. Using this
> technique, we can only make use of tx and rx pins (it's a 2 wire
> link).
With a LOT of hacking it might be possible to connect the MOD-pins to an
output and connecting XIRQ and RX together from the receive data. There
are versions of the talker where XIRQ and RX should be connected just
for the purpose of not having to have a reset signal connected.
However it would require a lot of carefully crafted code to ensure you
always end up en the right mode after a reset or XIRQ due to random data
received. I would *NOT* go into this type of coding other than just as
a mental excercise.
I believe I would use a shiftregister and a pair of digital comparators
to reset a flip-flop and the CPU when a certain bit-pattern is detected
on the RX line.
You could even consider sensing the load on the TX-line and reset if
it's too high.
A word of wisdom:
Just because something can be done (using software) does not mean it
should be done.
Good luck with your project.
/Leif