Why does my program run in RAM, but not in EPROM?

Burning a program into EPROM which worked in RAM is a common source of errors. It is not a particularly difficult process, but it does involve multiple steps and several unknowns. The sequence is rather simple:

1. When program development is complete, compile the program using Ctrl-F3, the "Compile to File" option. The "Options/Compiler/File" type for the "Compile to File" option should be set to "Code with BIOS (*.BIN)".

2. If the compilation produces errors, attempt to correct the errors and retry compilation to file.

3. After this is accomplished, a .BIN file will have been generated containing the binary image of your compiled program. If the "Create .HEX File Also" box (OPTIONS | COMPILER) is checked, an extended Intel HEX file is generated.

4. If the compilation is successful, exit Dynamic C. You now have the data necessary to program an EPROM. Please note that Z-World controllers cannot program EPROMs. Programming must be done by third party devices.

5. Use an EPROM which is large enough for the program and fast enough for your controller. To determine the size of your program, look at the size of the .BIN file (don't use the .HEX file which is artificially large). Use the .BIN or .HEX file to program the selected EPROM.

6. Your newly programmed EPROM should replace the normal Dynamic C EPROM. Normally, configuration jumpers should not require any changes. However, based on the size of the new EPROM, it may be necessary to move one or two jumpers. See the hardware manual for your controller for more details.

My program executes correctly prior to burning an EPROM, but it does not run properly from the EPROM. Why?

1. You should be using an EPROM with a part number of some variation of 27C256, 27C512, 27C010, 27C020, or 27C040, which are different sizes of EPROM.

2. The EPROM may not be large enough for the program. To determine the program size, look at the size of the .BIN file. Don't use the size of the .HEX file, because it contains overhead and it's over twice as large as the actual program! EPROMs are measure in KiloBits, so a 27C256 is 32KByte, 27C512 is 64KByte, etc. Make sure the KByte size of the EPROM is at least as large as the size of the .BIN file.

3. The EPROM may not be fast enough. Controllers with 9Mhz clocks require 100 nSec or faster memory. All controllers faster than 9Mhz should use 70nSec memory.

4. The board may not be jumpered correctly for the selected EPROM. Most Z-World controllers that are not FLASH based, are shipped with 27C256s installed. If this is the size EPROM the selected, no jumpers are needed to be moved. If a 27C512 or larger is selected, one or two address jumpers will need to be changed. Consult Z-World documentation and/or schematics for the particulars for any given board. The SmartCore Z1 is configured to accept a 27C010, 27C020 or 27C040 without jumper changing. Smaller EPROMS (the 28-pin 27C256 and 27C512) will not work without moving J3, a surface-mounted zero-ohm resistor.

5. It is possible the EPROM was not burned correctly. Since EPROM programmers tend to verify in the manner they have programmed, verification is of little help if the programmer is setup incorrectly. The best way to verify the correctness of the programming procedure is to burn a new Dynamic C EPROM. Once this EPROM is burned, place the EPROM in a target board and try to have Dynamic C respond as normal. Note that it is not sufficient to copy the EPROM by reading the original EPROM into a buffer. The point of this exercise is to test whether your programmer can convert a file to an EPROM, not whether it can duplicate EPROMs. Most EPROM programmer problems occur in reading files.

6. Your program may contain STDIO (printf, putchar, etc.) function calls. These functions calls are intended for debugging purposes only. They communicate with the STDIO window in Dynamic C. Since the debugging kernel is not running when a program is in EPROM, executing one these commands will cause the program execution to stop.

7. Are variables being modified which are initialized when declared? Consider the declaration "int x = 6;". This defines an integer x. Since x is assigned a value when it is declared, the variable x is placed in code space, which at development time is RAM. During development, x may be freely modified. When the program is burned into EPROM, however, the value of x is also placed in EPROM and now it's value is fixed. If the proper execution of your program relies on modifying such variables, it will fail in EPROM.

Why does my program run faster in EPROM?

1. Busy delay loops tuned empirically by hand will run faster in ROM. The proportion of execution overhead devoted to debugging is inversely proportional to code complexity. Since busy loops are trivial code, debugging overhead is high and its removal can be dramatic. Loops in ROM can execute 2 to 3 times faster! The solution is to make such routines stand-alone functions and declare them as nodebug. This will remove the overhead at development time and should make the delay uniform.

2. If timing sensitive code (such as the initialization of an LCD) is written incorrectly, debugging overhead may introduce enough delay to allow the procedure to work. When this overhead is removed, the routine then fails. In this situation, the incorrect code must be fixed.

My LCD/KIO works at development time, but not in EPROM. Why?

Why do two binary files compiled at different times for the same program have different check sums?

0x2240:one bytes
0x2288-0x228f: time information, 8 bytes
0x2305-0x2306: checksum two bytes
end of root code: 8 bytes, time information

How can I keep the value of my variables across a power recycle?

How do variables initially get their values?

1. Explicit Initialization

In this case, the user must take some action (install a jumper, press a button, etc.) that will be recognized by the program as a signal to set all globals to their default values. This system has the benefit of being the only 100% fool-proof way to know whether or not a system needs initialization. The downside is an operator may forget to explicitly initialize the unit.

2. "Magic Number"

A magic number is a pattern stored in memory which indicates whether or not the system has been initialized. In C, a magic number is normally implemented as:

long lMagic
void main ()
{		if (lMagic != 0x55AA5AA5L) {
			// Do Initializations
			lMagic = 0x55AA5AA5;
		}
		// Program Goes on from Here
}

Note that the magic number (0x55AA5AA5L) is chosen because it is unlikely to occur randomly in RAM. Not accounting for the physical nature of randomized RAM, this method will fail only once in 4.3 billion units.

3. Bounds Checking

Bounds checking is nothing more than an extension of the magic number principle. Mission critical values (such as set points and safety ranges) are bounds checked to see whether or not their values are reasonable, both with respect to other system parameters and to absolute norms. If one (or any one of a collection) of such parameters is out of bounds, the parameter (or entire group of parameters) is reset.