10 Atmel AVR2054
8390B-AVR-12/11
3.2.1 Changing the reset vector
The Atmel SAM3S MCU does not contain a special bootloader section in the flash
memory1. The fuse settings do not indicate whether to start execution from the
application section or from the bootloader section and where this section starts. So if
the bootloader code is first programmed at the end of the flash memory and then the
application code is loaded into the remaining part of the flash memory, the MCU will
start code execution from the last loaded code after reset (that is, the application
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.
3.2.2 DFU impact
Another feature involves notifying embedded bootloader that the PC tool is ready to
transfer a new firmware image to the device. For the Atmel AVR and XMEGA MCUs
the device must be reset before the new software upload can take place. Upon reset
the COM port assigned to the device on the PC is still enabled. The bootloader
receives control and waits for the uploading requests from the PC tool. However, to
reset a USB stick with SAM3S it should be removed and re-attached to the PC. This
may cause the PC to assign a different COM port to the device and stop the serial
communication with the device.
To prevent serial port reassignment when using SAM3S, the USB Device Firmware
Upgrade components based on [5] should be used. DFU components should be
included in both the embedded bootloader and the application code (see Section
3.2.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.
3.2.2.1 Adding DFU support to an application
The DFU class for the application is implemented on top of the USB driver. Set the
DFU_SUPPORT parameter to 1 in configuration.h file to enable DFU support:
#define DFU_SUPPORT 1
3.2.2.2 Not-responding application or absent DFU
The application loaded to the flash by embedded bootloader may not include a DFU
component as well as any special code to deal with PC tool’s requests. In other cases
1A dedicated bootloader ROM section is included by individual manufactures for their
individual use.
