In applications like server power supply, metering, and so forth. the system is desired to be run continuously to reduce downtime. But typically during firmware upgrades due to bug fixes, new features, and/or performance improvements, the system is removed from service causing downtime for associated entities as well. This can be handled with redundant modules but with increase in total system cost. An alternate approach, called Live Firmware Update (LFU), allows firmware to be updated while the system is still operating. Switching to new firmware can be done either with or without resetting the device, with the latter being more complex.

LFU is feasible when the device has enough resources of various kinds – CPU bandwidth, Memory, and Peripheral availability:

• CPU Bandwidth – The new firmware has to be transferred using a communication peripheral and written to flash memory while the application is still operating. This means CPU need to have enough available bandwidth to support LFU.
• Memory – The non-volatile memory that is used here is Flash memory. Flash read and write operations cannot be simultaneously performed on the same Flash bank. However read and write operations can be simultaneously performed on different Flash banks. Hence, the ideal scenario is for the device to contain dual Flash banks. In devices with single Flash banks, LFU is particularly challenging, but still feasible provided:
  • The complete application code (or a portion of it that controls the output(s) the user is interested in) and Flash APIs need to run from RAM memory while the new firmware is updated to Flash. This means there should be enough RAM memory that can be utilized.
  • Some devices support Flash APIs in ROM; in those devices the application code can run from RAM and Flash APIs can run from ROM memory, thus reducing the RAM requirement.
• Peripheral Availability – A spare communication peripheral using the new image can be transferred from the host to the device.

LFU is easier to implement in devices with multiple Flash banks. In this document and the reference example, it is assumed that the device has 2 Flash banks. The device considered is TMS320F28004x, which has dual flash banks. Their address space is 64K x 16 each, with addresses ranging from 0x80000-0x8FFFF, and 0x90000-0x9FFFF.

The Flash memory has been partitioned as shown in Figure 3-1.

Figure 3-1 Flash Memory Contents for Bank 0 and Bank 1

Assuming each Flash bank has 16 sectors, two sectors have been allocated to Static code (code that will not change between applications). This is described in Section 4.

A few locations in sector 2 have been reserved to store the below entries:

• START – when this 64-bit field is set in a specific Flash bank (to 0x5A5A5A5A5A5A5A5A) by the Serial Communications Interface (SCI) Flash Kernel, it indicates that the corresponding Flash bank has been erased (Application sectors) and programming/verification is about to begin. In this example, the START field is located at addresses 0x82000 in BANK0 and 0x92000 in BANK1.
• REV – this represents a 32-bit Firmware revision number that is set by the SCI Flash Kernel which is used by the Bank Selection Logic to determine which the latest image is between Flash bank 0 and 1. REV starts at 0xFFFFFFFF and is decremented on each subsequent Flash programming cycle. Thus, the Bank with the lower revision number is considered the latest one. Firmware revision field is handled by the flash kernel for simplicity. In practice, the last downloaded image may not be the latest firmware version and the application image would contain the firmware version, but that assumption is made with this model where the kernel updates the REV field. In this example, the REV field is located at address 0x82006 in BANK0 and 0x92006 in BANK1. As an example, if the REV in BANK0 is FFFF FFFA, and the REV in BANK1 is FFFF FFF9, BANK1 will be considered the latest firmware and will execute.
• KEY– The image in a bank is considered as valid if this location contains a valid KEY (0x5B5B5B5B). This Key is written to by the SCI Flash Kernel, and is read and tested by the Bank Selection Logic. In this example, the KEY field is located at addresses 0x82004 in BANK0 and 0x92004 in BANK1.

The rest of sector 2 and sectors 3-15 can be used to store the application image. This allows the static code in sectors 0 and 1 to be programmed once, and remain unchanged during LFU.

Static code that is used to support LFU consists of:

• Bank Selection Logic – when there are two (or more) Flash banks containing application firmware, logic that determines which Flash bank to boot is necessary. A common implementation of this logic centers on a firmware revision number. As described, the lower revision number is the latest image in this Example. Bank selection logic is placed at the default flash boot address (0x80000 in F28004x), so that once Boot ROM code completes execution, execution will transfer to bank selection logic. Bank selection logic is only included in Bank0, not in Bank1.
• Flash Kernel – it is the job of the Flash kernel to receive the Firmware image from the host using a peripheral, and call the Flash programming APIs to write it to flash memory. In this document, the SCI flash Kernel is used since the SCI peripheral is used to transfer the new firmware image. The detailed step by step flow is documented in the file header of flashapi_ex2_ldfu.c.
  • In a blank device (where application firmware is not present in either flash banks) the bank selection logic will identify there is no valid KEY in either Flash bank, and will wait for an LFU command over SCI. This will use the Flash Kernel to update the firmware on to bank1 as the kernel code is first programmed to bank0, and therefore executes from bank0.
  • If one or both banks contains a valid application, bank selection logic will transfer control to the code entry point (codestart) of the corresponding bank. In this example, the codestart address is 0x8EFF0 for Bank0 and 0x9EFF0 for Bank1.
  • During LFU, the application will make a call to the Flash Kernel to receive and update the firmware.
• Flash API – Flash APIs provide interfaces to erase and program Flash memory. These APIs need to run from the bank which is NOT being updated.

The static code is configured as a single example - flashapi_ex2_sci_kernel project (included in C2000Ware at <C2000Ware>\driverlib\f28004x\examples\flash). This example supports multiple build configurations, of which those relevant to LFU are listed below:

• BANK0_LDFU - Links the bank selection logic and flash kernel to Bank 0 (addresses 0x80000 - 0x81FFF). Uses Flash API symbols in flash.
• BANK0_LDFU_ROM - Links the bank selection logic and flash kernel to Bank 0 (addresses 0x80000 - 0x81FFF). Uses Flash API symbols in ROM; Rev A of F28004x cannot be used with this build configuration, since it does not support Flash APIs in ROM.
• BANK1_LDFU - Links the flash kernel to Bank 1 (0x90000 - 0x91FFF). Uses Flash API symbols in flash.
• BANK1_LDFU_ROM - Links the flash kernel to Bank 1 (0x90000 - 0x91FFF). Uses Flash API symbols in ROM; Rev A of F28004x cannot be used with this build configuration, since it does not support Flash APIs in ROM.

For more details, see the flashapi_ex2_sciKernel.c in the flashapi_ex2_sci_kernel project (included in C2000Ware at <C2000Ware>\driverlib\f28004x\examples\flash).

This example (flashapi_ex3_live_firmware_update project) is designed to demonstrate LFU with the LED blinking periodically. This is achieved using the Live Device Firmware Update (Live DFU or LDFU) command, which is part of SCI kernel. This is to be used with the Serial Flash Programmer (PC tool).

In this example, an SCI auto baud lock is performed and the byte used for auto baud lock is echoed back. Two interrupts are initialized and enabled: SCI Rx FIFO interrupt and CPU Timer 0 interrupt. The CPU Timer 0 interrupt occurs every 1 second; the interrupt service routine (ISR) for CPU Timer 0 toggles an LED based on the build configuration that is running.

• LED1 is toggled with the BANK0_FLASH build configuration. “BANK0” is a pre-defined symbol in this build configuration, and when this symbol is defined, the project sets up GPIOs associated with LED1.
• LED2 is toggled with the BANK1_FLASH build configuration. “BANK1” is a pre-defined symbol in this build configuration, and when this symbol is defined, the project sets up GPIOs associated with LED2.

The application images generated by building the above build configurations are the ones that will be used to illustrate LFU in this document. Note that other than the changes described above between the two build configurations, there are no other differences between the two application images. Hence, this is a relatively simple example for LFU illustration.

The SCI Rx FIFO interrupt is set for a FIFO interrupt level of 10 bytes. The number of bytes in a packet from the Serial Flash Programmer (when using the LDFU command) is 10. When a command is sent to the device from the Serial Flash Programmer, the SCI Rx FIFO ISR receives a command from the 10 byte packet in the FIFO. If the command matches the Live Device Firmware Update (Live DFU) command, then the code branches to the Live DFU function (liveDFU()) located inside of the SCI Flash Kernel (flashapi_ex2_ldfu.c) for the corresponding bank. So if the application on Bank0 is executing, control will pass to liveDFU() on Bank0, located at 0x81000. If the application on Bank1 is executing, control will pass to liveDFU() on Bank1, located at 0x91000. Within this function, execution passes to the ldfuLoad() function in order to erase the appropriate bank, load a hex formatted program (in the appropriate SCI boot format) into flash, and verify the program. Then the watchdog is configured for a reset. At the end, the watchdog is enabled in order for a reset to occur. When the device resets, it boots and loads the new Firmware.

Figure 5-1 depicts the flow of the code at a high level after the code enters main() of the application. For more details, see the flashapi_ex3_live_firmware_update.c located in the flashapi_live_firmware_update project (included in C2000Ware at <C2000Ware>\driverlib\f28004x\examples\flash).

Figure 5-1 Code Flow After Entering main() of Application