PJRC.COM Offline Archive, February 07, 2004
Visit this page on the live site

skip navigational linksPJRC
Shopping Cart Checkout Shipping Cost Download Website
Home MP3 Player 8051 Tools All Projects PJRC Store Site Map
You are here: 8051 Tools PAULMON Monitor Manual Using Flash ROM Search PJRC

PJRC Store
8051 Dev Board, $79
LCD 20x2 Display, $11
Serial Cable, $5
12 Volt Power, $8
More Components...
8051 Tools
Main Page
Software
PAULMON Monitor
Development Board
Code Library
89C2051 Programmer
Other Resources

Using Flash ROM With PAULMON2

PAULMON2 can support Flash ROM, but the functionality must be enabled when PAULMON2 is assembled. You can download a ready-to-use copy if the memory configuration you require is available. If your hardware requires a different configuration, you will need to create a customized copy of PAULMON2 for your hardware.

Downloading to Flash Memory

The PAULMON2 commands which write to memory (Download and the Memory Editor) will automatically program the Flash ROM. No special steps are required, other than assembling (.ORG) the code for a place in memory which is within the Flash ROM chip.

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

One of the advantages of Flash ROM is that programs may be almost downloaded as easily as RAM, but they will remain in the Flash ROM until it is erased. PAULMON2 provides a capability to identify programs in memory which should be run when the system starts up.

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

The 28F256 Flash ROM chip must be erased all-at-once. It is not possible to erase single bytes or portions of the chip. When Flash ROM support is enabled in PAULMON2, an additional command appears in the menu:
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
When this command is run, it will ask if you really want to erase the chip, and a single "Y" will confirm and begin the erase operation.
PAULMON2 (beta8) Loc:3000 > Erase flash rom

Erase flash rom, Are you sure?

Flash rom erased
In some cases, a program or external command with the 64 byte program header is download to Flash ROM, but it turns out that there is a bug and a new copy must be downloaded, but many others are already in the Flash ROM. One alternative if the program can be reassembled for a different location is to use the Memory Editor to write zeros over the first several bytes of the old copy. This will destroy the program header and PAULMON2 will not recognize the program exists. Then reassemble the program for a new location, which is in an unused portion of the Flash ROM (all FF's), and download the new version.

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

It is possible to download a startup program to PAULMON2 which does not terminate with a RET instruction. For dedicated applications this is intentional, and it can also happen unintentionally in the case of a nasty bug in the startup program.

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

The Flash ROM can be read in the same manner as an ordinary RAM chip, using MOVC (or MOVX if the hardware supports reading the Flash ROM as data memory). PAULMON2 contains built-in functions which allow programs to write individual bytes to the Flash ROM or to erase the entire chip.

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.


PAULMON2 Documentation, Paul Stoffregen
http://www.pjrc.com/tech/8051/pm2_docs/flash.html
Last updated: November 28, 2003
Status: This page is finished
Suggestions, comments, bug reports??? <paul@pjrc.com>