SFBBootBlock Struct Reference

The exactly-64-byte-long SFB 'boot block' contents. More...

#include <SFBBootBlock.h>


Data Fields

u8 version
 V1: The version of the bootblock goes in the first byte.
u8 writeTag
 V1: Determines which bootblock copy is newer.
u16 flags
 V1: Boot-related and miscellaneous flags.
u32 bootCount
 V1: The number of times the tertiary bootloader has booted a sketch.
u32 burnCount
 V1: The number of times the tertiary bootloader has burned a sketch.
u32 ownerId
 V2: The owner of this board, displayed in B36, 0xffffffff illegal.
u32 boardId
 V2: The name or id of this board, displayed in B36, 0xffffffff illegal.
u32 powerOnHours
 V3: The count of full uptime hours on this board, excluding any fractions lost to reboots.
u8 initialPower
 V4: The bits determining which faces should provide/accept power at boot time.
u8 watchdogResets
 V5: Which of last eight boots (LSB: most recent) involved watchdog resets.
u8 voltageCalib [15]
 V6: Optional ADC calibration data for NSEW faceVoltage, and railVoltage.
u8 reservedPadding [15]
 Reserved for future use; currently undefined; should not be read.
SFBChecksum cs
 The checksum of the first 60 bytes of this block.


Detailed Description

The exactly-64-byte-long SFB 'boot block' contents.

The SFBBootBlock structure is more complicated than it otherwise might be, to make it possible for an older tertiary bootloader to interoperate with a newer bootblock format in a reasonably sane way. In particular, an older tertiary bootloader should be able to verify the newer format, and get at the old fields that it knows about, without messing up newer fields it doesn't understand.

In addition, we reserve room in EEPROM for two SFBBootBlock, which are written to alternately, so that dying during a bootblock write will cause rollback to the prior bootblock, rather than the complete loss of all bootblock information. The value of the writeTag field determines which copy is 'current' and which is 'backup'.

This drastically reduces the chances that the (overall, redundant) boot block will be accidentally corrupted, even if a power failure occurs during a boot block update. Typically, in such a case, all that will happen is that interrupted update will be lost, and the backup, still-uncorrupted boot block will be treated as current instead.

Attention:
Although it is not documented with each method, note that all the SFBBootBlock methods have the potential to:
Blinks:
E_API_EEPROM_ADDRESS or E_API_EEPROM_RESPONSE or E_API_EEPROM_DATA if there are problems accessing the EEPROM device.

Field Documentation

V4: The bits determining which faces should provide/accept power at boot time.

V3: The count of full uptime hours on this board, excluding any fractions lost to reboots.

Note that maintaining this field involves an EEPROM write once an hour. This does age the EEPROM, although with the dual bootblocks it will take over two centuries to perform a million write operations. Nonetheless, if desired for whatever reason, incrementing of the powerOnHours can be suppressed by calling

.

V1: The version of the bootblock goes in the first byte.

If bootblock-handling code of a given version accesses a bootblock of a newer version, that older code must look only at the fields it understands (while faithfully double-buffering the entire block, however).

On the flip side, all future versions of the bootblock code must

  1. be able to upgrade all prior bootblock versions, and
  2. during such an upgrade process must change nothing in any preexisting field, except for the version.

V1: Determines which bootblock copy is newer.

If both bootblocks are valid, as they typically will be, then the 'more ahead' (in the sense of IS_LATER, except on 8 bits) writeTag value wins.


The documentation for this struct was generated from the following file:

Generated on Fri Apr 22 06:57:11 2011 for SFB by doxygen 1.5.9