AVR ATMega Bootloader Version AVR Bootloader (0.03) 0. INTRODUCTION Purpose References Revision history...

Transcription

1 AVR Bootloader (0.03) Table of contents: 0. INTRODUCTION Purpose References Revision history Terms and definitions REQUIREMENT IMPLEMENTATION Location of files (CVS) Initial comments Last comments Operation & Program Flow Main Functions Program Flow Comments (on code & functionality) General comments Versioning AVR Patch file (avrpatch.h) Timer (start & stop) <All function should be here > #Defines description To Do s... 12

2 2.10 Makefile SIMPLEMAIN SIMPLE DEMO APPLICATION OPERATION WITH PC Figures Figure 1 Program Flow... 8 Figure 2 Common functions groups... 9 Figure 3 Debug functions group... 9 Figure 4 #define list Figure 5 Bootloader: make help Tables Table 0-1 Revision History... 4

3 0. Introduction This document describes common requirements for a bootloader/bootmonitor. Some implementation relations, and finally examples on how to use it in real life. The bootmanager is specifically made for the AVR series (ATMega-xxx) from ATMEL. But the principles, and nature could easily be portable for another CPU & hardware/flash s. 0.1 Purpose The purpose is that any developer, with this document at hand, is capable of understanding the implementation of the bootloader. Contents: Chapter 0 General information Chapter 1 Requirements & Ideas (whats in, whats out) Chapter 2 Implementation Chapter 3 SimpleMain Simple Demo Application Chapter 4 Operation with PC Usage uploading application with a PC. 0.2 References References to other documents (eg. Atmel, Gcc, Winavr, ATMega etc). Table 1 Reference # <External doc, revision, section & page, description> [1] [2] Xxx 0.3 Revision history Date yyyy-mm-dd Revision Section/page Description Initial version by johnk

4 Table 0-1 Revision History 0.4 Terms and definitions Terms and their definitions here Table 2 Terms - description Term Meaning ATMEGA CPU from ATMEL ATMEL Company AVR Atmel CPU BL Bootloader CPU Central Processor Unit (U should know this) CRC Checksum (8bit, 16 bit or 32 and even 64/128..) CVS Concurrent Versioning System (for managing versions on software) DOS Old traditional Disk-Operation-System PIN I/O pin on CPU UART serial port XModem Protocol for transferring package 128 or 1K at the time.

5 1. Requirement This section lists the known requirements for the Bootloader. 1. Basically the bootloader should be able to re-flash the internal FLASH section on the AVR µprocessor. But this might be used for external FLASHS s as well as many other CPU s too 2. The CPU supported should be the ones in the AVR family 2.1. ATMega-32, 2.2. ATMega-64, 2.3. ATMega-128, 2.4. ATMega-256 (later on) All above 64K - requires support for RAMPZ (handling of upper memory >64K). 3. The bootloader is design for using XModem protocol 128-byte packet size. Since this is the most used protocol for uploading data using serial interfaces! 3.1. This also means compatibility with the MS HyperTerminal (available on many desktops now a days)! 4. Uploading is done using serial communication the UART 4.1. Speed is specified by your PC and what s defined in the BM(Bootmonitor). 5. CRC should be verified on the transmitted packets (actual part of XModem). 6. CRC should be calculated within the programmed application (actual requirements is TBD). 7. We need to make sure the power cycle is OK. And that the application (which the execution is transferred to) has ability available for checking the application program area. 8. As little as possible dependency should be implemented between the application code and the Bootloader code! Dependencies are hw and sw. We need to know if the code section is correct uploaded, if its correctly flashed and so on 8.1. A single byte in EEPROM specifies the state on the programmed code: xFF - Not flashed x55 - Flashed and ready2run (set by BL) xAA - Flashed and checked (set by Appl) xelse - Unspecified state (when flash is erased). 9. Code should fit into the available boot section on the AVR (4K or less ) 10. Code should compatible for production usage eg. pre-mounting CPU. 11. Internal flags/fuses should support automatic check and start up of the bootloader This means bootloader is always started after power up & reset Some sort of check (a pin) should be added, so we know whether bootloader or the application should start. (Actually bootloader is always initially started). 12. xxx

6 2. Implementation This section describes the actual idea and actual implementation of the bootloader. 2.1 Location of files (CVS) This depends on how you got your image If downloaded, then you have received two files. Bootloader (the actual boot loader code) Simplemain (a small project for testing the bootloader) <the demo illustrates a SDK500 kit from ATMEL > 2.2 Initial comments All the code is based on open source from various projects, I have found on the web. Take a look at the for starters. Some projects were using other CPU (Tiny), others were not adopting +64K support. Others again don t support XModem but a much more advance debugging facilities (we defiantly shouldn t use here). So after some cut n past this is what we got after a couple of weeks work! I have found a Xmodem interface, merged with 64K bootloader, and upgraded this to 128K version. The GCC have had some problem I had to fight with, and RAMPZ (going above 64K) was also a minor problem, since the standard library (using at that time) didn t support the required stuff. Further more did the JTAG-ICE I m using not support any debugging of the bootloader section 2.3 Last comments The project could be much more optimized regarding code size, since lot of debugging functionality is left in there. I have removed some of it, by using various #define, and other is just #ifdef d out! I have had great use of the spare UART, and do use this for detailed debugging. This should be fairly easy to activate again, if you stumble into any problems. Future: big clean up should remove lot of the unwanted parts. Future: should/could remove many functions, which actually just gives some abstractions to the initialization or a given setting. - UART initialization

7 For a really tight version, optimizing interrupt handlers and much more (very much) come to my mind

8 2.4 Operation & Program Flow Starting bootloader Power On PIN Status is? ~5 sec In BM Requesting new flash loading? No 3 sec Yes - Purge UART RX/TX Send SignOn - Clear Flash - Sending Sign On Message ~5 sec Run Application 3 sec Send C 3 sec - Send C (wait max 3 sec) - Await s XModem pckt from PC Send C Got first pckt Receiving - Quick Flashing Green LED receiving data packets. - When pckt received - Flash it! Done! Got all packet s Done transmitting All these activities are related to a nonedebug version! Flashhing ~2.5 sec Flashing Red/Green LED s 6 time Activating debugging revival much more capabilities Await Reset Press Reset button! Figure 1 Program Flow

9 2.5 Main Functions AVR ATMega Bootloader Version 0.03 The primary functions all located in the same file are listed here BM System Timer s UART XModem GPIO Flash EEPRO Platform Init Start & Stop IRQ Init LED Ctrl Clear Page Write Address Call- Application Call- Application Timer init SendChar SendStr Uart init Uart Flush Receive Packet Validate Packet Request Packet Timeout Handler Program Page Set Flash Status Get Flash Status Read Address Figure 2 Common functions groups PrintF Macro s Hex8bit PrintStr SwapUA Hex16bit Print-Predefind Dec16bit Figure 3 Debug functions group 2.6 Program Flow The actual program is more or less described in the Figure 1 Program Flow.

10 Everything starts in main(), where we starts with detecting the state on a EnableBootloader-Mode - PIN (if this indicate we should boot load). If TRUE, then the bootloader continues, otherwise we jump to the application code part! If bootloader is activated, we send out sign on msg s (if activated), then flush the rx uart on the XModem port. After a 3 sec timeout, we send a C indicating we are ready for the first packet (XModem). The flash code is marked Unknown (in EEPROM). Now we await the first packet. When the packet is received, we calculate the CRC, and sends with ack. A temporary buffer holding data-to-be-flashed is cleared, then filled with the data just received. We received XModem 128 bytes at the time, but needs 256 for programming the flash! When the buffer is full (255 bytes) the flash section is erased, then programmed with the data from the temporary buffer. Make some counter update - local, and total byte received.!!! OBS!!! using XModem protocol, programming a 256 byte sector, with less than a full (actually 2 * 128 byte) XModem packet, seams to put 0x1A, and not 0xFF in the gap of the last XModem packet. When all bytes are received we update the EEPROM value with a code indicating ApplicationReady2Run. Flash s the LED, and jumps to the reset section. Actually the newly loaded application. 2.7 Comments (on code & functionality) General comments Since we normally have the same hardware arrangement in bootmode, as in the application mode, I have shared various definitions file amongst the application and the BootManager. Having exact the same HW platform (surprise ) as on the application part, I have chosen to import lot of defines and settings from here. This means port I/O and eg. Uart settings are copied to make a faster solution. But also files like data types (inttypes.h) Versioning The version string given by CVS is used for handling and printing the current version number! This is stored in VERSION_STRING

11 2.7.3 AVR Patch file (avrpatch.h) AVR ATMega Bootloader Version 0.03 They have mangled with the system lib s, and I were using old functions, which was removed in never releases. To maintain compatibility (at functional level), I have added a avrpatch.h file. In this file I have put the macros and function no longer supported on the standard system. This is good to know if you are planning on updating WINAVR tool chain (compiler, lib s etc)! <if it aint broken why fix it > Timer (start & stop) Timer management is done by setting a pre-defined value in a timer register, which counts down in an 1 ms interrupt. When the value in the register is 0, we sets a flag indicating timeout. This flag is regularly polled before the timed-out action is executed. Very simple, very efficient for a small none-rtos system <All function should be here > <empty but functional description could be listed here > 2.8 #Defines description The following defines (and some more of cause) are configuring the system. Most of the defines are located in the bootloader.c, others are located in platform.h #define Meaning _STATIC_ Activating this seams to reduce the bin file (?) HALT_ON_ERROR ENABLE_SIGNON_BOOTLOADER ENABLE_SIGNOFF_BOOTLOADER ENABLE_NOT_IN_BOOTLOADER_MODE SEND_OUT_INIT_STRING_AT_9600 CALC_FLASH_CSUM USE_UART_0 USE_UART_1 This would stop the CPU instead for eg. jumping to the loaded application, to the BL main and so on Put out a sign-on string on the active Uart (XModem) Put out a sign-off string on the active Uart (XModem) Put out a string - when the bootloader isn't active/running This is done when control is passed to the application main() Send out a indicating shifting to other baud rate (115K2) Activate this to perform a CSUM calculation on the flashed code. (This is not working yet!!!) Activate code and handling for uart0 Activate code and handling for uart1 XMODEM_UART Specify which Uart to use for the XModem part (0 or 1) AVR_ENHANCED Needed for activating advanced functions in the libc ACTIVATE_DEBUG Generally debug output should always be on "the-other" Uart - that'll be opposite of XMODEM_UART Activate debugging code section Need this for any print s related to debugging Introduced for having a small-optimized XModem & Uart loader (hmmm... not there yet) Set this flag for actually perform flashing FLASH_PROGRAMMING _B4096, _B2048, _B1024, _B512, _B256 Select one for size of bootloader section

12 USE_EXTERN_MEMORY HW_PLATFORM Set this true - if the bootloader should operate with the external memory Select a platform (STK200, STK500, USER_CHOSEN) COMPILER Select compiler for the job :-) COMPILER_AVR_IAR COMPILER_AVR_IMAGECRAFT COMPILER_AVR_GCC CPU_XCLK CPU xclock selection Eg.: FOSC_ UL (check in platform.h) [4.0, , 8.0, , , 16.0] Debugging: REMOVE_UNUSED_CODE_SECTIONS Set true to removed unused code sections (==> reducing code required) XMODEM: PROGRAMMING: CALC_FLASH_CSUM Not working - should perform a CSUM calculation on the flashed code section Figure 4 #define list 2.9 To Do s In to top of the file a ToDo s list is written I will not list these here

13 2.10 Makefile The make file builds the project bootloader! Press make help for helpful information about various commands Figure 5 Bootloader: make help You have mainly two options: Make cleanall Make

14 3. SimpleMain Simple Demo Application This simple main file could be flashed using the bootloader. It s a mini-application for demonstrating the usage of the bootloader. NOTE: Right now I can t recall, if it is setup to work on the target (FF1, FF2) or only on the STK500 evaluation board. Basically is should read a pin, and toggle a LED if pressed. This makefile does not support help, prefix, Doxygen or like. It only supports clean and all.

15 4. Operation with PC This chapter describes how the uploading of the compiled application is done to a board with the installed bootloader. This requires the bootloader is installed!