Uploading software to external RAM on HC11

Alex Wiecek wrote: >

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.

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:

Good Luck /Leif

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

(916) 780-7623

----------------------------------------------------------------------

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.

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?

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

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.

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

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.

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.

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.

Hello.

Still playing with HC11 MCUs, I'd like to give you extra informations that could help you (see inline text).

... 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).

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

(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.

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

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.

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

Done... :)

Yes, that would make it a very nice utility.

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

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

It contains a editor with syntax highlighting and a "built-in" assembler for HC11 and HC12.

/Leif

Leif, I agree with the fact that instructions such as BRA, BEQ, etc... 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.

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.

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

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

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.

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

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).

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

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