Hello: I'm looking for a Bootloader for SAMD10 and reading 'Atmel AVR2054: Serial Bootloader User Guide' which provides examples for different AVR and SAMR21 parts, there are some things not very clear to me. According the Application Note, the bootloader firmware is flashed in the device, and after reset it executes and connect to a PC program to download the user application.
The downloaded user application is then flashed in the device (in a higher address space in flash) and executed once this process is finished. However, if the user application is not starting at flash address 0x00, then it should be linked to start in a different address.
But there is no mention about this.I'm wondering how this really works. I would appreciate any comment on this.
AVR Bootloader and Programmer AVR Bootloader and Programmer Note 15 February 2014: This project is workable but I'm no longer developing very much for AVR. The best alternative option is the by A. Maccione (see below) which covers both PIC and AVR extensively, although development has slowed not progressed since April 2014. Note 14 February 2016: Some additional AVR work for the XBee project has prompted upgrading the project to QT5.
For the AVR microcontrollers, control of program loading to the FLASH memory, and manipulating of the fuse and lock bits for configuring certain features of the microcontroller, can be simply done through a PC parallel port programmer (see the CDK4AVR tools and references). Many of the AVRs provide a small section of FLASH memory with capabilities that allow it to modify its own FLASH memory. This is sometimes referred to as the bootblock.
It normally resides in the top of FLASH memory and can be set, through fuse bits, to different sizes, typically 256 bytes to 4K bytes. The microcontroller can also be configured through a fuse bit so that after a reset, a jump directly to the bootloader section can be forced, rather than the usual jump to address 0. For microcontrollers that have a UART, programming can be done through a PC serial port using the bootloader. This makes programming even simpler, particularly for PCs and laptops that do not have a parallel port. For those without a serial port, a commercially available USB to serial adaptor can be used.
Beware: there are some very low cost adaptors that just don't work. Some tools developed for AVR programming are presented here. Similar tools are available in both open source and commercial versions, including bootloaders, PC programming control applications and hardware programmers. The tools described here were constructed to add some specific features. Code and PCB files for this project can be found on.
AVR Bootloader Atmel's application note describes a bootloader for microcontrollers that have a separate bootloader section, that uses the UART to communicate FLASH programming instructions. Atmel also provides some in C that allows the programming of FLASH, EEPROM, and lock bits. Note that the AVR109 bootloader does not support the programming of fuses, which for safety cannot be changed by the self programming features of the AVR. The communication protocol used is compatible with the AVRPROG programming software. After loading this into the bootloader section, the device can be configured so that on reset the program counter starts at the bootloader, and programmer software can program the FLASH memory. The ATMEL example bootloader program proposes the use of a port pin on the microcontroller to signal whether to execute the bootloader program or to jump directly to the application. This allows a user to set a jumper on the microcontroller card that pulls the pin low when programming of the FLASH is needed.
The adaptation of this code described here keeps it almost unchanged in the interests of compatibility. By disabling the port pin test and excluding the EEPROM programming section and the AVRPROG compatibility section, the code will fit neatly into a 1K block of the bootloader FLASH section on ATMega48/ATMega88/ATMega168 AVRs. Disabling the port pin test means that on reset the microcontroller always ends up in the bootloader program (if the appropriate fuse bit has been set), and must be explicitly sent out again with a bootloader exit command. For the moment this is acceptable as the device will normally operate while connected to a PC serial port. For standalone operation a pin will need to be made available to implement the port pin test, or the appropriate fuse bit programmed to start the device on reset at location 0. In the latter case the application firmware will need to manage a jump to the bootloader when firmware update is required.
Although the AVR109 code is freely available, Atmel has not released it under a clear open source licence. As such the modified code will not be provided here. Writing another bootloader is probably not worthwhile as it turns out to be difficult to produce more compact C code than that provided in Atmel's sample.
There are assembler versions of the bootloader available (e.g. That by ) that take up less space, however assembler code is less readable and potentially less portable than a higher level lenguage. The changes made to the code AVR109 are quite simple, most being corrections to perceived minor deficiencies:. Modify the block read and block write functions to add a compiler directive REMOVEFLASHBYTESUPPORT around the FLASH programming section (be careful of if-else clauses).
Modify the block read and block write functions to add a compiler directive REMOVEEEPROMBYTESUPPORT around the EEPROM programming section (be extra careful of if-else clauses). Move the 'E' command outside of REMOVEAVRPROGSUPPORT so that we can get out of the bootloader into the application. Add a compiler directive REMOVEPROGPINTEST around the the port pin check section. This must also be added at the end of the 'for' loop where the jump to the application is made. The preprocessor.sh script can be modified to generate an all-encompassing defines.h file covering all microcontroller types, rather than using the suggested cut and paste system. This makes use of the availability of the MMCU variable in avr-gcc to identify the microcontroller type. To allow the application to execute a jump into the bootloader I used an instruction to enable the Watchdog Timer on a very short timeout to force the MCU to be reset, the fuses being set to send it to the bootloader section.
Custom Boot Loader Pc
There seemed to be a problem either with the (old) compiler or the AVR that a long jump was not possible. This has the advantage that it does not require the exact address of the bootloader to be set in the code, but of course prevents the Watchdog Timer from being used for other purposes. I then added a call to wdtdisable (from the wdt library in avr-lib) to disable the Watchdog Timer at the start of the bootloader. This may depend on the optimization used by the compiler. For some time the CDK4AVR toolset produced more compact code than avr-gcc. This may have now changed.
Advanced C coding and optimization techniques may also reduce the code size. Programmer GUI Application To support the above bootloader a GUI programmer for Linux was written in QT4/5 and C (see the. This provides basic hex file load and verify, download, and some fuse/lock bit programming for selected devices (do not fiddle with these settings until you have carefully read and understood the datasheets). The programmer opens a serial port (which may need to be changed to match the target system) and synchronizes with the device using no parity, 1 stop bit and 8 bit data.
A character 0xDD is sent and the character received back from the device is checked for either a 0xDD or a '?' The latter indicates that the bootloader may have been found. If the bootloader is not present the device will probably just reset itself.
If neither character is received, the baud rate is cyclically changed through a set of standard rates for a couple of cycles. When the program has synchronized with the device, it gathers a swag of information and presents the above window. Note that unlike avrdude it assumes that a valid and working AVR device is connected. An Intel hex file can be opened and will be immediately read and uploaded to the application area of the device FLASH. The default baud rate to start with is 38400 baud. Theklub-17 v7.5 full setup.exe (782,46 ). If this does not match that of the device, then the program will cycle through standard baud rates between 1200 and 115200 baud until it finds the correct one.
Free Pc Tool
This process can be sped up by changing the default baud rate to match that of the bootloader. The program allows for turning off block mode, and also allows verification without programming and vice-versa. Autoaddress currently does nothing so it is disabled. There is a chip erase feature provided: normally the E button is invisible until the checkbox has been selected to minimize accidental erasures. An erase may be necessary if the lock bits have been set incorrectly. This requires an external programmer.
A bootloader will not reset the lock bits. The GUI program relies on inserting delays into the serial communications to adapt the speed of the PC to the bootloader or serial programmer. Also when waiting for a response from the programmer, the program will timeout if this takes too long. If problems are experienced while programming or verifying, it may be that these delays need to be increased. This is particularly the case if the clock speed used with the MCU is low.
The GUI program was tested with 8MHz MCU clock frequencies and 38400 baud communications. Additional sections have been added to enable fuse and lock bits to be read and changed for a limited number of devices. The program uses the device signature bytes to identify the device uniquely, and the appropriate window is invoked.
This has only been partly tested so use it at your own risk. The program also supports a limited command line feature to allow a much faster non-GUI usage during intensive AVR development and testing work.