Chapter 7: Flash Application Layout
37
TI
-
89 / TI
-
92 Plus Developer Guide
Not for Distribution
Beta Version January 26, 2001
0x1000 — ACB_BG, app receives background
processing.
0x4000 — ACB_COMPRESS, app is being moved
during Flash memory compression.
0x8000 — ACB_DELETE, app is about to be
deleted.
AppID
myID
— ID of this app.
AppID
nextID
— ID of the next app in the linked list.
AppID
prevID
— ID of the previous app in the linked list.
ULONG
publicStorage
— Temporary storage space for the app.
AppHdr const *
appHeader
— Pointer to the AppHdr structure. An AppHdr resides
with the app in Flash memory and cannot be changed.
BYTE const *
certhdr
— Pointer to the certificate header.
pFrame
appData
— Handle to the app’s object frame. Use
OO_Deref
to
convert it to a pointer.
The OS allocates memory for applications from two pools. The executable code
and constant resources (.text and .const sections) are stored in Flash ROM.
Static variables (.data and .bss sections) are stored in RAM.
Applications are stored in Flash memory beginning at the first sector boundary
after OS code. The OS reapportions archive memory to application memory as
needed to make room for additional Flash applications. When an application is
deleted, applications after it in memory are moved up to fill the void. Flash
sectors vacated during this process are returned to archive memory.
One pad byte of 0xFF is added between apps if needed to make sure each app
begins on an even address boundary.
The OS allocates the application’s static data in high RAM. The handle to this
chunk of memory is locked to assure that it does not move during heap
compaction. The data segment contains the app’s Application Control Block,
initialized data (.data), and uninitialized data (.bss). The OS frees the data
segment when the application is deleted.
To Next Page
Loading...
Need help?
General
