their respective memory addresses. Note that EEPROM is
not a part of the PIC32MX’s memory scheme. By utilizing
the PIC32MX Peripheral Library NVM (Nonvolatile
Memory) calls, the PIC32MX’s program Flash can be used
the same way that EEPROM is used in PIC devices that
support on-chip EEPROM. There’s lots of PIC32MX memory to work with, which is a good thing. Functional flexibility
comes as standard equipment with the massive memory
space by way of memory control SFRs. By loading base
values into the PIC32MX’s memory SFRs, separate user
program and data memory areas can also be carved out
of the 4 GB memory space. We can even go as far as
specifying the size of our program Flash and data RAM
memory areas. The PIC32MX can be configured to execute
instructions from data RAM via manipulation of the values
placed within the PIC32MX memory SFRs.
A graphical representation of the PIC32MX virtual and
physical memory is shown in Figure 1. If you look up the
word virtual, the words “computer simulation” will most
likely be injected into the definition at some point.
I like to think of virtual in terms of a computer’s
logical view of and use of its physical resources.
Take another look at Figure 1. The lower 2 GB
(0x00000000 - 0x7F000000) of PIC32MX virtual
memory space is called the USEG/KSEG segment.
The “K” here represents Kernel, while the “U”
stands in for User. The PIC32MX’s virtual memory
is divided into User and Kernel space. User mode
applications must reside and execute within the
USEG segment. If you’re wondering why a KSEG
moniker is tacked onto the USEG segment definition, that’s because the USEG memory segment is
also available to Kernel mode applications.
The upper 2 GB of virtual memory area
(0x80000000 – 0xFFFFFFFF) is Kernel-only
memory space. The PIC32MX Kernel-only memory space is partitioned into four 512 MB
(0x20000000) segments: KSEG0 (0x80000000-
0x9FFFFFFF); KSEG1 (0xA0000000-0xBFFFFFFF);
KSEG2 (0xC0000000-0xDFFFFFFF); and KSEG3
(0xE0000000-0xFFFFFFFF). As I mentioned earlier,
Kernel mode applications can dip into User mode
memory space. However, User mode applications
are not allowed to participate in or access the
Kernel mode memory space.
Note that KSEG0 and KSEG1 are identical with
the exception of the inclusion of the INTERNAL
PERIPHERALS partition, which is mapped into
KSEG1. The PIC32MX’s CPU uses virtual
addresses to address the peripherals, which means
that to access the PIC32MX’s peripherals we (and
the CPU) must be operating within the virtual boundaries of
KSEG1. The PIC32MX’s CPU also uses virtual addressing to
fetch and execute program memory instructions. Here’s
where the virtual fetch and execution process takes
advantage of its physical roots. If you look closely, you’ll see
that the physical address extents between the physical
INTERNAL RAM at physical address 0x00000000 and the
INTERNAL BOOT FLASH beginning at physical address
0x1FC00000 match up with the virtual memory schemes of
KSEG0 and KSEG1. The PIC32MX CPU maps the virtual
areas of KSEG0 and KSEG1 against the same physical
memory area beginning at physical address 0x00000000.
KSEG0 and USEG-KSEG are cacheable while KSEG1 is
not cacheable. Because both the KSEG0 and KSEG1 virtual
segments point to the same physical memory area, the
PIC32MX CPU can execute instructions from either the
KSEG0 or KSEG1 virtual memory segment, depending on
the cacheable status of the application.
The PIC32MX contains a Fixed Mapping Translation
■ FIGURE 1. At first glance, this looks pretty hard.
Once you associate the virtual segments with their
respective physical addresses, it all comes clear
and easy. I used this memory map and the MPLAB
debugger memory window to gain a better
understanding of how the PIC32MX uses virtual
March 2008 77