Is it possible to build a device with a ROM memory part to contain the Neuron Firmware, and a Flash memory part to contain the application? (KB234) – Knowledge Base

Question Detail

Is it possible to build a device with a ROM memory part to contain the Neuron Firmware, and a Flash memory part to contain the application? That way I would only need to change the flash when upgrading the node's software.

Solution

The Neuron Chip firmware is based on the premise that Neuron Chips will be used in control networks instead of as stand-alone microcontrollers. This firmware (and the concept of this design) implements four distinct "images":

- system image
- application image
- network image
- communication parameters

In simplified terms, the SYSTEM image contains the protocol, the I/O models, the scheduler, and a boot-image. The APPLICATION image is your Neuron C program. The NETWORK image contains the network variable offsets, as well as binding and address information. The COMMUNICATIONS PARAMETERS define the transceiver and channel specifications.

It is important to keep these images synchronized. Four properly initialized and synchronized images make up a complete functioning device. Also, it is important to understand that these images can be updated independently of one another--provided that they remain synchronized. If we assume that the SYSTEM image is fixed (not movable and not modifiable), and is the same for all devices, it would make sense that you could create a ROM that contains the system image, and a FLASH that contains the APPLICATION image. If you want to change the application, you just change the FLASH.
Unfortunately, this is not possible with the Neuron Chip because the SYSTEM image is not fixed. It varies based on the APPLICATION image. The part that varies is the boot-image. The boot-image contains: checksums, read-only data structures, the memory map of the entire device, and entry points to "when()" statements. This boot-image is created by the linker/loader and packaged into the system image. The firmware implements the following boot process steps:

At boot time, the firmware compares the boot ID in the ROM boot-image area to the boot ID in the Neuron Chip's on-chip EEPROM. If the boot IDs do not match, the firmware will copy the ROM-based boot-image and boot ID to the on-chip EEPROM.
Next, a CRC (cyclical redundancy check) is performed on the APPLICATION image. That computed CRC is compared to a value in the Neuron Chip's on-chip EEPROM boot-image. If the computed CRC does not match the value in on-chip EEPROM, the node goes into the applicationless state.

If you change the FLASH part, step 2 (the application CRC) fails and the node goes into the applicationless state. If you run EEBLANK, and then reboot the Neuron Chip with your second FLASH part, step 1 (the boot ID comparison) passes, but step 2 will again fail. Even writing the boot ID manually, and computing the checksums manually, is not enough. The entire on-chip boot-image must be re-initialized for the Neuron Chip to boot properly.

The reason this works with a networked device is that the loader is smart enough to re-initialize the entire on-chip boot ID. Since the load process does not change the boot ID in ROM, step 1 passes when the newly loaded node is reset, and step 2 passes because the proper checksums have been entered in the on-chip boot-image section by the linker/loader. Further, and most importantly, the linker/loader updates the on-chip boot-image section to contain the proper network variable offsets and "when()" clause entry points for the new application.

Comments