| NVFS Memory Shuffle Issues |
Before we can explain the problem properly, it is necessary for us to first explain exactly what NVFS is and how it operates. Since this page is only for the technically minded, we will go directly to Palm's description of NVFS as presented to developers.
This has been abbreviated and only the relevant portions are included here. For a full description, see the Palm Developer Guide, version 5.1 page 95.
|
NVFS stands for Non-Volatile File System. Storage in Palm devices traditionally included nonvolatile NOR flash where the Palm OS and built-in applications were stored, and a volatile SDRAM (synchronous dynamic random access memory) where the Dynamic and Storage heaps were stored. If the power was removed, all data in the RAM was deleted.
NOTE Throughout this section, the term ROM denotes read-only memory, and the term rom (lowercase) denotes the OS, Palm system code/drivers, and other built-in applications.
The main difference between NOR and NAND flash memory is that NOR flash is completely XIP (execute in place), and all addresses in a NOR flash are mapped using address pins so that each byte can be accessed. In NAND flash memory, data is accessed in blocks, and only a small section. The section that houses the boot code is XIP.
This means that code instructions cannot be executed out of NAND memory directly, and thus require the rom, as well as any other application, to be executed from DRAM.
Copying and uncompressing the rom to DRAM for execution occurs at early boot time. Other applications residing in the Storage Heap are copied upon launch from NAND to DRAM for execution. Both code and data is copied to/from the NAND Storage Heap into the portion of the RAM used as a cache, called DBCache. DRAM must also contain another area for an application's local data; this area is called the Dynamic Heap.
...
When an application is launched, records and resources are copied from flash, as required, into DBCache. In addition, when a database is opened by an application, it is copied from flash into DBCache and is accessed directly from DBCache. All application access to its databases goes directly to DBCache only; it does not know that there is flash storage behind it. Because the cache is write-back, writes to DBCache do not immediately propagate back to flash. Instead the OS writes back those changes at the following occurrences: the database is closed, the system goes to sleep (auto off or user powers the device off), a call is made to DmSetDatabaseInfo, or a call is made to the new NVFS API (DmSyncDatabase). At these times, the database is scanned for “dirty” records, and those records are written back to flash.
...
Because the DBCache size is limited to approximately 10MB, resource databases are currently limited to this size. For large record databases, the OS intelligently purges or flushes data from the cache to free space for new records: If the DBCache becomes full, the OS purges records that are not locked in memory. If the records are modified, they are committed back to flash memory. The purging of data takes place in the background and is seamless to the user. You should be aware that there are some performance issues associated with this method. There may be a noticeable time difference in performance compared to earlier devices when a large amount of data is flushed back from the cache into the NAND flash memory.
|
Now, the key to understanding the reset problem is in the very last paragraph: If the DBCache becomes full, the OS purges records that are not locked in memory.
When your program was activated it set itself up on the device and either patched some system function calls to point to itself, or it registered for some notifications so it could preform its task. Notifications are better than patches, but neither is particularly bad and often times it is the only way a programmer can accomplish what they want to get done.
During a backup, the memory of your entire "User Data" space is cycled through the DBCache. This is done transparently and automatically by the NVFS portion of the Palm device. During this cycling, anything left unlocked in the DBCache is flushed back to the "User Data" space. This includes your program from earlier.
After the backup is complete, control passes from the Backup Loop back to the PalmOS Event Handler. When this happens, your device resumes doing what it was told. If a function was patched, the next time that function is called PalmOS jumps to the location of that patch, but that patch is no longer there. It was cycled out of memory by the system during the backup. If the program was notification based it receives it's next notification, but when it goes to act upon that notification it also jumps to data that is no longer in the DBCache. Either instance results in a reset immediately following a backup operation.
Programs that use the notification system when they are not the active application, or programs that patch OS function calls need to be updated to ensure they are always "locked down" in the DBCache. This is not as simple as it sounds, in some versions of NVFS it appears that Palm does not respect the traditional methods of locking a database.
You should check with the author of the specific program to determine when/if they will have a version that properly locks itself in the DBCache.
|
