Encoder Front Page
SRS Home | Front Page | Monthly Issue | Index
Google
Search WWW Search seattlerobotics.org

 

First Steps: Booting up the 68HC912B32 for the first time

Doug Leppard (DLeppard@CCCI.Org )
Benjamin Leppard (Benjamin@Leppard.Com)

Author’s note:

This is the third  in a series of articles outlining the steps we have taken to build our robot. Both Benjamin and I are newbies
at this and thus this article will be written for newbies. These articles are focused on a robot that will compete in the Fire
Fighting contest, be able to roam around the house and that will be a fun learning tool. The 68HC912B32 is our processor, so
articles will be on interfacing to the B32 to various mechanical devices and sensors using SBasic as our programming language.

Previous articles:

"Setting the Stage for Building a Robot," we set goals for the robot and did research. From the goals and
research we will make fundamental decisions on what our robot will be like.

"Choosing the CPU, Language and Basic Shape," from our goals we choose what microprocessor, language and what the fundamental shape of the robot.

"Motorola’s S-Record" looking at the S-Record format the Motorola uses to load data and programs.

Now we explore booting the CPU up for the first time.

This is easy!

I remember so well the first time I booted up my B32. I was concerned, did I still have what it takes, could I conquer the new tecnology, would any of this work? I hooked up the power to the B32, connected the serial cable to my notebook computer, turned on the power and immediately the LED came on the B32 and the notebook came alive with the B32 talking from its flash memory. The B32 was alive and working! Piece of cake!

I played with the debugger program, typing "Help" and ran the other functions. It was like a dream. It was working. I remember thinking "This is easy!"

 

Oh no it doesn’t load!

Next I got out the Nuts and Volts article by Karl Lunt (March 1997 page 71) to do a test program. It was a simple program, print a line and turn on a LED. Nothing could be simpler. But now you are entering the robotic zone where strange things happen. It wouldn’t load right, I couldn’t run a program, in other words, nothing was working and my greatest fears were realized.

I finally overcame these problems, but not until understood a few basic principles that I have outlined in this article.

 

Memories

To understanding the B32 you must understand its memory locations. Karl Lunt had a memory chart I kept by my side at all times. In the next chart is my version of it with other necessary  information.  It is in a word document.  (robot B32 memory chart.doc)

The B32 has three kinds of memory. 1K of RAM which can be read and written at anytime. This is usually reserved for dynamic data (variables etc). Next is 768 bytes of EEPROM which is Electrically Eraseble Programable Read Only Memory, this is for user programs. Finally there is the 32K of Flash memory which is used for user programs and bootloader. Both the EEPROM and Flash can not be altered by the B32 or by turning off power to the B32. It can only be changed by downloading it from your PC.

Knowing the above will effect how you load your program, where to put your variables and set any vectors.

 

Vectors

Vectors are what did me in more than anything. Vectors are locations in the memory that programs use to tell where to jump to memory locations upon certain conditions like Reset or a interrupt. They are simple once you know what is needed, but a killer until then. I could not get my program to run in flash. I finally got it to load but not run. I knew the problem was the B32 didn’t know where to jump once power was turned on.

Running with the bootloader in flash forced Motorola to setup secondary vector table. So I discovered that I had to load into this vector table where my program was located. It needed to be in the seconday Reset vector ($F7FE). In SBasic it would look something like this:

'this is so that when the command to jump to flash it will jump to start of program

org $F7FE ‘secondary vector address for Reset
asm
dw $8000 'set reset point to start of program
endasm

org code ' start compiling at the same place as it left off
‘rest of code

That solved my problems and now I can run my program from flash.

 

SBasic

The program is in Karl Lunt’s SBasic code which I have decided to use, not wanting to come to speed in C. The following tells how to work with SBasic:

 

Step 1 - Use your text editor write your basic program. Speed12.bas is the example here.
Step 2 - SBasic compiles the basic program. It converts it into assembler code. Note this is assember for the 68HC12 but has not been optimized for the HC12 and was originally done for the 68HC11.
Step 3 - The assembler code is now compiled (speed12.asm) and two files are created Speed12.s19 and Speed12.lst. the .lst file is a listing of the assember results and is useful for debugging and seeing any compiler errors. The S19 file is what you are going to download into the 68HC12.
Step 4 - Use your communication package and your onboard loader, load the S19 record into the B32. (note if the load goes to flash memory, then the Vfp must be present and flash must be erased first).
Step 5 - Switch the B32 to run the program and off you go.

It sounds complicated and it is. But once you get this working, it is not too bad. Steps 2 and 3 can be done all at once with an BAT file see Speed12.Bat for this example. The problem when you do this for the first time there are many things that have to happen correctly at the same time. If eveything is new to you (as it was for me) it can be a confusing and daunting task.

Thank goodness that Karl Lunt had done all this first. The problem was he was working on an earlier version of the B32 and the memory locations had changed (as he had warned in the article that it could). The manual from Techart was no help since I had received the very first batch of B32s and as everyone knows the very first manuals are not worth much. So I was on my own with my brilliant son to figure this out (being in Orlando is like being in the desert for robotic knowledge, any Orlando robotic enthusasts out there? Email me).

 

Step by Step in detail, bring it up

Now let’s go into detail how the loading is done.

 

Step 1 - Using your text editor you write your basic program.

I have already done that for you for Speed12.bas. Any text editor is fine as long as it doesn’t put in special codes. If you use Word and saved it as a DOC file it would not work.

 

Step 2 and 3 - This would all be done using a BAT file. See Speed12.Bat for example and suggestions. This will compile it into assembler then into the S19 record. The BAT file would look like this:

sbasic speed12.bas /s0bff /c8000 /v0800 /m6812 /i > speed12.asm
as12 speed12.asm >SPEED12.LST
sbasic - runs the sbasic compiler.
/s0bff - where to put the stack in memory. Notice it is put at the far end of the RAM area.
/c8000 - where to compile the program for. $8000 is for flash. $0d00 is for EEPROM.
/v0800 - where to put the Variables in memory. They go at the start of the RAM area.
/m6800 - tells sbasic to compile for the 68HC12. If left off it will assume the 68HC11.
/i - tells the complilier to inhibit automatically putting in the vector adresses, like for interrupts. This is because of the secondary interrupt table that has to be there because of the bootloader. This goes away when you use a BDM (Background Debug Mode).
>speed12.asm - tells the compilier to load the resutls into this file (speed12.asm). Can be named anything but the same name is the best.
as12 - the assembler program

To use the above all you need to do is change the name of the program (speed12) to your program and change the load address to eirther location you would like to use.

 

Step 4 - Using your communication package and your onboard loader, you load the S19 record into the B32.

The important thing with loading the S19 record is that your communication program must wait for an asterisk sent from the B32 bootloader before sending the next line. So you must configure your communication package to do that. This is so the B32 has time to load the data in memory and check to see if it is correct. In the document 68EVB912B32UM/D in section "B", it gives suggested communications programs and how to set them up for this operation. The B32 bootloader is set at 9600 baud, 8 data bits, 1 stop bit and parity none.

 

Loading your program into EEPROM do the following:

  1. You must have compiled it with the proper settings. For the B32 EEPROM you would use /c0d00 as the complier option to load it into the EEPROM memory. Else it will not load.
  2. Start your communication package. We are using Qmodem. Hook up the serial cable to the B32 and appropriate port on your PC.
  3. Set your switches on your B32 to bootloader. There should be jumper switches on your B32 to do this. The picture below shows how I put two toggle switches wired into the jumper locations. This is one of the best things I have done so far with my robot. I am constantly switching these switches and the jumpers that came with the board where to hard to switch a lot and quickly. To jump to bootload on start the switches should both be 1 (on).
  4. Turn on the B32. You should see:

(E)rase, (P)rogram or (L)oadEE:

  1. Press "L" on your computer. Then set your communicaion program to download the S19 record. You should see row of asterisks *. At the end it will say one of two things, "Programmed" and you are happy or "Not Programmed" and you have to go back to work. If you get only one * then most likely the S19 record is set to run at a different memory location. If you get multiple * but it doesn’t finish loading, then there is a problem with the last line of the S19 it tried to load. Again the most likely problem is that it is trying to load outside of its memory area. Make sure your program isn’t trying to load into flash a section or that your program is too big to fit. An unlikely problem could be the EEPROM is bad in that location. See my article "Motorola’s S-Record" on reading and working with the S19 record.
  2. Once it loads correctly switch your switches to jump to EEPROM to run the program. This would be an 1 and a 0. Turn off and turn back on the B32 (or push the reset button) and it should be running your program in the EEPROM.

 

For loading it into flash memory do the folowing:

  1. You must have compiled it with the proper settings. For the B32 flash you would use /c8000 as the compiler option to load it into the flash memory. You must have compiled in your program the secondary reset vector. See above for the code.
  2. Start your communication package. We are using Qmodem. Hook up the serial cable to the B32 and appropriate port on your PC.
  3. Set your switches on your B32 to bootloader. There should be jumper switches on your B32 to do this. See section above about putting in switches.
  4. Turn on the B32. You should see:

(E)rase, (P)rogram or (L)oadEE:

  1. With the program going to flash memory, it must have the 12V Vfp turned on. With the Vfp on press "E" and it will erase the flash but not the bootloader. You will only get three responses; Erased and so you are ready to load, "Vfp Not Present" that means that the voltage is not making it to your B32 to erase it, or Not Erased which I think could only mean a bad memory location (hasn’t happened to me).
  2. Now you are ready to load the program. Press "P" on your computer. Set your communication program to download the S19 record. You should see row of asterisks *. At the end it will say one of two things "Programmed" and your happy or "Not Programmed" and you have to go back to work. If you get only one * then most likely the S19 record is set to run at a different memory location or you have not erased your memory first. If you get multiple * then there is a problem with the line of the S19. Again the most likely problem is that it is trying to load outside of its memory area. Make sure your program isn’t trying to load into EEPROM a section or that your program is too big to fit. An unlikely problem could be the flash is bad in that location. You could also be tryin to load parts of the program into the protected part of the flash memory. Count the number of * that came through and it will point to the problem line (plus 1, the first record S0 will always load) in the S19 record. See section on how to read the S19 record.
  3. Once it loads correctly switch your switches to jump to flash to run the program. This would be an 0 and a 0. Turn off and turn back on the B32 (or hit reset) and it should be running your program in the flash. If it goes to never never land, you may not of set your secondary vector location correctly. See above for explanation..

I do hope this helps. It took me quite awhile to work through these things.

 

Next Steps

Next article I want to explore using a BDM (Background Debug Mode). I have not hooked it up yet and I am looking forward to it.

Please drop me an email and let me know if these articles have been helpful. (DLeppard@CCCI.Org)