UPSD33XX Datasheet, PDF (140/231 Pages) STMicroelectronics – Fast 8032 MCU with Programmable Logic

uPSD33xx
EEPROM Emulation. EEPROM emulation is
needed if it is desired to repeatedly change only a
small number of bytes of data in Flash memory. In
this case EEPROM emulation is needed because
although Flash memory can be written byte-by-
byte, it must be erased sector-by-sector, it is not
erasable byte-by-byte (unlike EEPROM which is
written AND erased byte-by-byte). So changing
one or two bytes in Flash memory typically re-
quires erasing an entire sector each time only one
byte is changed within that sector.
However, two of the 8K byte sectors of Secondary
Flash memory may be used to emulate EEPROM
by using a linked-list software technique to create
a small data set that is maintained by alternating
between the two flash sectors. For example, a
data set of 128 bytes is written and maintained by
software in a distributed fashion across one 8K
byte sector of Secondary Flash memory until it be-
comes full. Then the writing continues on the other
8K byte sector while erasing the first 8K byte sec-
tor. This process repeats continuously, bouncing
back and forth between the two 8K byte sectors.
This creates a wear-leveling effect, which increas-
es the effective number of erase cycles for a data
set of 128 bytes to many times more than the base
100K erase cycles of the Flash memory. EEPROM
emulation in Flash memory is typically faster than
writing to actual EEPROM memory, and more reli-
able because the last known value in a data set is
maintained even if a WRITE cycle is corrupted by
a power outage. The EEPROM emulation function
can be called by the firmware, making it appear
that the user is writing a single byte, or data
record, thus hiding all of the data management
that occurs within the two 8K byte flash sectors.
EEPROM emulation firmware for the uPSD33xx is
available from www.st.com/psm.
Alternative Mapping Schemes. Here are more
possible memory maps for the uPSD3333.
Note: Mapping examples would be slightly differ-
ent for uPSD3312, uPSD3334, and uPSD3354
because of the different sizes of individual Flash
memory sectors and SRAM as defined in Table
82., page 155.
– Figure 55. Place the larger Main Flash
Memory into program space, but split the
Secondary Flash in half, placing two of it’s
sectors into XDATA space and remaining two
sectors into program space. This method
allows the designer to put IAP code (or boot
code) into two sectors of Secondary Flash in
program space, and use the other two
Secondary Flash sectors for data storage,
such as EEPROM emulation in XDATA space.
– Figure 56. Place both the Main and
Secondary Flash memories into program
space for maximum code storage, with no
Flash memory in XDATA space.
Figure 55. Mapping: Split Second Flash in Half
FFFFh
8032 PROGRAM
SPACE (PSEN)
Page Page Page Page
0
1
2
3
8032 XDATA SPACE
(RD and WR)
Page X
FFFFh
fs1 fs3 fs5 fs7
16KB 16KB 16KB 16KB
C000h
8000h
fs0
16KB
fs2
16KB
fs4
16KB
fs6
16KB
Nothing Mapped
4000h
csboot1, 8KB
2000h ^{Common Memory to All Pages}
csboot0, 8KB
0000h ^{Common Memory to All Pages}
System I/O
8000h
csboot3
8KB
6000h
csboot2
8KB _4000h
System I/O _2100h
csiop, 256B _2000h
rs0, 8KB
0000h
AI09174
Figure 56. Mapping: All Flash in Code Space
FFFFh
8032 PROGRAM
SPACE (PSEN)
Page Page Page Page
0
1
2
3
8032 XDATA SPACE
(RD and WR)
Page X
FFFFh
fs1 fs3 fs5 fs7
16KB 16KB 16KB 16KB
C000h
fs0 fs2 fs4 fs6
16KB 16KB 16KB 16KB
8000h
csboot3, 8KB
6000h ^{Common Memory to All Pages}
csboot2, 8KB
4000h ^{Common Memory to All Pages}
csboot1, 8KB
2000h ^{Common Memory to All Pages}
csboot0, 8KB
0000h ^{Common Memory to All Pages}
System I/O
2100h
csiop, 256B _2000h
rs0, 8KB
AI09175
0000h
140/231