Basic Bootloader For AVR MCU DA Family DS00003341C
Basic Bootloader For AVR MCU DA Family DS00003341C
Introduction
Authors: Cristian Pop, Iustinian Bujor, Microchip Technology Inc.
This application note describes how the AVR® DA MCU family of microcontrollers (MCUs) can use self-programming.
This enables the user to download application code into Flash without the need for an external programmer. The
example application is using the AVR128DA48 Curiosity Nano Board to communicate through the UART interface
with a PC running a Python™ script.
To avoid transferring unuseful data, the current implementation includes a configuration section at the beginning of
the image that will inform the bootloader about the features of the new image. Included in this information is the size
of the code, so only the useful data will be transferred in the memory, thus significantly reducing the upload time.
The provided example bootloader application and Python™ scripts are suitable as starting points for custom
bootloader applications. Each of the repositories below provide an example of bootloader and host application, for
both MPLAB X and Atmel Studio environments.
Table of Contents
Introduction.....................................................................................................................................................1
1. Relevant Devices.................................................................................................................................... 3
1.1. AVR® DA Family Overview.......................................................................................................... 3
2. Device Self-Programming....................................................................................................................... 4
2.1. What has Changed.......................................................................................................................4
2.2. Bootloader Code, Application Code, and Application Data Sections........................................... 5
2.3. Flash Programming...................................................................................................................... 8
4. Host Application.................................................................................................................................... 16
4.1. Application Code Format............................................................................................................16
4.2. Python™ Scripts Operation........................................................................................................ 16
5. Expanding Functionality........................................................................................................................ 19
5.1. Entering Bootloader Mode..........................................................................................................19
5.2. Communication Interfaces .........................................................................................................19
5.3. Interrupts.................................................................................................................................... 19
5.4. Data Integrity.............................................................................................................................. 19
6. References............................................................................................................................................21
7. Revision History.................................................................................................................................... 22
Customer Support........................................................................................................................................ 23
Legal Notice................................................................................................................................................. 23
Trademarks.................................................................................................................................................. 24
1. Relevant Devices
This chapter lists the relevant devices for this document.
Flash
Pins
28 32 48 64
Devices with different Flash memory size typically also have different SRAM.
2. Device Self-Programming
On the AVR DA devices, the access to Flash memory and EEPROM has been changed from the previous
megaAVR® and tinyAVR® devices. This means that the existing code for writing to Flash and EEPROM on other
devices must be modified to function properly on AVR DA devices. This section describes what has changed and
how to adapt the code to these changes.
LOCK 0
0x1040-0x104F
FUSE 0x1050-0x107F
USERROW 0x1080-0x10FF
SIGROW 0x1100-0x13FF
0x1600-0x3FFF
(Reserved)
SRAM 0x4000-0x7FFF
0x18000
16 KB
In-System Reprogrammable
Flash 0x8000-0xFFFF
32 KB
0x1FFFF
32KB
The size of the In-System Reprogrammable Flash in the data space is 32 KB. For devices with Flash memory size
greater than 32 KB, the Flash memory is divided into blocks of 32 KB. Those blocks are mapped into the data space
using the FLMAP bit field in the NVMCTRL.CTRLB register:
Another major difference between the tinyAVR® and megaAVR® devices compared to the AVR DA devices is the
Flash write access. On the previous tinyAVR and megaAVR devices, the Flash writes are performed through a page
buffer, while on the AVR DA devices the writes are done directly to Flash memory locations using ST/SPM
instructions.
Note: To write a Flash location, that location must be blank (0xFF), otherwise the result will be an AND between the
existing value and the new one.
APPCODE
APPEND: (CODESIZE*512) - 1
APPDATA
FLASHEND
For security reasons, it is not possible to write to the section of Flash the code is currently executing from. Code
writing to the APPCODE section needs to be executing from the BOOT section, and code writing to the APPDATA
section must be executing from either the BOOT section or the APPCODE section.
The fuses define the size of each of the respective sections. There are BOOTSIZE and CODESIZE fuses that control
this. The following table shows how these fuses configure the sections.
Table 2-1. Setting Up Flash Sections
A good way of making sure these fuses are set up as expected on a device is to use the FUSES macro in the
bootloader code project. It can be found in fuse.h, which is included by io.h:
#include <avr/io.h>
FUSES = {
.OSCCFG = CLKSEL_OSCHF_gc, // High frequency oscillator selected
.SYSCFG0 = CRCSRC_NOCRC_gc | RSTPINCFG_GPIO_gc, // No CRC enabled, RST pin in GPIO mode
.SYSCFG1 = SUT_64MS_gc, // Start-up time 64 ms
.BOOTSIZE = 0x02, // BOOT size = 0x02 * 512 bytes = 1024 bytes
.CODESIZE = 0x00 // All remaining Flash used as App code
};
Note: All fuse bytes in the struct must be configured, not only BOOTSIZE and CODESIZE. This is because an
omitted fuse byte will be set to 0x00 and may cause an unwanted configuration.
By including this macro in the project, the fuse settings are included in compiled files. To write the fuse setting at the
same time as the Flash, the *.elf file must be selected instead of the *.hex file during device programming.
In Atmel Studio 7.0, another method is to use the Production File tab from the Device Programming.
Figure 2-4. Writing Fuses using Production File Tab, Atmel Studio 7.0
In Atmel Studio 7.0, the fuses can also be configured using Device Programing (Ctrl +Shift + P) - Fuses, as shown in
the figure below.
Figure 2-5. Configure BOOTSIZE and CODESIZE Fuses, Atmel Studio 7.0
Note: A change from one command to another must always go through the No Command (NOCMD) or No Operation
(NOOP). Otherwise, the Command Collision error will be set in the ERROR bit field in the NVMCTRL.STATUS register
and the current command will not be executed.
The write operation is initiated by writing a Flash Write Enable (FLWR) command into the NVMCTRL.CTRLA register.
After this command, multiple byte writes are allowed to the selected page locations, as long as no other command is
written into the NVMCTRL.CTRLA register.
As the function is not called using CALL/RET instructions but entered at start-up, the compiler is instructed by the
naked attribute to omit the function prologue and epilogue. See the AVR GCC documentation for more details.
With AVR GCC, the standard start files are disabled by setting the linker flag -nostartfiles when compiling the
project.
In Atmel Studio 7.0 this can be found in Project Properties (Alt+F7) → Toolchain → AVR/GNU Linker → General, as
shown in the figure below.
Figure 3-1. Disabling Standard Files, Atmel Studio 7.0
In MPLAB X, this can be found in File → Project Properties → Conf → Avr GCC (Global Options) → avr-ld →
General, as shown in the figure below.
Figure 3-2. Disabling Standard Files, MPLAB® X
Note:
• The bootloader project needs to include fuse settings. Refer to 2.2 Bootloader Code, Application Code, and
Application Data Sections for more details.
• The generated code must not exceed the BOOT area as resulted from the fuse settings.
-Wl,--section-start=.text=0x200
In AtmelStudio 7.0, the relocation can be done in Project Properties (Alt+F7) → Toolchain → AVR/GNU Linker →
Memory Settings by adding .text=0x200 to the FLASH segment, as shown in the figure below.
In MPLAB X, the relocation can be done in File → Project Properties→ Conf → Avr GCC → avr-ld → Memory
Settings by adding .text=0x200 to the FLASH segment, as shown in the figure below.
Figure 3-4. Memory Settings, MPLAB® X
typedef struct
{
uint32_t start_mark;
uint32_t start_address;
uint32_t memory_size;
uint8_t reserved[116];
}application_code_info;
The wait_mark contains the “INFO” tag; the start_address contains the user application start address; the
memory_size contains the image size (number of bytes). The next 116 bytes are reserved for future improvements.
After receiving image information, an additional tag (“STX0”) is expected at the end of the information buffer, then the
bootloader will start writing data to the APPCODE section.
The bootloader expects that the application code is received byte-by-byte in incremental order of Flash address.
When a new page boundary is reached, this is first erased and prepared for the next writes. When the number of
bytes indicated in the image information buffer is reached, the bootloader will execute a software Reset and will start
the new application.
The following image shows the flow diagram of the bootloader operation:
START
YES
Enable UART
Software Reset
UART Read Byte
NO YES
All Bytes Received?
4. Host Application
In a bootloader context, the host is the system responsible for sending the application code to the device. This is
usually a computer or a CPU that can be connected to the target device to perform the application code upgrade or a
CPU host on the same circuit board.
There are very few limitations on how to make a host application, if the user is able to communicate with the target
device. The simplest host applications have only a basic command line interface, while more complex apps have
Graphical User Interfaces with several layers of security and advanced configuration settings.
Over-The-Air (OTA) programming is also possible if the device has wireless connectivity. This makes it easier to add
software upgrade features from a smartphone application, or other ways of upgrading many devices without having to
physically connect each device to a computer or a programmer.
START
Send Byte
Byte Echoed NO
Report Failure
Correctly?
YES
NO Reached End
of Byte Array?
YES
Note: The Virtual COM port is connected to the UART pins (PC0-TxD and PC1-RxD) on the AVR128DA48
device on the board.
4. Baud rate used. The default baud rate used by this example bootloader is 9600.
To run the script for an AVR128DA48 Curiosity Nano connected to port COM10 and of a 128 KB Flash size, the
following format must be used:
Note: Make sure to put the device in Bootloader mode before starting the script. This is done by pressing SW0 while
powering or resetting the AVR128DA48 Curiosity Nano board.
5. Expanding Functionality
The example bootloader is a simple implementation of a bootloader containing only basic functionality. However, this
implementation can be extended in several ways. This section introduces some of the possible extensions.
All AVR DA family have hardware UART, TWI, and SPI available for serial communication, and the I/O pins can also
be used for custom digital protocols.
5.3 Interrupts
The current implementation of the bootloader does not use interrupts. If the bootloader is more complex, it can
require usage of interrupts.
After Reset, the default vector table location is at the start of the APPCODE section. The peripheral interrupts can be
used in the bootloader code by relocating the interrupt vector table at the start of the BOOT section. That is done by
setting the IVSEL bit in the CPUINT.CTRLA register:
void relocating_vector_table_example(void)
{
// Set the Interrupt Vector Select bit,
// read-modify-write to preserve other configured bits
_PROTECTED_WRITE(CPUINT.CTRLA, (CPUINT.CTRLA | CPUINT_IVSEL_bm));
//Enable global interrupts
sei();
}
Note:
• If interrupts are used in the bootloader, the linker directive -nostartfiles must not be used.
• If the interrupt vector location was changed to the start of the BOOT section, it needs to be changed back to the
start of the APPCODE section before entering the main application.
5.4.1 Confidentiality
Cryptographic countermeasures might be necessary to ensure that a product and its application code are not cloned,
counterfeited or tampered with. Implementing CryptoAuthentication™ in the bootloader will ensure that only legitimate
code can be transferred between the host and the device.
For more information, visit the Microchip CryptoAuthentication Site.
6. References
1. AVR128DA28/32/48/64 Preliminary Data Sheet.
2. AVR128DA48 Curiosity Nano User’s Guide.
7. Revision History
Doc. Rev. Date Comments
C 05/2020 Updated AVR® MCU DA (AVR-DA) to AVR® DA MCU, and AVR-DA to AVR DA, per latest
trademarking.
Customer Support
Users of Microchip products can receive assistance through several channels:
• Distributor or Representative
• Local Sales Office
• Embedded Solutions Engineer (ESE)
• Technical Support
Customers should contact their distributor, representative or ESE for support. Local sales offices are also available to
help customers. A listing of sales offices and locations is included in this document.
Technical support is available through the website at: http://www.microchip.com/support
Legal Notice
Information contained in this publication regarding device applications and the like is provided only for your
convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with
Trademarks
The Microchip name and logo, the Microchip logo, Adaptec, AnyRate, AVR, AVR logo, AVR Freaks, BesTime,
BitCloud, chipKIT, chipKIT logo, CryptoMemory, CryptoRF, dsPIC, FlashFlex, flexPWR, HELDO, IGLOO, JukeBlox,
KeeLoq, Kleer, LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, Microsemi logo, MOST,
MOST logo, MPLAB, OptoLyzer, PackeTime, PIC, picoPower, PICSTART, PIC32 logo, PolarFire, Prochip Designer,
QTouch, SAM-BA, SenGenuity, SpyNIC, SST, SST Logo, SuperFlash, Symmetricom, SyncServer, Tachyon,
TempTrackr, TimeSource, tinyAVR, UNI/O, Vectron, and XMEGA are registered trademarks of Microchip Technology
Incorporated in the U.S.A. and other countries.
APT, ClockWorks, The Embedded Control Solutions Company, EtherSynch, FlashTec, Hyper Speed Control,
HyperLight Load, IntelliMOS, Libero, motorBench, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus,
ProASIC Plus logo, Quiet-Wire, SmartFusion, SyncWorld, Temux, TimeCesium, TimeHub, TimePictra, TimeProvider,
Vite, WinPath, and ZL are registered trademarks of Microchip Technology Incorporated in the U.S.A.
Adjacent Key Suppression, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, BlueSky, BodyCom,
CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM,
dsPICDEM.net, Dynamic Average Matching, DAM, ECAN, EtherGREEN, In-Circuit Serial Programming, ICSP,
INICnet, Inter-Chip Connectivity, JitterBlocker, KleerNet, KleerNet logo, memBrain, Mindi, MiWi, MPASM, MPF,
MPLAB Certified logo, MPLIB, MPLINK, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM,
PICDEM.net, PICkit, PICtail, PowerSmart, PureSilicon, QMatrix, REAL ICE, Ripple Blocker, SAM-ICE, Serial Quad
I/O, SMART-I.S., SQI, SuperSwitcher, SuperSwitcher II, Total Endurance, TSHARC, USBCheck, VariSense,
ViewSpan, WiperLock, Wireless DNA, and ZENA are trademarks of Microchip Technology Incorporated in the U.S.A.
and other countries.
SQTP is a service mark of Microchip Technology Incorporated in the U.S.A.
The Adaptec logo, Frequency on Demand, Silicon Storage Technology, and Symmcom are registered trademarks of
Microchip Technology Inc. in other countries.
GestIC is a registered trademark of Microchip Technology Germany II GmbH & Co. KG, a subsidiary of Microchip
Technology Inc., in other countries.
All other trademarks mentioned herein are property of their respective companies.
© 2020, Microchip Technology Incorporated, Printed in the U.S.A., All Rights Reserved.
ISBN: 978-1-5224-6063-3