ENEE 445, FALL 1999 PROGRAMMING THE 6812 FLASH EPROM This handout describes the programming of the 6812 Flash EPROM using POD Mode. Note that because this capability exists, it does not mean you want to use it. Look at the trade-off analysis at the end of this handout. You need TWO 6812's to do this: - The "POD" board will always run D-BUG12. Power and serial ports are connected to THIS BOARD ONLY. (The "labs's" 6812's that you may borrow must ALWAYS be used in POD mode. DO NOT ERASE DBUG12 from the lab's 6812s.) Lab partners can choose to make one of their 6812's the POD, and the other the target. - The "Target" board is your own 6812, which you will erase D-BUG12 and load your own program into Flash EPROM. This will allow the code size of your program to be up to 32KBytes and to enable interrupts. On the target board, you will ONLY connect the VPP (12 Volt), but DO NOT CONNECT THIS POWER YET. Your user console will plug into this target board. Before power is turned on, review the jumpers on both the POD and Target boards. For the POD board: - Jumper W3 should be set to 0. - Jumper W4 should be set to 1. <-- this is only one that changes - Jumper W7 should be set to Vdd (5V). This is different from the default configuration that you have been using until now. If you go back to default configuration, then reset the jumpers as follows: - Jumper W3 should be set to 0. - Jumper W4 should be set to 0. - Jumper W7 should be set to Vdd (5V). For the Target Board: - Jumper W3 should be set to 0. - Jumper W4 should be set to 0. - Jumper W7 should be set to Vpp (12V). <-- this is only one that changes - Connect the BDM cable that was in your 6812 kit (it's an 8-inch grey ribbon cable with 6 pins). For the POD board: - connect to BDM OUT (W12). *** Make sure it is properly oriented, such that pin 1 on board and cable are lined up. For the Target board - connect to BDM IN (W9) *** Make sure it is properly oriented, such that pin 1 on board and cable are lined up. FOR THIS NEXT STEP, the 12-volt on target board is still NOT connected - Turn on power supply, and connect to 6812 using HyperTerminal as in Lab 1. If you get the error "Can't communicate with the target processor", then hit ENTER and/or hit RESET on the TARGET board. The normal (default mode) prompt is ">". In POD mode, the prompt will be either "S>" or "R>", where S means target is STOPPED, and R means target is RUNNING. If it doesn't show S> or R>, then re-check all your jumper and cable settings. Once this works, turn the power OFF for the next step. - Create wires for the 12-volt that use pin connectors on one of the ends (these connectors will be supplied to you). The other end is to be soldered to the GND/12 volts of your power supply. *** Do not use alligator clips for the 12-volt wire, as even an instantaneous short on these lines will blow up the flash eprom, making the processor useless. The pin connectors will ensure that connections aren't shorted before turning power on. - Before connecting wires to target board, DOUBLE CHECK the wires that are soldered to your board using the multimeter, to ensure that you are properly getting 12 volts with the proper polarity. IF THIS IS WRONG, YOU ***WILL*** BLOW UP YOUR BOARD. - ALWAYS Turn Off power when connecting 12-volt wires to the target board. Connect the wires, (12V goes to Vpp), just beside the 5-volt connector. DO NOT CONNECT 5V to TARGET. - TRIPLE check your connections, then turn on Power if everything is okay. To verify that you have the proper 12V programming voltage, do the following. - Go into Hyperterm, and make sure you have S> prompt. - If you have the R> prompt, type "STOP" then ENTER, to get the S> prompt. - Type "fload" at prompt. - If you get message "Flash Programming Voltage Not Present" then TURN POWER OFF, and verify EVERYTHING. - If the terminal just goes into a wait mode (i.e. nothing is displayed on screen), then hit the reset button on the POD board. You should get your prompt back. This means the voltage is indeed present, and you are all set to load your program into the FLASH EPROM. - Modify the PRM file such that MY_ROM goes from 0x8000 to 0xFFBF (If you use interrupts somewhere, then you'd need to setup the Vector Addresses between 0xFFC0 to 0xFFFF). - You can use the RAM for everything else, and re-allocate what parts of memory go where. - Go to HIWARE Linker, and modify your options to make sure that it generates a .SX file. Go into "SmartLinker->Option->Output", check the top box, which is "Generate S-Record File". Then, Relink your code with the new PRM file. This will generate a file called filename.SX in addition to the .abs file. For your education, it is worthwhile to look at the S-record file, as it is a Motorola standard and something you may see many times in the future. But it is not necessary to look at the file. It is an ASCII file, so use your favorite editor to look at it. - Go back to your Hyperterm window, and type the following: **IMPORTANT** Make sure Hyperterm is setup as follows: Go to "File->Properties->Settings", click on ASCII Setup. Make sure that the "Line Delay" is AT LEAST 10 msec. If you have the R> prompt, type STOP. S> FBULK The FBULK command erases your flash EPROM. Once you do this, you will no longer have DBUG12 on your 6812. If you want DBUG12 on it, you will need to reload it. The .SX file for DBUG12 is on a floppy disk in your 6812 kit. Next, type S> FLOAD The command will appear to lock up Hyperterm ... but rather it is just waiting for you to send something. Go to the "Transfer" menu of Hyperterm, and select "Send Text File", then select the filename.SX file in the dialog box, and say OPEN. You should see a bunch of asterisks. Each asterisk represents one line in your .SX file. The longer your program, the more asterisks you'll see. If this hangs in the middle, then re-check the Line Delay above. If you get lots of invalid commands, check to make sure you had typed "fload" first. - When you get the prompt back, the Flash EPROM is loaded. You can verify the code by looking at the memory using a command like "MD 8000" or "ASM 8000" (i.e. using the hyperterm instructions that we used during lab 1.) - You can VERIFY that your Flash EPROM was loaded correctly. Do it just like the FLOAD above, except you type "VERF" at the prompt. If you get the message "S-Record Data did not match memory contents", then something was wrong. If you get one or more asterisks, then the program is fine. - Now, you can go back to HIWAVE. You must close hyperterm, or at least "disconnect", so that the port is not busy when HIWAVE tries to use it. - Start up HIWAVE in the normal way. The middle status window (at bottom of window) should now say "POD" mode instead of BDM mode. - The target is still ASCIIMON. You need to load the "filename.abs" in Hiwave. You can now run and stop your program. But you won't be able to use the breakpoints or several other features. NOTE: This is NOT the only way to program the Flash EPROM. You can also program it using Bootloader mode. If you do so, you do NOT need TWO boards, but you also will NOT be able to use HIWAVE as a debugging tool; ALL debugging would have to be done using the logic analyzer. When in Bootloader mode, the bootloader part of the FLASH EPROM is protected. When using POD mode, the bootloader *is* erased (contrary to what the documentation says), and you would need to reload DBUG-12 to reload this part of code. In this case, the memory map on Page 3-55 is valid. TRADEOFF ANALYSIS ON DESIGN AND DEBUG TIME I know you may be excited to use the 32 KBytes of Flash EPROM as well as interrupts in your program. However, there is a MAJOR tradeoff. Programming the Flash is much more complex than loading data into the RAM and byte-erasable EEPROM. Furthermore, your debugging capabilities are greatly reduced when code is in the Flash EPROM, as you cannot put in breakpoints. If you can keep your program within just RAM, you'll have the best debugging capabilities. If you run out of RAM, and use just the Byte-erasable EPROM, then that is your next step. Downloading a program via HIWAVE and stepping through a program will be much slower, but it can be done. So either you spend more time optimizing the memory of your code to fit in just RAM, or both RAM and EEPROM; or spending less time optimizing your code, but instead more time in downloading and debugging it. You can't have it both ways ... if you did have it both ways, you would not be programming an embedded system! For the project, it is your choice on how you want to do this.