µracoli Manual
Version foo
|
The wireless bootloader WiBo consists of three main parts
The following article describes the usage of the uracoli wireless bootloader. WiBo works like a regular bootloader, except that it uses the radio transceiver instead of a UART. WiBo modifies the flash directly, therefore no special backup flash memory, like in other over the air upgrade (OTA) solutions, is required on the transceiver board.
The WiBo framework provides a method to program the MCU that controls the transceiver. Three components are involved,
The python script wibohost.py sends a hexfile app.hex in slices to the host node. It transmits these data slices as unicast or broadcast frames to the network nodes. The network nodes collect the data slices and programm them with SPM (self programming mode) commands in the flash application section of the microcontroller.
In order to verfify if a node was programmed correctly, the host and network nodes calculate a CRC16 during the transmission and reception of the data slices. When programming is completed, the wibohost can query the CRC from the nodes and compare with its own checksum.
The bootloading can be done either in unicast mode or in broadcast mode. In unicast mode one node is programmed with a program image at one time. In broadcast mode, multiple nodes receive the image in parallel. This is useful for programming multiple instances of identical hardware with a firmware image.
consists of a Python script and the host node that runs the wibohost firmware. The script wibohost.py uses the module pyserial for serial communication with the host node. It reads and parses the given hex file and transfers it in slices to the host node. The host node firmware sends this slices in frames to one (unicast) or all (broadcast) network nodes.
resides in bootloader section of the network nodes and occupy about 1K words of programm memory. Additionally to the bootloader code, configuration record at the end of the bootloader section. This record ensures that the node address and channel information is available, even if the EEPROM was accidentely erased.
The network nodes are passive, that means they never send anything if not queried by the host node.
Before the Atmel radio transceivers can be used in a wireless network scenario, they need to be configured with some key parameters.
The most important parameter is the radio channel, e.g. the frequency on which the radios communicate. Depending of the radio type, the cannel can be 11 - 26 for the 2.4GHz radios and 0 - 10 for the 868/900 MHz radios. Which channel to choose depends on the area where the network is operated (for 868/900 MHz) and which other interferers are present (e.g. Bluetooth and WLAN for 2.4GHz). Since this topic can't be covered here complete, consult other information sources for selecting a radio channel to operate on.
Other important parameters are the node address and the network address. The IEEE-802.15.4 radios support a 16 bit (SHORT-ADDRESS) and a 64 bit (IEEE-ADDRESS) node address as well as a 16 bit network identifier (PAN-ID).
Since for bootloaders with the limited amount of programm memory no complex search and asociation procedures can be implemented, the channel and addressing parameters needs to be stored persistently in the Flash or EEPROM memory of the network node.
Since the EEPROM in AVR controllers can be easily erased or modified by the application, a safe place to store the radio configuration is the flash memory (the programm memory itself). Since the parameters should be accessible from the bootloader and from the final application, a so called configuration record is stored at the end of the flash memory.
In order to create the config record at the flash end, a Intel Hex file needs to be generated, that is flashed with the hardware programmer and .e.g. with the tool avrdude.
For generating config records for multiple nodes, the pythonscript +wibo/nodeaddr.py+ is used. Basically the tool can be used directly on the command line.
More detailed information about the tools options are displayed with the command
As you see in the above example a command line that covers all relevant parameters is very long and therefore error prone too. The script +nodeaddr.py+ can read its parameters also from a configuration file.
A initial nnotated config file for a network setup is created with the command:
Assuming that your network consists just of rdk230 boards, the file +mynetwork.cfg+ for the above command line would look so:
The HEX files for the nodes are generated with the next command:
or in very freaky pipeline way:
Here is an example for the Raven USB Stick. Applying the configuration record to the hex-file is done in the same manner as for the bootloader application.
To test the wireless bootloader environment, the xmpl_wibo application will be used. It blinks a LED with a certain frequency and is able to jump in the bootloader when the special "jump_to_bootloader" frame is received.
At first create some firmware versions, e.g. one slow and one fast blinking. The network nodes shall be rdk230 nodes.
Next assume that you have 4 network nodes with addresses [1,2,3,4]. In order to check the presence of the nodes, run the scan command.
Note that the default address range of wibohost.py is 1 ... 8. This can be modified with the -A option. In the example above, only the nodes 1 to 4 are present, therefore no response from the nodes 5 ... 8 is received.
At first we update all nodes with the slow blinking firmware. Therefore we use the broadcast mode (-U), that means that the image is transfered only once over the air. The address range (-A) is needed to ping the nodes before programming and afterwards to verify their CRC.
In the next step we selectively flash node 1 and node 3 with the file fast.hex. Since we use unicast programming (-u), the image is transfered for each node over the air seperately.
Build the bootloader for your board with the command
With the command +make -f wibo.mk list+ the available <board>s are displayed.
The bootloader expects an address record at the end of the flash memory section. This record can be generated with the script nodeaddr.py. Here is an example for the rdk230 board.
To verify the correct AVR fuse settings refer to http://www.engbedded.com/fusecalc.
To flash multiple nodes more efficiently, the nodeaddr.py can pipe its output directly into avrdude. This slightly more complex command line can be stored in script +flashwibo.sh+ (under Windows replace $1 by %1 for +flashwibo.bat+):
With the +python nodeaddr.py -h+ the help screen is displayed.
The AVR flash memory can be divided in an application and a booloader section. The application section is located in the lower address memory. The bootloader section is located in the upper flash memory. In this section the so called self programming opcodes (SPM) can be executed by the AVR core. This SPM opcodes allows erasing and reprogramming the application flash memory.
The start address of the bootloader section is determined by the BOOTLSZ fuse bits. The BOOTRST fuse bit determines, if the AVR core jumps after reset to the application section (address 0x0000) or to the bootloader section (e.g. address 0xf000). The AVR fuse bits and the content of the bootloader section can only be changed either by ISP, JTAG or High Voltage programming.
In order to have enough memory for the application available, the booloader section is choosen to be rather small, e.g. for 8K devices a 1K bootloader section and 7K application section is a reasonable choice. The larger 128k AVR devices are partitioned usually with a 4K bootloader section, leaving 124K flash memory for the application.
For WiBo, the last 16 byte of the flash memory are reserved for a configuration record, that holds address and channel parameters, which are needed for operation. The structure of this record is defined in file +board.h+ in the type +node_config_t+. It stores
2 byte CRC16
The configuration record is accessible from the applicatation and from the bootloader section.
The file wibohost.py can also be used as a python module. The following script shows how a broadcast and a unicast flash can be programmed.