Serial Bootloader Avr

TinySafeBoot - A tiny, safe and flexible AVR-Bootloader for ATtinys and ATmegas TinySafeBoot - A tiny and safe Bootloader for AVR-ATtinys and ATmegas • • • • • • • • • • TSB-Firmware for ATtinys and ATmegas: • Compatible to plenty of ATtinys and ATmegas • Read/Write access to Flash and EEPROM. • All IOs available for serial communication • One-wire, also with multiple AVRs on a single line • Autobauding, rugged protocol. • Activated by Reset + Password (optional) • Password and Timeout user changeable anytime. • 'Emergency Erase' to overcome lost Password - kills all data but leaves bootloader intact.

Atmel AVR2054 Serial and OTA Bootloader Atmel. A standalone, serial boot loader utility for use with Atmel wireless software stacks such as BitCloud, RF4CE, lwMesh. The vote is over, but the fight for net neutrality isn’t. Show your support for a free and open internet.

• ATtinys: ~ 550 bytes, ATmegas. Idea Most AVR Bootloaders were designed for ATmegas only. No wonder, since we got special Reset-vectors, lots of memory, protected memory sections and real hardware UARTs in that controller family. These may be the reasons for so many ATmega-Bootloaders dealing with bulky protocols and mindless crypto-stuff. In fact, all the current ATtinys also have the feature of 'Self Programming' and some portion of SRAM on chip. These are the two essential prerequisites for implementation of a Bootloader.

Deeper thoughts on activation mechanism, memory consumption and safe Flash access were useful though. There are few well elaborated ATtiny bootloaders out there, and the best ones are of course written in Assembly language. The TSB project just combined, what's established as good practice in this context, with an innovative approach to add reasonable installation, configuration and security support. TinySafeBoot Supported ATtinys: tn13A tn13 tn1634 tn167 tn2313A tn2313 tn24A tn24 tn25 tn261A tn261 tn4313 tn44A tn44 tn441 tn45 tn461A tn461 tn48 tn84A tn84 tn841 tn85 tn861A tn861 tn87 tn88 Note: The table on the right is rather 'theoretical' for most ATmegas that i haven't tested the TSB-Firmware so far. Feel free to try out and give me your (positive or negative) feedback! Installation Prerequisites • running on the respective host platform (low requirements, commandline tool).

• Genuine RS232 or USB-COM must exist, as well as an adequate RS232-level converter circuitry at the Controller's board. • First installation of TSB on fresh ATtiny/ATmega requires ISP-Programmer + Programmer software for the host platform (e.g. AVR911 Programmer plus AVROSP2 on Windooze). • (the actual bootloader) has been generated for the respective ATtiny/ATmega and configured for the desired portline(s). You can build it directly from assembly sourcecode within AVR-Assembler infrastructure (even the 'Studio', if your kinda addicted to punishment), or simply let the TSB-Software generate one for you! And remember the Fusebits! System32 Ntoskrnl Exe Download Free here. ATtinys: • SELFPRGEN must be set to enable flash writes from firmware, e.g.

TSB • BODLEVEL should be set to avoid flash corruption during unsafe device power-up. • LOCKBITS may be set to MODE 3 for enhanced security (i.e. Serious password protection intended).

ATmegas: • BOOTRST activated lets the MCU jump into the Bootloader Section (rather than $0000) with every hardware Reset. • BODLEVEL should be set to avoid flash corruption during unsafe device power-up. • BOOTSZ=10 or BOOTSZ=11 to reserve 512 bytes for a Bootloader Section. • BLB to MODE 2 or 3 protects Bootloader Section from undesirable write access by firmware. • LOCKBITS may be set to Mode 3 (LB-Mode 3) in a security environment. Prerequisites for Application to coexist with TSB • General: Nothing special to observe.

Application's firmware should start at $0000 and first machine opcode must be a jump to its Reset-routine. (Standard behaviour of all AVR-compilers.) • Application plus Bootloader code may not take more than available flash memory on the respective ATtiny (just to mention;-). • Application should do without SPMs on the ATtinys. This will minimize the risk of Bootloader (and Application) being corrupted. At least, take care to prevent Flash writes into upper pages that contain the bootloader firmware. Generally, it's good practice to store some bytes of working data in the EEPROM section.

On ATmegas with BLB-Fuses set - no further precautions needed at all! Protocol RS232-TTL, 8-N-1, half duplex, max. 57600 bps @ 16 MHz, inverted 5V-logic levels Two-Wire: In a typical setup, the board provides for RS232-connectivity by means of some levelshifter like MAX232, LTC280x, simple 2-transistor-converter (see appnote ), or even.

Also USB to virtual serial port interfaces like FT232 or PL2303 may be in place. The bootloader may be configured for the same two portlines that are normally used by the Application for RXD and TXD - thus eliminating the need for any additional hardware. (NOTE: The term 'Two-Wire' refers to an RS232-style interfacing in this context. It should not be confused with 'TWI', which is Atmelspeak for the I2C-bus.) One-Wire: If the board does not make use of any regular RS232 and we're running short on I/O-ports, we can do all bootloader communication by only one bidirectional portline that's alternately switched between TXD and RXD functionality. One-Wire is a well-proven concept originating from the world of amateur radio, and it's working fine for many asynchronous half-duplex serial transactions (i.e.

RXD and TXD do not perform data transfer at the same time) as well. Hardware requirements on the MCU board are minimized with only one portline and a simple 2-pin connector to lead out.

On the net you will find several descriptions on how to build some One-Wire adaptor for the Host, often referred to as 'CI-V' interface. Even simple ones perform pretty well with TSB. Try for a start. When it comes to sending data, the TSB firmware will control the bidirectional portline with open-collector characteristics. This is to avoid electrical conflicts with an attached one-wire-interface, even if the sequencing of send/receive should fail for any reason.

For One-Wire, an external pullup-resistor (about 1k. 4k7) is strongly recommended to enable sufficient signal levels and rising times (= higher transmission speed). Yet, in a Two-Wire-setup (with MAX232 or other RS232-TTL-converter attached), the TXD-assigned portline will be driven straightforward as a normal output (sinking and sourcing current). One-Wire in a bus: Yes, we can hook up several TSB-featured AVRs to a common bidirectional communications wire and address them separately simply by using different passwords. Only the TSB-device that has detected its unique password will give a reply and occupy the bus. The other TSBs lock into an endless loop and stay passive until next hardware reset occurs. TSB's should be configuered separately with their passwords before linking them to a common One-Wire. Only one Pull-up is needed for all devices collectively.

Further on, it is recommended to have all TSBs using similar or same clock frequency and Timeout settings. They should be hooked up to a common Reset-line (or have similar start-up properties when powered-up). Logical sequence of a bootloader session: • Connecting (in fact, plug hardware and serial port stuff together, identify COM-port number, open Console in TSB-folder). • Activate Bootloader via Hardware-Reset on the controller platform. • Send calibration characters plus password to the bootloader (before time-out) • TSB responds with device info block (wrong password - no reaction).

• PC sends TSB-command. • Mutual data exchange via tsb-protocol. • Confirm successfull execution by Bootloader - further actions and goto 4 - or leave bootloader and start Application. Like other ATtiny Bootloaders, TSB does not emulate some legacy protocol to perform its tasks.

Those bulky STK-protocols are neither suitable for autocalibration of baudrate, nor do they provide means of serious access control. So, TSB must have had some house-made communication protocol, but, certainly, it's open-documented and well tested.

Note: All data communications with TSB use full 8-bit-characterset for efficiency reasons. However, all commands and control characters are printable ASCII characters; this allows for some basic testing with even the simpliest terminal program. Activation, Calibration, Command processing: Activation + Login: Hardware-Reset the Controller Host-PC: sending '@@@' + 'Password' BL: sending Device info Command execution: Host: send BL command (see tables below) BL: acknowledge with CF or cancel activity with RQ Finished: BL awaits further commands BL will start application when receiving an invalid command (e.g. 'Z') Commands: 'f' = Read Flash 'F' = Write Flash 'e' = Read EEPROM 'E' = Write EEPROM 'c' = Read Userdata 'C' = Write Userdata Handshake/Flowcontrol: '?'

= chr$(63)= RQ ('Request') '!' = chr$(33)= CF ('Confirm') Flash / EEPROM - access, User data access, Emergency Erase: Flash Read Flash Write EEPROM Read EEPROM Write Always from start to end of available Application Flash. Terminated by Host Always 'til end of EEPROM Terminated by Host Host Bootloader [Login] 'f' + CF CF CF CF [done] [Reset] [Info] [Page1] [Page2] [PageN] +CF Host Bootloader [Login] 'F' CF+[Page1] CF+[Page2].

RQ [done] [Reset] [Info] RQ RQ CF Host Bootloader [Login] 'e' + CF CF CF. CF [done] [Reset] [Info] [Block1] [Block2] [BlockN] +CF Host Bootloader [Login] 'E' CF+[Block1] CF+[Block2]. RQ [done] [Reset] [Info] RQ RQ CF Terminated by Bootloader (due to end of Appflash reached or verifying error) Terminated by Bootloader Host Bootloader [Login] 'F' CF+[Page1]. CF+[PageN] [abort] [Reset] [Info] RQ RQ CF ( RQ) Host Bootloader [Login] 'E' CF+[Block1].

CF+[BlockN] [done] [Reset] [Info] RQ RQ CF Read / Write User Data Emergency Erase Read User Data from LASTPAGE Do engage the Emergency Erase (kills 1. Windows Xp Familiale Isopure. User data) Host Bootloader [Login] 'c' [done] [Reset] [Info] [LASTPAGE-Data] +CF Host Bootloader '@@@' CHR$(0) CF [done] [Reset] [await PW] RQ [security confirm] [erase EEPROM] [erase Flash] [erase LASTPAGE] CF Write modified User Data to LASTPAGE. No, no, just kidding.

Host Bootloader [Login] 'C' CF+ New data for LASTPAGE [finished] [Reset] [Info] RQ New Device Info Block +CF Host Bootloader '@@@' CHR$(0) RQ ( CF) [nothing changed!] [RESET] [await PW] RQ [1st confirm] [no reply]. Software TSB commandline tool for the PC platform This is a simple commandline tool (W32/Linux), addressing all functionality of the Bootloader. Additionally it is capable of generating customized TSB-Firmware for all supported devices. The executable may also be easily invoked from batch scripts. This program is free Software.

It is being further developed for with Geany. The sourcefile may be compiled platform-independently without major modifications. Full functionality has been proven successfully under windooze (from XP up) and current linux distros (Debian/Ubuntu).