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


A Beginner's Experience Getting a BotBoard Microcontroller Running

by Steven D. Kaehler April 6, 1998



My name is Steve Kaehler. I am an electrical/electronic engineer with the Boeing Company. I specialize in the design, construction, installation, operation, and repair of instrumentation and control systems. I am writing this article to share my experiences as I work toward building a real, operating, autonomous robot. I hope that by sharing some of the lessons I have learned the hard way, readers can avoid some of the pitfalls I went through.

I have been an electronics hobbyist for about 30 years or so, having started before I was a teenager. I started working on a robot over two decades ago, and remember hearing about the Seattle Robotics Society (SRS) in the early eighties. I used to frequent United Products which I understand helped get the club going and provided a meeting place for a while. I worked on my machine through high school, installing a diode-matrix brain, programmed with simple reflex responses from bumpers. The robot lived in storage until last summer when I pulled it out of my parent's basement, completely dismantled it, and started over using salvaged bits and pieces.


I chose Marvin Green's BOTBoard (BB) after seeing it advertised on the SRS website. I attended my first SRS meeting in the fall of 1997 and saw robots built using it. When I found out how cheap it was, I was flabbergasted. I eagerly purchased a kit with high expectations of finally bringing my robot to life the way I had always hoped. I downloaded the free software tools from Motorola's website and assembled the kit. I also built the serial interface cable with sample chips obtained from Maxim. The kit and cable both went together quite smoothly and easily. The software however, didn't work when I first tried it.


A call for help to the SRS mail list yielded rapid and helpful answers. This list is an extraordinary resource for new as well as experienced robot builders. The expertise of many people here locally and far away is available simply by asking your questions. I highly recommend using it. As it turned out, there are at least two HC11 assemblers, AS11.EXE and ASMHC11.EXE floating around. One seasoned HC11 user recommended using AS11.EXE and avoiding the other. I don't know if one is necessarily better than the other, but he recommended that users stick with one since each has unique quirks that must be learned.

I downloaded the HC11 tools from Tom Dicken's website and at first couldn't get the program to successfully assembled a simple checkout program included with his software toolkit. There is a good AS11 Primer in Tom's kit. An appeal to the SRS mail list produced several helpful responses.

Randy Carter offered the following:

"The public domain AS11 is very stuck up. It only allows the extension .ASC on the source code files. There are a few other quirks in instruction formatting that if the spacing of the operands is not correct you will get an error."

Randy continues:

"This appears to be what I ran into with ASMHC11.EXE. The gist seems to be to pick an assembler and work with it consistently since there are quirks in both. Some prefer the one over the other, however switching back and forth will probably prove frustrating, especially for a newcomer so I chose AS11."


Tom's website at (http://home1.gte.net/tdickens/68hc11/my_tools.html), has a comprehensive beginner's guide and primer for PCBUG11. His experience teaching 68HC11 programming has exposed him to the wide variety of questions people encounter when first introduced to this chip. He has a nice zipfile set up for downloading that includes his whole toolkit. I strongly recommend this to anyone who hasn't used a BB before.

I found it helpful to create a batch file that invokes the assembler, adds the .ASM extension, and requests a list file with a symbol cross-reference table. This saves command line typing and always generates all the useful stuff one needs to review and debug code.

I use a multi-buffer text editor and so added commands to my batch file that assembles my code, then invokes the editor and places the source, list, .S19, and 6811REGS files in separate buffers where they can be viewed for accuracy, completeness, or reference.


Another issue of confusion that surfaced during this exercise was a suggestion by Kevin Ross in the annotated Marvin Green BB instructions to make a jumper modification to allow easy selection of "Special Bootstrap Mode" or "Single Chip Mode". The mod was highly recommended, yet lacked explanation as to what it gained. I wondered in simple terms what these modes were and why this modification was so highly recommended. Again the SRS mail list provided access to helpful answers to my questions.

Karl Lunt offered the following:

Single Bootstrap Mode lets you power up the chip and talk to it directly with PCBUG11, a freeware development tool probably included with your software distribution. Single Chip Mode is the normal mode for executing a program after it has been burned into the 'hc11's memory. Thus, you really need to use both modes. Single Bootstrap Mode lets you INSTALL your program, and Single Chip Mode lets you RUN your program. Bottom line: Make the mod."

Karl also added:

"Try the SRS Encoder, (http://www.seattlerobotics.org/encoder/index.htm), or my web site (http://www.seanet.com/~karllunt) for articles on how to do the basic startup activities on a 68hc11. As to why they work or what they accomplish, you need to get with someone and talk things over, or spend some serious quiet time with the Motorola manuals. Or get a copy of "Mobile Robots," by Joe Jones and Anita Flynn (published by A.K. Peters, Ltd.). This is an excellent book on robots in general and the 68hc11 in particular. You can buy a copy from Mondotronics (http://www.robotstore.com)."

Anyway, the software was now working so I tried actually downloading to the BB. Using Tom Dicken's PCBUG11 Primer as a guide, I was able to tweak the batch and macro files to match my particular PC and BB configurations, but got the dreaded "com port errors" he mentioned, suggesting a hardware problem. Tom suggested checking all interface cable wiring, PC and BB configurations, and software configurations. I did this and found no obvious problems. After bringing my PC, cable, and BB to a meeting, the general conclusion was that either my PC had a com port problem or my interface cable did. Upon closer examination of the various doc files related to the cable, I discovered a wiring error in the interface cable that I hadn't noticed before. Pins 5, 6, and 20 on the RS-232 connector should be tied together. Once I corrected this, the PC & BB started talking. The best advice I gleaned from this exercise is to have someone else check your wiring. I could no longer see the problem myself.

The next step was to download a simple program that would increment an I/O port. I did this and viewed the results with an o-scope to verify that everything was working normally. Again, for serious users, an o-scope is an essential piece of test gear. If you don't have one and can't afford one, make friends with someone who has one you can use from time to time.

Tom's package conveniently provided several versions of simple Port B incrementing program. When I first downloaded the program, I didn't quite understand the programming sequence required. Before allowing the software to attempt to connect to the BB, you must reset it. If this isn't done, the microcontroller won't respond to PCBUG when it tries to connect. The second problem was getting the it to start program execution at F800 in memory where my program was located. Once connected, the program counter would show up at 0000. When I executed a 'G F800' command in PCBUG, the program ran fine. The problem now seems to be getting the automatic startup to happen properly. Full remote control from PCBUG works just fine however.

Over the night I had an inspiration to try following Tom's programming and operating procedure without any other modifications. That is, leave the jumper in place that permits selection between Single Bootstrap Mode or Single Chip Mode so that Single Bootstrap Mode is selected all the time. Tom says just power down the board, disconnect the programming cable, install a jumper across the "Transmit" and "Receive" pins of the programming connector, and turn on the power. The board came up running my program just as it should. This of course returns me to question this mysterious, highly recommended mod and its exact purpose. This was in part the reason I couldn't get this thing to work properly. Once again, I queried the SRS mail list looking for answers.

Bill Harrison, president of Sine Robotics, responded with the following comments:

"I think the "single chip" mode keeps users of a chip from modifying the program. This way you can program the chip in Single Bootstrap Mode, and hand it off to a user, that uses it in Single chip, without worrying. Since we use the chip ourselves, we don't need the special safeguard, so we can program and use it in the Single Bootstrap Mode. There is a difference in the way the chip operates and uses memory, but I don't think it effects us enough to not use the Single Bootstrap Mode."

Randy Sargent, president of Newton Labs, responded with the following detailed explanation:

"The HC11 operating modes are fairly interesting. If memory serves me correctly, here's what the chip does in each of the four modes:

"Normal expanded mode": Use external bus. Upon reset, fetch a 16-bit address from $FFFE and jump to that address.

"Special test mode": Use external bus. Upon reset, fetch a 16-bit address from $BFFE and jump to that address.

"Single chip mode": Do not use external bus. Upon reset, fetch a 16-bit address from $FFFE and jump to that address. Internal to the 6811E1, the ROM is the only thing that can map to that address. This would typically run BUFFALO or whatever has been burned into ROM.

"Special Bootstrap Mode": Map in the special "bootstrap" Single Bootstrap Mode ROM in the $BFxx range. Upon reset, fetch a 16-bit address from $BFFE and jump to that address. This causes the 6811's bootstrap downloader to run.

But here's the trick. If you want to program the EEPROM of the 6811E1, you're in trouble. The EEPROM covers neither the $BFFE nor $FFFE reset vectors. So Motorola built in a hack to their downloader in "special bootstrap mode" Single Bootstrap Mode. If the bootstrap routine detects that TX and RX are looped back, it will jump to the beginning of EEPROM.

Another piece of trivia: the MIT LEGO robot controller and Handyboard use "special test mode" because it allows much more flexibility in the operation of the 6811. In particular, it allows you (if you so desire) to switch between using the external bus and not using the external bus. We did this to operate a standard LCD display on the 6811's bus. The LCD was spec'd to need a slower bus cycle than a 6811 at 2Mhz E clock can give, so we popped the chip into "no external bus" mode, and frobbed the I/O ports directly to simulate a slow bus cycle. In retrospect it probably would have been simpler to add the single latch chip the circuit would have required."

These explanations offer considerable insight into these modes of operation. The main thing I learned was that Single Bootstrap Mode works just fine for running the microcontroller as a self-contained system with no external memory or I/O.


Another quirk I noticed with my board was that it would sometimes take off running upon powerup while other times it needed to be manually reset. The problem turned out to be with my power supply. I was using the power switch on the supply to turn the controller on and off. The problem is that it takes too long for the supply to come up to operating voltage, probably exceeding the power-on-reset time. By leaving the supply on and simply interrupting power to the board, reliable auto-startup was finally achieved.


Programming and Startup Sequence:

1. BB Power off.
2. Connect programming cable from PC COM port to BB programming port.
3. BB Power on.
4. Execute batch file to start PCBUG and download program. Exit when done.
5. BB Power off.
6. Disconnect programming cable and place TX-RX jumper on BB programming port.
7. BB Power on.


This list is an invaluable resource for someone trying to troubleshoot something or figure out how to do something, or simply to share something learned with the rest of the SRS. One can subscribe to the SRS mail list by accessing the "Contact Us" link on its homepage and following the instructions.


The following are just a few really good links to get started. They have a lot of good information and point to many other interesting places.

Seattle Robotics Society http://www.seattlerobotics.org/
Tom Dickens’ Website http://home1.gte.net/tdickens/68hc11/68hc11.html
Karl Lunt’s Website http://www.seanet.com/~karllunt/
Motorola Microcontrollers http://www.mcu.motsps.com/
P.A.R.T.S. Website http://www.rdrop.com/users/marvin/
Kevin Ross’s Website http://www.nwlink.com/~kevinro/robotics.htm
Mondotronics Website http://www.robotstore.com



I can’t begin to describe how helpful and informative the monthly meetings of the SRS are. They provide a great source of inspiration for the any robot builder. It can be done without spending thousands of dollars and hours! Come to the meetings on the third Saturday of each month at Renton Technical College, Room J314. This room is on the third floor of building "J" in the SE corner. Ask your questions, talk to people about what you are trying to do. Enter the contests. Be part of the action.


This experience has proven to me once again that nothing is as simple or easy as I expect. When one mixes science, mechanics, electronics, and programming there is no telling what's ahead. I have great respect the people that make up the Seattle Robotics Society. This group includes an extraordinary pool talent, expertise, and experience. This expertise is offered freely to anyone who asks. For someone looking to get their feet wet in robotics, I can't think of a better place to do it. Bring your dream to life.