Using Flash ROM With PAULMON2

Downloading to Flash Memory

Flash ROM can not write as quickly as RAM. During a download to PAULMON2, the speed that the data is sent must be limited to a rate which the Flash ROM can accept. Many Flash ROM chips can accept data very quickly, so that the baud rate of the data transmission will provide enough delay between each write to the Flash ROM, even for fast baud rates.

With some chips, the speed for a download to Flash ROM should be limited by either selecting a slower baud rate, or by introducing delays between the characters as they are transmitted. Most terminal emulation programs support this type of delay when transmitting ASCII data and often times the default action is to insert delays. The exact delay required can be found with a bit of experimenting, though in many cases no delay at all is required. PAULMON2 verifies that every byte was written to memory properly, so not using enough delay will result in PAULMON2 displaying errors after the download is finished.

Creating Dedicated Applications

My placing the Startup Header on your program, PAULMON2 will run your program when the board is reset, before printing the welcome message. The program will run in the same environment as if it had been download and run normally. PAULMON2 will have configured the serial I/O and other special function registers, so that converting a normal program into a dedicated application is as easy as possible.

PAULMON2 is usually configured to use automatic baud rate detection when it reset from a cold boot (or the previously stored baud rate data is corrupted). A different type of header for hardware init is available, and is usually only used with the fix_baud code to set up the baud rate without requiring the automatic baud rate detection. This can be handy even without having a dedicated application installed as a startup program, because the automatic baud rate detection can detect the incorrect baud rate if it receives noise or undesired characters before Enter is pressed.

Erasing the Flash ROM

Standard Commands
  ?- This help list
  M- List programs
  R- Run program
  D- Download
  U- Upload
  N- New location
  J- Jump to memory location
  H- Hex dump external memory
  I- Hex dump internal memory
  E- Editing external ram
  C- Clear memory
  Z- Erase flash rom

PAULMON2 (beta8) Loc:3000 > Erase flash rom

Erase flash rom, Are you sure?

Flash rom erased

This trick works because the programming algorithm for the Flash ROM can turns any bits with a 1 into zeros. The only way to turn a 0 back into a 1 is to erase the entire chip.

Erase On Startup

To deal with this situation, PAULMON2 is usually configured to scan a pin at startup. If that pin is held low, the PAULMON2 will erase the Flash ROM chip before searching for any startup programs. The default configuration assigns this pin to P3.5 (pin #15 on a 40 pin DIP package).

In the case of a dedicated application, the code can be easily upgraded my inserting a jumper which shorts this pin to ground and resteting the board. PAULMON2 will startup with the menu and a new version of the code may created and downloaded to the Flash ROM once the desired changes are tested and working properly.

PAULMON2 can be configured not to test any pins, which removes the erase-on-startup feature. For applications which require all of the available I/O pins, it is a good idea to use P3.5 (or whichever pin is configured for the erase-on-startup check) as an output-only pin, with a pullup resistor. This way the application may use the pin as an output signal, and when the board is reset PAULMON2 may configure it as an input and test for the erase-on-startup condition. If PAULMON2 is configured not to test any pins, it can be difficult to recover from downloading a startup program which doesn't work properly and can't return to PAULMON2.

Accessing the Flash ROM From Programs

Usually bytes should be written by calling to the smart_wr routine. The value to be written is placed in Acc, and the location to write it is placed in DPTR. The Carry will be set if an error occurs while writing. This code will automatically determines if the memory is Flash ROM or RAM (by using the values specified when PAULMON2 was configured, not by making a sophisticaed test of the actual memory). The prgm is a similar function which assumes that the memory location is Flash ROM.

The erall function can be called to erase the entire Flash ROM chip. There is no prompting such as "are you sure?", it simply erases the entire chip. Like the other routines, the Carry will be set if an error occurs and the chip cannot be erased.

The programming process (smart_wr, prgm) turns bits which are ones into zeros. To turn zeros back into ones, the entire chip must be erased, which of course turns every memory location into FF (hex) or 255. Because programming can turn ones into zeros, any location may be overwritten with the value 00. One approach to storing data which must be changed without erasing the entire chip is to overwrite the old copy with zeros, and store the new copy. This complicated the reading process by requiring a search for the non-zero data.

Solutions like this are required to use Flash ROM for data storage if only a small piece of data must be changed without erasing the entire chip. Other non-volatile memory technologies, like EEPROM, don't offer the low-cost and high-density of Flash ROM, and often the time taken to write a byte is much longer an Flash ROM.