In order to perform firmware updates with the OpenBLT through a TCP/IP network, double-check that the network communication interface is configured in “blt_conf.h”. The following macro should have a value of 1. If this macro did not yet have a value of 1, the bootloader should be rebuild after making the change.

#define BOOT_COM_NET_ENABLE            (1)

The MicroBoot utility needs to be configured to connect to the correct IP address and port:

• Start MicroBoot by double-clicking “\Host\MicroBoot.exe” (on Linux it is “\Host\MicroBoot”).
• Click the “Settings”-button and select “XCP on TCP/IP” from the “Interface selection” dropdown box.
• Set the IP address (or fully qualified domain name) of your microcontroller system on the network. Note that the IP address is also specified by the macro's BOOT_COM_NET_IPADDR in “blt_conf.h”.
  • Set the port on which the bootloader listens for firmware update connection requests. This is specified by the macro BOOT_COM_NET_PORT in “blt_conf.h”. Typically, this is 1000 for the demo programs.

Once you saved the settings by clicking the “OK”-button, MicroBoot is now ready for action!

After building your user program, its S-record formatted firmware file can be downloaded to the remaining flash memory using the bootloader. In MicroBoot click the “Browse”-button and select your user program's firmware file. For the demo programs, this one is located in the “.\Prog\bin\” directory. Once the firmware file was selected, the download should automatically start.

Once the download completed, the newly programmed software will be started by the bootloader. For the demo program's you can verify this by checking that the LED blinks. Congratulations! That's all there is to using the bootloader.

The BootCommander command line interface (CLI) program allows you to configure all communication settings via options on the command line. The following example demonstrates how to call BootCommander for making a firmware update with one of the demo programs. Just set the “-a” option to the IP address or hostname of the target to connect to and set the “-p” option to the TCP port number that the target listens on..

BootCommander -s=xcp -t=xcp_net -a=192.168.178.23 -p=1000 demoprog_ek_lm3s6965.srec

The example assumes that the S-record of the demo user program is located in the same directory as where the BootCommander executable itself resides. If not, then simply prepend the absolute (or relative) directory to the name of the S-record firmware file.

The initialization of the TCP/IP network stack, up to the point where the bootloader can accept firmware update requests, can take several seconds. This delay occurs after each reset event, before your user program is started. Because such a long delay is typically not desired, the demo programs have the so called deferred initialization functionality enabled. This was done via configuration macro BOOT_COM_NET_DEFERRED_INIT_ENABLE in “blt_conf.h”.

With the deferred initialization enabled, the TCP/IP stack initialization is skipped during a normal reset event, unless: (a) there is no valid user program present, or (b) the bootloader was forced to stay active. This latter case happens when the CpuUserProgramStartHook()-function is enabled and returns BLT_FALSE.

To be able to perform remote firmware updates without having to access the system, a third scenario was added in the demo programs for forcing the TCP/IP stack to be initialized. This is the case when the bootloader was started from the user program. The shared parameter module was integrated into both the demo bootloader and user program, to be able to pass information from the user program to the bootloader. After the user program detects a firmware update request from the TCP/IP network, it sets a shared parameter in RAM right before the bootloader is activated. Upon activation, the bootloader evaluates the shared parameter and initializes the TCP/IP stack when requested.