Doug Leppard (DLeppard@CCCI.Org )
Benjamin Leppard (Benjamin@Leppard.Com)
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.
"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.
"Motorolas 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.
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!"
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 wouldnt load right, I couldnt 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.
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 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 didnt 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
dw $8000 'set reset point to start of program
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.
The program is in Karl Lunts 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).
Now lets 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 doesnt 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.
(E)rase, (P)rogram or (L)oadEE:
(E)rase, (P)rogram or (L)oadEE:
I do hope this helps. It took me quite awhile to work through these things.
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)