Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
en:xboot:readme [2012/01/08 23:48] alex [3.7 Bootloader features] |
en:xboot:readme [2012/03/07 04:22] (current) alex [1.1 Compatibility List] |
||
---|---|---|---|
Line 13: | Line 13: | ||
Currently, XBoot should work on any XMEGA processor and any ATMEGA with sufficient memory (4K boot NRWW block). The following list of processors are currently supported. An asterisk denotes the MCU has been tested and confirmed XBoot compatible. | Currently, XBoot should work on any XMEGA processor and any ATMEGA with sufficient memory (4K boot NRWW block). The following list of processors are currently supported. An asterisk denotes the MCU has been tested and confirmed XBoot compatible. | ||
- | * XMEGA | + | * XMEGA |
* atxmega16a4 * | * atxmega16a4 * | ||
* atxmega32a4 * | * atxmega32a4 * | ||
Line 20: | Line 20: | ||
* atxmega64a4 | * atxmega64a4 | ||
* atxmega128a1 * | * atxmega128a1 * | ||
- | * atxmega128a3 | + | * atxmega128a3 * |
* atxmega128a4 | * atxmega128a4 | ||
* atxmega192a1 | * atxmega192a1 | ||
Line 36: | Line 36: | ||
* atxmega256d3 | * atxmega256d3 | ||
* atxmega16a4u | * atxmega16a4u | ||
- | * atxmega32a4u | + | * atxmega32a4u * |
* atxmega64a3u | * atxmega64a3u | ||
* atxmega64a4u | * atxmega64a4u | ||
Line 49: | Line 49: | ||
* atxmega128b3 | * atxmega128b3 | ||
* ATMEGA | * ATMEGA | ||
+ | * atmega324 | ||
+ | * atmega324pa | ||
+ | * atmega325 | ||
+ | * atmega3250 | ||
* atmega328p * | * atmega328p * | ||
+ | * atmega329 | ||
+ | * atmega3290 | ||
+ | * atmega64 | ||
+ | * atmega640 | ||
+ | * atmega644 | ||
+ | * atmega644pa | ||
+ | * atmega645 | ||
+ | * atmega6450 | ||
+ | * atmega649 | ||
+ | * atmega649p | ||
+ | * atmega6490 | ||
+ | * atmega128 | ||
+ | * atmega1280 | ||
+ | * atmega1281 | ||
* atmega1284p * | * atmega1284p * | ||
+ | * atmega2560 | ||
+ | * atmega2561 | ||
===== - Using XBoot ===== | ===== - Using XBoot ===== | ||
Line 60: | Line 80: | ||
==== - Build XBoot and Program to Chip ==== | ==== - Build XBoot and Program to Chip ==== | ||
- | To build XBoot, select a .conf.mk file from the conf directory and make sure the settings are appropriate for your chip, programmer, and configuration. Then type "make [file].conf.mk". This will copy [file].conf.mk to config.mk, generate config.h, compile the whole package, and generate xboot.hex, which can be downloaded with any programming cable capable of programming AVR chips. If you have and XMEGA and want to save some time and just program the boot section, type "make xboot-boot.hex" and then write the new file xboot-boot.hex to the boot section directly with avrdude. The makefile includes built-in support for avrdude, so all you need to do is modify the avrdude parameters in the .conf.mk file for the programmer you have and type "make program". | + | To build XBoot, select a .conf.mk file from the conf directory and make sure the settings are appropriate for your chip, programmer, and configuration. Then type "make [file].conf.mk". This will copy [file].conf.mk to config.mk, generate config.h, compile the whole package, and generate xboot.hex, which can be downloaded with any programming cable capable of programming AVR chips. If you have an XMEGA and want to save some time and just program the boot section, type "make xboot-boot.hex" and then write the new file xboot-boot.hex to the boot section directly with avrdude. The makefile includes built-in support for avrdude, so all you need to do is modify the avrdude parameters in the .conf.mk file for the programmer you have and type "make program". |
Note that after typing "make [file].conf.mk", the settings from [file].conf.mk will remain active until either a new .conf.mk file is selected or "make clean" is run. | Note that after typing "make [file].conf.mk", the settings from [file].conf.mk will remain active until either a new .conf.mk file is selected or "make clean" is run. | ||
Line 81: | Line 101: | ||
Here are a few tips for your main application that will make using XBoot a much more pleasant experience. | Here are a few tips for your main application that will make using XBoot a much more pleasant experience. | ||
- | |||
- | === - Program UART Bits Properly === | ||
- | |||
- | If you select the ''USE_UART'' option, XBoot will program the UART. If your program uses the same UART as XBoot, you should not assume any of the UART registers are blank! Manually force all bits to the desired state. In particular, the 2x bit is often left out of UART configuration routines, but is set by XBoot. | ||
=== - Catch the "Enter Bootloader" command === | === - Catch the "Enter Bootloader" command === | ||
Line 105: | Line 121: | ||
</code> | </code> | ||
- | In many cases, this allows you to use the AVRDude program command without having to manually reset the AVR. Alternatively, if the API is used, calling ''xboot_reset()'' will have the same effect. | + | In many cases, this allows you to use the AVRDude program command without having to manually reset the AVR. Alternatively, the API call ''xboot_reset()'' will have the same effect. |
+ | |||
+ | === - Combine hex files === | ||
+ | |||
+ | To streamline programming multiple chips for a production run, the tool ''srec_cat'' can be used to combine the hex files. Use the command as follows: | ||
+ | |||
+ | <code> | ||
+ | srec_cat xboot.hex -intel main.hex -intel -o mergedfile.hex -intel | ||
+ | </code> | ||
+ | |||
+ | This will concatenate the two hex files together with the proper offsets. Please make sure to use xboot.hex and not xboot-boot.hex to ensure tha the correct offset is used (xboot.hex is relative to address 0 while xboot-boot.hex is relative to the start of the boot section). Note that the combined hex file cannot be programmed with xboot; it is intended to be written with an ISP programmer so both xboot and the application are written in one step. | ||
===== - Configuring XBoot ===== | ===== - Configuring XBoot ===== | ||
- | XBoot is designed to be reconfigured to suit specific needs. Out of the box, all of the standard features are turned on. Turning off features and reassigning pins is easy, just pick a .conf.mk file in the .conf folder, make a copy of it, and edit the appropriate parameters. Then build xboot with your parameters by running "make [file].conf.mk". | + | XBoot is designed to be reconfigured to suit specific needs. Out of the box, all of the standard features are turned on. Turning off features and reassigning pins is easy, just pick a .conf.mk file in the .conf folder, make a copy of it, and edit the appropriate parameters. Then build xboot with your parameters by running ''make [file].conf.mk''. |
Recommended configuration: | Recommended configuration: | ||
Line 220: | Line 246: | ||
* ''UART_U2X'' turns on the double-rate BRG in ATMEGA parts | * ''UART_U2X'' turns on the double-rate BRG in ATMEGA parts | ||
* Note: this only applies to ATMEGA devices | * Note: this only applies to ATMEGA devices | ||
+ | * ''UART_RX_PUEN'' enables a pull-up on the UART RX pin | ||
=== - USE_UART_EN_PIN === | === - USE_UART_EN_PIN === | ||
Line 363: | Line 390: | ||
* ''xboot_app_temp_erase'' | * ''xboot_app_temp_erase'' | ||
* ''xboot_app_temp_write_page'' | * ''xboot_app_temp_write_page'' | ||
+ | |||
+ | ==== - Code Protection ==== | ||
+ | |||
+ | The code protection features built into xboot keep your code safe from reverse engineering. Protected areas will read the same as unprogrammed flash or EEPROM (0xff). | ||
+ | |||
+ | === - ENABLE_CODE_PROTECTION === | ||
+ | |||
+ | Enable basic code protection. Code protection prevents reading of the flash memory via xboot's interface. Code protection is temporarily disabled by an erase command, allowing verification of newly written firmware. Code protection does not disable CRC commands. | ||
+ | |||
+ | === - ENABLE_EEPROM_PROTECTION === | ||
+ | |||
+ | Enable EEPROM protection. EEPROM protection prevents reading of the EEPROM memory via xboot's interface. Like code protection, EEPROM protection is temporarily disabled by an erase command, allowing verification of newly written firmware. | ||
+ | |||
+ | === - ENABLE_BOOTLOADER_PROTECTION === | ||
+ | |||
+ | Enable bootloader protection. Bootloader protection prevents reading of the boot block via xboot's interface. Unlike code protection, bootloader protection is not disabled by an erase command. | ||
===== - XBoot API ===== | ===== - XBoot API ===== |