
PSD813FH - 80C31 Design Example …Application Note
052
WSi Inc. Fremont CA 800-832-6974 www.wsipsd.com
8
Now let's look at partitioning code in the FLASH memory pages. Ultimately, the MCU will be
executing from FLASH memory since the OTP boot ROM is only used for boot-up and ISP in
this design. Let's assume that we will have 128 Kbytes of program space in FLASH memory as
shown in Figure 5. The 128 Kbytes of code will reside in four areas: 32 Kbytes in the common
area (FS0, FS1 accessible from any page), 32 Kbytes on page zero (FS2, FS3), 32 Kbytes on
page one (FS4,FS5), and 32 Kbytes on page two (FS6,FS7).
Keep in mind that if the 8031 never leaves page zero while executing, it can access 64 Kbytes of
FLASH memory as well as all SRAM and I/O. However, if the 8031 execution jumps to FLASH
memory on pages one or two from a call on the upper half of page zero, care must be taken to
leave a path to return to page zero again. However, if the call to page one or two was from a
routine in the lower half of page zero (common area), there is no problem returning from the call.
When placing code in FLASH memory on the upper half of pages zero, one, or two, the software
designer must break tasks into logical groups. These groups should not need access to code on
other pages frequently (most software can be split in this manner and is a result of a good
modular design). Since system SRAM is available on any page, firmware routines that reside on
different pages may pass data using global variables or the stack. The designer can create page
switching algorithms to jump between the tasks which are on different pages. There are many
ways to implement a method of paging. One method involves the use of a table of addresses
and page numbers of all program tasks, which may be called from page to page. This table and
these algorithms must reside in FLASH memory that resides in the common area. This provides
a very clean paging solution, which may be implemented using high level compilers (the
compilers from Keil support this directly). The only penalty when using this method is the
overhead experienced when switching from page to page.
When this MCM design is converted to a monolithic PSD design, a similar memory map
structure can be maintained. One may use a PSD813F1 device and take advantage the
EEPROM instead of the OTP PROM that exists on this MCM. The 32 Kbytes of EEPROM may
be split into 16 Kbytes of boot memory and 16 Kbytes of data memory (used for product
configuration, calibration, etc.). There are many possibilities.
In addition to ISP of the main FLASH memory, the monolithic PSD devices will support MCU
ISP of the boot memory as well. The memory management techniques that will be used for ISP
of boot memory fit very well into the memory map scheme of this MCM design. ISP of boot
memory will be covered in separate applications notes for the monolithic PSD devices. Also,
refer to the section covering Conversion Issues at the end of this document.
Accessing the MCM FLASH die
The monolithic FLASH PSD devices (PSD813F1/F2/F3/F4/F5) will have 128 Kbytes of FLASH
main system memory available in eight segments, each segment containing 16 Kbytes. Standard
PSD architecture provides a separate chip select equation for each segment to afford flexibility
and is especially useful when paging is required. The PSD813FH MCM device will emulate this
segmenting by using a 4 Mbit (512 Kbyte) FLASH die and control signals from the PSD6XX die.
As a result, the MCM device will make 128 Kbytes of FLASH memory available to the MCU in
eight 16 Kbyte segments, just like the monolithic devices.
As shown in Figure 1, the control signals and some of the address lines for the FLASH memory
die are generated from Port C of the PSD6XX die. They are listed here in Table 2.