Here’s a little bit more technical information on the LEGO Mindstorms NXT file system and memory.

The main processor on the NXT is an ARM7 RISC CPU equipped with 256K bytes of flash memory and 64K bytes of RAM memory

Sector size on the flash memory is 256 bytes. There are hardware commands to erase either a single sector or all sectors at once. The “erase” and “write” command operates on a complete sector in flash.

The NXT firmware is loaded into flash memory starting from the front. The “leftover” flash (about ~128K) at the rear is used for the NXT’s file system

The last sector in the flash contains the file system “table of contents” (TOC). It is a 64 element array of pointers. Each pointer is either NULL or the starting address of the first flash sector of a file. Since the TOC is only one sector long, the NXT file system is limited to 63 files total. One of the “pointers” is used to contain some flags.

Flash memory is specified to support 10K write cycles. It might be worrisome that the TOC is written so often that this will be exhausted in a year or two of heavy use (two rewrites per file download!). Fortunately, (1) the spec appears to be extremely conservative and (2) the most common failure mode is the flash will simply not retain its contents for the full 10 years in its design spec.

The first few bytes of a file contain system information about the file – like its name – and access to these bytes is normally hidden from user programming.

The file system supports two storage formats for files:

• A linear contiguous block of flash memory.
• A linked list of flash sectors

The “contiguous block” format is required for user programs and certain data files. Programs – both the NXT firmware and user programs – are executed directly from flash memory.

Fragmentation of the file system is one reason that a large program file might not be loadable onto a NXT. There may not be a single contiguous block of free flash to accommodate the file. A periodic defragment operation may be infrequently required.

Some CPUs allow simultaneous read access to other locations in flash memory while a sector is being written or erased. This is not the case with the NXT’s CPU. A flash erase or write operation stops all other flash accesses. It can take up to six milliseconds to update a flash sector! The NXT firmware execution is essentially “stalled” during that time

Normally you’d still want interrupts – USB and BT messaging, motor encoder count updates, sound playback, etc – to continue to function during the flash updates. So the “trick” is to relocate the interrupt handlers in RAM memory which can still be accessed during flash updates. The interrupt handlers are stored in the flash firmware image; on initial startup they are copied to RAM and it is these versions that are subsequently executed

The RobotC development system is one of the first 3rd party alternative development environments for the NXT. It has some enhancements to improve on the issues mentioned above:

• It has a PC based file defragmenter program. The defragmenter moves all the files on the NXT tightly together and collapses the empty file space into a single region.
• It has a comprehensive RAM based data logging capability. Use of RAM instead of NXT file systems will ensure that users program aren’t stalled if data is logged to a flash file. There are also easy commands to copy datalog to a flash file when program terminates.
• Standard firmware uses a polling technique is used to increment the 1-msec system clock. Clock ticks can be dropped when flash memory is updated. RobotC has a interrupt based implementation that captures all counts.
• It supports compressed audio (RSO) files to minimize flash usage.

One final tidbit. Ever noticed the file “NVConfig.sys” on your NXT and wondered what it is? It’s a normally hidden system file containing persistent storage for your power down delay and volume level settings.