Atmel 8390 WIRELESS AVR2054 Serial Bootloader User Guide Application Note
Atmel 8390 WIRELESS AVR2054 Serial Bootloader User Guide Application Note
Atmel 8390 WIRELESS AVR2054 Serial Bootloader User Guide Application Note
Features
Introduction
8390DWIRELESS03/2015
Table of Contents
1. Overview ............................................................................................ 3
1.2 Supported platforms and interfaces .................................................................. 3
1.3 Package content and structure ......................................................................... 4
1.3.2 Precompiled bootloader firmware ....................................................... 5
5. Reference ......................................................................................... 21
6. Document revision history ................................................................ 22
The concept of firmware programming with the serial bootloader is shown on Figure 1-1. The embedded bootloader
preprogrammed to the MCU receives an application image over serial interfrace and writes it to the internal MCU flash.
An application firmware image should be loaded in the Motorola S-record hexadecimal format (SREC) and is expected
to be transferred by a host device. The host may be a PC or another MCU/MPU. It should be connected to the target
MCU via supported serial interface and deliver the application image following the specific protocol.
Figure 1-1. General approach for using serial bootloader for MCU programming.
Embedded
Bootloader host bootloader
application Serial
connection
Application
.srec
Image
image
Embedded bootloader also supports some stack-specific functionality required to perform firmware Over-The-Air
Upgrade (OTAU) procedure in ZigBee or RF4CE networks. Sections 3.7 and 3.8 provide more information on this topic.
Chapter 3 describes in details how the embedded bootloader works on different serial interfaces as well as how to
configure and compile its source code.
For convenience the Serial Bootloader package includes pre-compiled images of the embedded bootloader images in
different configurations. It also contains Atmel implementation of a PC host application - Bootloader PC tool that can be
operated as a GUI application or as a command line tool (see Chapter 4 for instructions how to use it).
The Bootloader PC tool may also be used to initiate an Over-the-Air Upgrade (OTAU) of a ZigBee network by
transferring a firmware image to the OTAU server device connected to the PC via a serial interface. See Section 3.7 as
well as [8] for more details.
Embedded bootloader can work with several different serial interfaces simultaneously as listed in the table Table 1-1
(except of TWI that needs to be used alone only). More details on the interface configurations are given in Section 2.1).
ATSAMR21E18 USART0,
(1)
Configurable N/A ATSAMR21-XPRO
ATSAMR21G18
pins
(1)
ATmega256RFR2 USART0 AT256RFR-XPRO
ATmega2564RFR2 USART1 AT256RFR2-EK
ATZB-S1-256-3-0-C [10]
ATmega128RFA1 TWID ATRF4CE-EK
USB_FIFO ATAVR128RFA1-EK1
USARTF0
USARTD0
REB2xxED-EK
ATxmega256A3 SPIE N/A
STK600 + RZ600
TWIC
TWIE
USARTD0
ATxmega256D3 N/A STK600 + RZ600
TWIC
USART0
USART1 (2)
ATmega1281 N/A RCB230 / 231 / 212
USB_FIFO
TWID
(2)
AT91SAM3S4C USB_DFU N/A deRFusb-23E00
(1)
Requires connection Flow Control to be set to Hardware on the host side.
(2)
Non-Atmel products; see http://www.dresden-elektronik.de for details and purchase.
Note: There are three configurations of embedded bootloader firmware distinguished by their functionality: common serial
bootloader, serial bootloader with OTAU support for Atmel BitCloud applications and serial bootloader for RF4CE-
based applications. The latter two provide extra functionality in addition to common serial bootloader features. For
details see Sections 3.7 and 3.8.
More details on the interface configurations are given in Section 2.1.
Table 1-3. Default serial port settings for embedded bootloader images.
Used MCU
MCU Precompiled image(s) Comment
port
Several different interfaces and ports can be enabled for bootloader use at the same time. As described in Section 3.5
embedded bootloader will scan them for required handshake packages one after another. Note however that TWI
interfase can be operated only alone.
Default port configuration used for UART and hence also in precompiled firmware images is given in Table 2-1.
For Atmel PC Bootloader tool to operate correctly as a host over UART it shall get the connection enumerated as a COM
port and configured as described in Table 2-1.
Caution: TWI interface in the embedded bootloader must be used only alone and cannot be enabled together with any
other serial interface.
When using Bootloader PC tool it is recommended to have Xmega-A1 Xplained board [13] as a TWI-to-USB bridge that
provides connection to the PC and can get it enumerated as a COM port.
Atmel XMEGA-A1 Xplained kit contains ATxmega128A1 and AT32UC3B1256 devices. The preprogrammed
AT32UC3B1256 device acts as a USB-to-UART gateway. The ATxmega128A1 device on this board shall be
programmed with the firmware image XplainedA1SerialToI2CBootLoaderBridge.hex from
\ThirdPartySoftware\XMEGA_A1_Xplained_Firmware\ to make it act as a USART-to-TWI bridge. TWI on PORTD
is used by ATxmega128A1 and thus GPIO0 (SDA) and GPIO1 (SCL) of PORTD of XMEGA PORTD header of Xplained
board shall be used to connect to the target MCU via TWI. The programming of firmware image to ATxmega128A1
device is explained in Connecting the board Section of AVR1927: XMEGA-A1 Xplained Getting Started Guide [12].
When connecting the XMEGA-A1 Xplained to PC, the operating system will request a driver file for installing the serial
communication driver. This driver file XPLAINED_Virtual_Com_Port.inf is available in
\ThirdPartySoftware\XMEGA_A1_Xplained_Firmware\ folder.
After VCP has enumerated PC Bootloader tool should be used with COM port settings given in Table 2-1.
An MCU must be aware of the size of the memory occupied by the bootloader if it resides in the flash and must start from
the bootloader section rather than from the application section.
Recommended fuse bits for supported AVR microcontrollers are given in Table 2-2 and fuse bits for supported XMEGA
microcontrollers are given in Table 2-3. The tables list all fuse bits and show the resulting fuse bytes as well.
Fuse bits configuration informs the MCU to start execution from the bootloader section in memory instead of the
applications. On Atmel AVR microcontrollers the bootloader is stored in the flash memory in the same address space as
the application. This reduces the amount of memory available for the application. The fuse bits are also used to specify
the amount of memory exclusively reserved for the bootloader. Bootloader size may also vary depending on the
bootloader type (for example, the OTAU bootloader requires larger memory allocation than a bootloader without OTAU
support).
On XMEGAs, the embedded bootloader is kept in a separate storage, and so it is not needed to specify the size of the
bootloader section (all 256kb of flash are available as the application memory).
JTAGUSERID 0xFF
DVSDON OFF
BOOTRST BOOTLDR
BODACT Disabled
BODPD Disabled
SUT 0ms
WDLOCK OFF
JTAGEN ON
EESAVE OFF
BODLVL 1.6V
FUSEBYTE0 0xFF
FUSEBYTE1 0x00
FUSEBYTE2 0xBF
FUSEBYTE4 0xFE
FUSEBYTE5 0xFF
The embedded bootloader application is provided as a set of pre-compiled firmware images for various configurations
and the source code. The user can immediately start using boot loading by programming devices with the pre-compiled
images. It is also possible to modify the source code of the embedded bootstrap and compile it using the appropriate
toolchain as described in Sections 3.2-3.4 .
Program
In addition to the common bootloader that simply programs application firmware to the flash and EEPROM, embedded
bootloader application may be built to support additional features like Over-the-Air Upgrade (OTAU) applied by BitCloud
applications or RF4CE features. The OTAU bootloader is able to load an application image, which has been received by
the application over the air and saved in an external memory device, and program it into the internal flash memory (see
Section 3.7). RF4CE features are invoked by the application to enable a special type of the Over-the-Air upgrade when
the application image is replaced in memory simultaneously with reception of the new image. For detail refer to Section
3.8.
Application configuration options for embedded bootloader are collected in the configuration.h file. Using this file it is
possible to configure the following parameters:
Serial port interfaces enabled for reception of new firmware image from the host. This are defined separately for
each MCU with the #ifdef sections. For example, enabling only the USART1 port for an Atmel
ATmega128RFA1 MCU is done like this:
#ifdef ATMEGA128RFA1
// Use USART0
#define USE_USART0 0
//#define USE_USART0 1
// Use USART1
//#define USE_USART1 0
#define USE_USART1 1
// Use USB_FIFO
// Use TWI
#define USE_TWIS 0
//#define USE_TWIS 1
#ifdef USE_TWIS
// Use TWID
//#define USE_TWIS_D 0
#define USE_TWIS_D 1
#endif
External flash device used to store the application image during an over-the-air upgrade procedure. This is done
via TYPE_EXTERNAL_MEMORY parameter and is applicable only to configurations with BitCloud OTA feature
enabled. For an overview of BitCloud OTA bootloader and more references see Section 3.7.
For convenience the bootloader package includes precompiled .hex images of the embedded bootloader in most
common configurations as described in Section 1.3.2.
Toolchain Comments
Atmel Studio v6.2 (with GCC compiler) For AVR and Xmega devices only
To compile the bootloader application in Atmel Studio, open witht the Atmel Studio the .atsln project file that
corresponds to the target platform and feature set from the \Embedded_Bootloader_src\as6_projects directory.
Then choose a particular build configuration from the list on the toolbar, and select Build form the Build menu.
To compile the bootloader application in IAR IDE, open with corresponding IAR toolchain the .eww project file from the
\Embedded_Bootloader_src\iar_projects directory. Then choose a particular build configuration that corresponds
to the target platform and feature set and select Rebuild All form the Project menu.
1. After the device is reset, the embedded bootloader waits 200ms on each enabled interface for a
HANDSHAKE_REQ data sequence to arrive. If no HANDSHAKE_REQ is received on none of the interfaces, the
embedded bootloader jumps to the applications entry point in the flash memory.
2. If a HANDSHAKE_REQ sequence is received, bootstrap code sends a HANDSHAKE_CONF sequence over the
same serial interface and expects reception of SREC records one by one.
3. After every valid reception of a SREC record the embedded bootloader responds with an ACK data sequence
over the serial interface.
4. In case of any error during loading process, the embedded bootloader sends a NACK data sequence and then
proceeds to step 1.
As the host side, Atmel Bootloader PC tool performs following actions to conform to the embedded bootloader behavior:
1. The Bootloader PC tool sends a HANDSHAKE_REQ data sequence on specified serial port for 30 seconds with
200ms interval, waiting for a HANDSHAKE_CONF data sequence between transmissions. Any reply except
HANDSHAKE_CONF is ignored.
2. If HANDSHAKE_CONF is received, the PC bootloader starts sending data from the SREC file via the serial link.
Each record of the SREC file is converted to binary representation before sending.
3. For every record sent the host expects an ACK over the serial link as a response. If a NACK sequence is received
or a timeout occurs, the PC bootloader aborts.
Serial data sequences used between the device and the host while boot loading:
HANDSHAKE_REQ: 0xB2 0xA5 0x65 0x4B
HANDSHAKE_CONF: 0x69 0xD3 0x0D 0x26
ACK: 0x4D 0x5A 0x9A 0xB4
NACK: 0x2D 0x59 0x5A 0xB2
Reset
Waiting for
HANDSHAKE_REQ
Is HANDSHAKE_REQ
received?
Yes
Send HANDSHAKE_CONF
Read next
record from
UART
No
Is received record Send NACK
No
valid? data sequence
No
Yes
Write record
data to flash and
send ACK data
sequence
Yes
Jump to
program entry
point
Embedded bootloader for SAM3S uses Device Firmware Upgrade (DFU) standard. A DFU component should be
included in the application (see Section 3.6.2.1). The procedure of uploading a new firmware image does not change for
the user (see Section 4.1.2). The remaining part of this section describes implementation details of SAM3S embedded
bootloader and is intended for users who will possibly modify the embedded bootloader code.
In order for the embedded bootloader to work correctly it must receive control first after reset to be able to communicate
with the host software and upload a new device image before the application code is executed.
To achieve this, the embedded bootloader for SAM3S, during uploading, reassigns the reset vector value (the MCU
component that stores the address to start from reset), setting it to its own starting address. Thus the MCU will always
start execution from the embedded bootloader, which, in turn, will pass control to the application section upon
completion.
To prevent serial port reassignment when using SAM3S, the USB Device Firmware Upgrade components based on [11]
should be used. DFU components should be included in both the embedded bootloader and the application code (see
Section 3.6.1). The DFU component inserted in the application code should always be enabled along with other
application components. Upon receiving a command indicating that a new firmware image is ready, it writes a special
byte into the program memory and initiates a device reset. After reset, the DFU component included in the embedded
bootloader checks this status byte and enters the new firmware upload mode.
If the embedded bootloader is the only image loaded in the program memory, it will constantly be ready to receive and
upload a new firmware image from the host.
To program a device that contains the embedded bootloader with DFU support (such as the embedded bootloader for
Atmel SAM3S) you may also use the third-party software, since DFU components provided with this software package
closely adhere to the DFU standard.
1
A dedicated bootloader ROM section is included by individual manufactures for their individual use.
To load an image using bootloader into such device, connect JTAGs PB7 pin to ground and reset the device. On an
Atmel SAM3S USB stick, these are the first two pins of the JTAG port and so can be connected with a jumper wire.
The OTAU bootloader can also be configured to program an application image received via a serial interface to the flash
as a common serial embedded bootloader. But it has more functions required for OTAU support, such as driver to an
external flash device, image decryption, etc.
Atmel BitCloud PC Tool (described in Chapter 4) has a BitCloud OTAU tab that can be used to OTAU programming of a
remote node.
For further details on the topic of OTAU in BitCloud ZigBee PRO refer to [4] and [8].
Another use of the Bootloader PC tool is initiating Over-the-Air Upgrade. This document does not cover this usage of the
tool for this purpose. A complete guide to Over-the-Air Upgrade of ZigBee networks is given in [8].
As a firmware image the Bootloader PC tool requires a file in the Motorola S-record hexadecimal format, also known as
SREC or S19 format. Such file names have the .srec extension and can contain both flash memory and EEPROM
images.
For ARM just replace the name of the AVR tool with arm-elf-objcopy.exe. Note that this tool takes an image in the
.elf format as input.
can be used to load C:\work\SerialNet_ZigBit_Rf230B.srec image via port enumerated as COM4. Figure 4-2
shows a screenshot with an example of successful firmware upload using command line control.
Note: With the command line COM-port settings will be automatically used as given in Table 2-1 and cannot be changed.
Besides, when the -e <eeprom_size> option is specified the EEPROM section is cleared.
bootloader -h
Figure 4-2. Loading application firmware using command line control of PC Bootloader tool.
DISCLAIMER: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property
right is granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND CONDITIONS OF SALES LOCATED ON
THE ATMEL WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS
PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN
NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION,
DAMAGES FOR LOSS AND PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN
IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the
contents of this document and reserves the right to make changes to specifications and products descriptions at any time without notice. Atmel does not make any commitment to
update the information contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and shall not be used in, automotive applications. Atmel products
are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.
SAFETY-CRITICAL, MILITARY, AND AUTOMOTIVE APPLICATIONS DISCLAIMER: Atmel products are not designed for and will not be used in connection with any applications
where the failure of such products would reasonably be expected to result in significant personal injury or death (Safety-Critical Applications) without an Atmel officer's specific
written consent. Safety-Critical Applications include, without limitation, life support devices and systems, equipment or systems for the operation of nuclear facilities and weapons
systems. Atmel products are not designed nor intended for use in military or aerospace applications or environments unless specifically designated by Atmel as military-grade. Atmel
Atmel AVR2054: Serial Bootloader User Guide [APPLICATION NOTE]
products are not designed nor intended for use in automotive applications unless specifically designated by Atmel as automotive-grade.
23
8390DWIRELESS03/2015