Kindly have a look at the follow-up project: One-Way-Loader

TinySafeBoot - tiny and safe Bootloader for AVR-ATtinys and ATmegas

Idea

TSB

Installation

Protocol

Firmware

Software

Remarks

Downloads

Links

Index

TSB-Firmware for ATtinys and ATmegas:

Compatible to plenty of ATtinys and ATmegas (see below )

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.

ATtinys: ~ 550 bytes,
ATmegas: < 512 bytes (!)

TSB for ATtiny can update itself.

The Sourcecode is free Software (GPL)

TSB-Software Tool for the PC:

All features easily accessible via commandline parameters and/or menu driven

Script-friendly

Make bootloader on user's wish (tiny models, ports) but without the need for assembler infrastructure!

Integrated Database of pre-assembled TSB-Code

Programming, Compiler and IDE: Open Source

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.

Top | Index

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!	Supported ATmegas: m162 m164A m164PA m164P m165A m165PA m165P m168A m168 m168PA m168P m169A m169PA m169P m16A m16 m16HVA m16HVB m16M1 m16U2 m16U4 m324A m324PA m324P m3250A m3250 m3250PA m3250P m325A m325 m325PA m325P m328 m328P m3290A m3290 m3290PA m3290P m329A m329 m329PA m329P m32A m32C1 m32 m32HVB m32M1 m32U2 m32U4 m406 m48A m48 m48PA m48P m640 m644A m644 m644PA m644P m6450A m6450 m6450P m645A m645 m645P m6490A m6490 m6490P m649A m649 m649P m64C1 m64M1 m64RFR2 m8515 m8535 m88A m88 m88PA m88P m8A m8 m8HVA m8U2

*Memory Allocation:* Bootloader residing in upper storage and takes about 550 Bytes of Flash space. Bootloader is invoked by the modified reset vector at $0000 in the Application Flash. Bootloader will handover to the Application's Reset routine (rjmp APPSTART) after waiting time elapsed or command execution finished. Application regularly beginnung at $0000. Its Reset vector (rjmp at $0000) is the only word that will be modified by the Bootloader. *Flash Access:* No interrupts admitted. MCU waits for any Flash-Activity to be finished. Flash Erase always top-to-bottom. Will keep RJMP BOOTSTART (...which ensures accessibility of Bootloaders) as long as possible. Flash Writes performed bottom-to-top. RJMP BOOTSTART will be re-written with the 1st page's page write from the instant. Internal verifying of every freshly written Page - Automatic Erase of Application flash if errors were detected.	*Memory Allocation:* Bootloader residing in upper Bootloader-Section of 512 Bytes sharply. Bootloader is invoked by Hardware Reset by way of an activated Bootloader Reset Vector (Fuse "BOOTRST") Bootloader will handover to the Application's Reset routine by simple jump back to $0000, where the App's original reset-vector is supposed to be. Application should start at $0000 and won't be modified at all by the bootloader. *Flash Access:* No interrupts admitted. Program is strictly waiting for Flash-Activities being accomplished. Flash Erase top-to-bottom. Flash Writes bottom-to-top.
*What else is that 'safe' in TinySafeBoot?* Activation of the Bootloader with calibration characters prevents inadvertent trigger. Protection and individual device addressing by large passwords. Password and Timeout may be changed anytime by the authorized user, without need for re-assembly and further ISP-sessions. Robust and efficient block data transmission with internal verification for flash writes. Application reset-jump and userdata are located in a dedicated memory page (LASTPAGE). Flash access to this page won't affect the integrity of Application or Bootloader. (ATmega: Full SPM-protection on Bootloader Section by Fusebits) "Emergency Erase" deletes Application, EEPROM and user data but leaving Bootloader intact. No "russian roulette" with the Fusebits! Compact and genuine Assembler programming, no backdoors provided... Database of pre-assembled TSB-Firmware templates integrated with TSB-Software. Users are enabled to make their own TSB for certain ATtiny/ATmega-models and certain portlines for RS232 without Assembler infrastructure.

Top | Index

Installation

Prerequisites

TSB-Software 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).
TSB-Firmware (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!

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!

Top | Index

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 AVR910), or even that one. 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 this 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). Have fun!

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. See below!

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. Flash, 2. EEPROM, 3. 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]`

Top | Index

Firmware

TSB has been written in pure Assembly with utmost code efficiency and transparency in mind. Seems that with approx. 560 bytes, it is still one of the most compact and rich-featured AVR-Bootloaders at the same time. And the ATmega-Version... see below!

TSB for ATtinys: Newer versions come out as an "Installer". This is a regular Application starting at $0000 with the benefit that it can be installed either via ISP but also by way of any existing bootloader on the ATtiny. In short terms: TSB-Installer kicks out an existing bootloader, copies piggyback TSB-code to its target location on top of flash memory, and finally lets the new TSB take over. This allows for a modification of TSB by way of TSB without ISP :-). Note, that the Installer's copy routines will be completely removed from memory after successfull transfer. So, the update feature won't cost precious memory in the regular TSB-Firmware. See below for details on how the trick is done, or refer to the commented assembly source.

TSB for ATmegas: TSB for ATmegas enables many ATmegas to benefit from the useful functionality of TinySafeBoot, without sacrifice of too much flash memory as we know it from too many other ATmega bootloaders. Au contraire! All security-related characteristics of TSB, namely Password and Emergency-Erase, buffered transmission and regular functionality were easily to be transferred into the ATmega world. Some minor adjustments were necessary though (regarding the RWW/NRWW-stuff, flash write timing) but in the end, i've managed to make the ATmega version of TSB even smaller than TSB for ATtinys. TSB for ATmegas fits exactly into a boot flash section of only 512 bytes!
Just to be honest, we actually had to drop one feature that was crucial on the ATtinys, but abdicable for an ATmega bootloader: On the ATtinys, the internal verifying was also intended to prevent the ATtiny from executing corrupted Application code, since every page is being verified against original data before going on. In case of a verify error, TSB would instantly erase all the Application flash, thus protecting itself from damage or lock-out. With ATmegas we do not necessarily need this feature, since the boot flash section can be entirely protected from unwanted access and the verifying of Application data may be safely postponed in to a second round.
Just to add, this is a full-fledged ATmega-Bootloader that makes consequent use of the BOOTRST mechanism, i.e. not depending on a modified RESET vector like with ATtinys.
Since TSB bootloader code is virtually "immortal" on ATmegas, the TSB-Installer mechanism won't work either, since there is really no way to modify a protected boot flash section from software. Seems that we'd have to do some ISP-session to reinstall a different bootloader on ATmegas. Accordingly, TSB code for ATmegas is always being generated without the installer feature, i.e. directly for its target address.

Activation

When Reset line was triggered on the AVR, one of the first things happening is that several registers and hardware components are initialized, and then the program counter is set to $0000. At this location the processor will most likely find an rjmp (or jmp) opcode that points right to the Reset routine of the Application.
To implement some Bootloader on ATtiny, the jump located at $0000 is to be modified in such way that it points to the start address of the Bootloader instead of the Application's Reset. Yet the Bootloader should know the original address of the Application's Reset routine to return to the Application once the bootloader has finished its task.
On the ATmegas, it's basically the same procedure but without modifications in the Application programme necessary. With the BOOTRST fuse activated, the Controller will no longer jump to $0000 by hardware reset, but directly jump to a higher address that is defined as Bootloader Section (by other Fusebits). In this upper memory section the Bootloader resides. And best of all the Bootloader does not even have to know anything about the App that's currently installed down there - after doing its job, the Bootloader will simply jump to address $0000, where the Application's original Reset-vector is supposed to be.

Since this way the Bootloader is invoked by every Reset, it must check if it was "meant" anyway:

Certain serial characters are received within the waiting period (Timeout) - Bootloader gets activated and awaits further characters (i.e. Password or Commands)
Timeout? - Handover to Reset-routine of Application.
RXD-line LOW from the beginning: Should RXD stay on low logic level from the beginning, the RS232-TTL-connection is assumed to be 'faulty' and TSB will not try to await serial characters, but directly forward to the Application. Inspite of unsafe voltage levels in the course of Power-up-Reset, fixed safety delay of about some tens or hundreds of milliseconds is inserted before checking RXD.

Calibration (Autobauding)

Within the Timeout period, the PC sends a sequence of certain serial characters. The bootloader measures the overall duration of the logical zeroes and calculates a clock division factor that is precisely matching the given baudrate in relation to the actual MCU-clock frequency. After this calibration cycle, the controller is capable of sending and receiving serial characters with the current baudrate even without a built-in UART (that many ATtinys do not have). In some respect, the software-UART is more flexible than hardware-UART, since it is capable of using all available I/O for the serial communication and isn't bound to certain clock frequencies.

Password-Check

A password, if configured, should be sent directly (unprompted) following the calibration characters. Provided that the right password was entered, the bootloader will answer with its Device Data (see section below). If the submit password was wrong, the bootloader will give no indication on which character was wrong, and the only way to recover is another hardware triggered Reset.
With newer firmware versions, even the average processor load is very much the same as in active password checking. This has been an urgent fix with regards to elaborate attacks on the password checking routine by means of Power analysis. So, instead of resetting or starting the application, as with other Bootloaders, TSB will 'hangup' pretty silently.
Passwords may consist of all 8-bit characters, except for $00 and $FF. Length of the password may be up to the number of bytes per memory page in the respective ATtiny, less 4 bytes reserved for Appjump, Timeout and one termination character.
Since the password is administered in Userdata area, it could be changed from time to time without the need for re-assembly and re-flashing the whole bootloader. Also the Password feature may be deactivated at all by simply defining a 'nul' string for a password; e.g. for low-security applications or debugging sessions.

Device Info

After receipt of calibration chars and password, the Bootloader automatically sends Device Info:

    3 bytes ASCII identifier "TSB"
    2 bytes firmware date identifier
    1 byte firmware status identifier (reserved)
    3 signature bytes in the format of ATMEL signature bytes
    1 byte the Pagesize in Words (with ATtinys this may be 32, 64 or 128 Byte)
    2 bytes of available Flash memory (total free memory in bytes for Application minus Bootloader alotted memory)
    2 bytes EEPROM size

As we can see, all information needed for further device-specific operations has been submit by the datagram. This eliminates the need for PC software to search definition files before accessing a certain AVR.
The first 14 bytes of Device Info are in fact permanent data that will never change for a certain device. Thus it is held within the regular assembly code segment of TSB. It cannot be damaged by Flash erase/writes that apply to Appflash or LASTPAGE.

User Data

Later on the computer may request User Data:

    2 bytes Application jump address
    1 byte Timeout
    n bytes of password

Only those user-changeable parameters are placed in the very last page of the ATtiny's available memory (LASTPAGE) which is subject to user-initiated changes. If these operations should fail or LASTPAGE has been erased by accident, this does not harm integrity of the bootloader. Same applies for TSB on ATmegas, with the only difference, that LASTPAGE has been shifted down to the de-facto last page of Application Section. (This was necessary to enable write access from the Bootloader, which may itself being protected against SPM by the respective Fusebits.)

Accessing Flash and EEPROM

All critical write access to Flash memory pages is done due diligence of "Best Practice". Yes, I have been testing quite different methods before - just to become aware, that the following principles are in fact the best thing one can do to make a very stable and safe AVR-Bootloader:

Block transmissions with least protocol overhang: Data communication is organized in bursts of data blocks, equal to Pagesize of the flash organization. With respect to modern OSes, this allows for an effective RS232-transmission and is also suited to the limited ressources at Controller's site.

Flash Erase: Deletion of Application Flash takes place due to proven practice from "from top to bottom". Starting with the rearmost page, just below BOOTSTART, and proceeding down to the 1st page. This is considered the safest method, since the Reset jump at $0000 remains intact to the end. When the 1st page was finally deleted, too, we would find only $FF bytes in all memory locations from $0000 to BOOTSTART-1. The processor interprets this as machine opcode NOP. So there is really no danger of bootloader-lockout, if the power supply should fail at this very moment - since the controller would simply run through some thousands of NOPs 'til he finally reaches BOOTSTART - voilà, we're in business again!

Flash Writes: Bootloader receives data packets of actual pagesize in the respective ATtiny. Page contents received are first buffered into internal SRAM of the controller. By the way the Bootloader modifies the Reset-RJMP of the original Application to point to the Bootloader's startaddress (TSB for ATtinys). After transferring the data into the internal pagebuffer, the respective page is written, with one single SPM, to flash memory. All subsequent page-writes are considered uncritical, as the RJMP to invoke the Bootloader has already been restored.

Verifying: Every Flash page is verified against current buffer contents immediately after page write was complete. This method of internal verifying is reliable enough to make external verifying dispensable and thus avoid double data transfers in many fields of application. If, however, an error has been detected by the internal verifying, the Bootloader will automatically re-erase all Application flash to consequently remove any machine code, that may be corrupted and thus could be dangerous for or impair the accessibility of the bootloader. Of course, the PC will be notified about that. In some case, data corruption is not primarily caused by flash wearout, but merely due to instable power supply or transient disturbance. So, it's always worth a second (third, fourth...) try to cure flash errors; but it's a matter of fact, from my point of view, that such further write attempts must be initiated by the user rather than the bootloader itself. This means, TSB firmware cannot write a certain flash page more than one time per session. This is to effectively avoid any danger of hangups/infinite loops that could finally kill some already instable flash.

EEPROM Read/Write access is done likewise using Pagesize for the block size. EEPROM write access does not need internal verifying due to the robust "atomic write" mode that is applied. Of course, the Tool allows external (subsequent) verifying.

Changing Password and Timeout

The User Data of Appjump, Timeout and Password is located in LASTPAGE, separated from the TSB firmware at least by one page boundary. It can be safely read and modified via page-oriented SPM command without danger of affecting firmware code memory.

If LASTPAGE has been deleted by accident or in the course of an Emergency Erase, all bytes in this page will read $FF. These are, not incidentally at all, safe defaults of TSB meaning "no password, long timeout".

The advantages of user-defined passwords don't have to be advertised in here. Yet, the password may also be completely deactivated with TSB, e.g. for minimum safety environment or batch processing purposes.

Being able to change Timeout factor later on is pretty useful while reset-timing may be examinated and optimized in conjunction with the respective application.

For example, on a target platform that performs automatic reset of the AVR when serial port was opened (trigger of reset line by DTR or RTS), a minimum Timeout of only some 1/10 seconds will be sufficient for safe access to the bootloader. In other applications with manual reset or even power-on-reset, much longer timeouts of several seconds may be required.

Since the MCU clock cannot be considered in the preassembled TSB-Templates, the 'currency' of Timeout depends on the respective clock frequency. In general, bigger values of the Timeout byte result in a longer time to wait for the bootloader. You may calculate or estimate the actual Timeout time by the following thumb rules:

t_TO = desired Timeout (seconds) f_MCU = controller clock frequency(MHz) TO = TIMEOUT (valid from 8 to 255) f_MCU * 10⁶ * tTO TO = ------------------ 196600

f_MCU / TIMEOUT	4 MHz	8 MHz	16 MHz
8	80 ms	40 ms	20 ms
128	6 s	3 s	1,5 s
255	12 s	6 s	3 s

Emergency Erase

This function could be launched by anyone without a password that submits a dedicated command sequence. Properly confirmed, TSB will first delete all memory contents in Appflash, then the EEPROM and, at the very last, Userdata in LASTPAGE. Of course, the bootloader won't kill itself.
Emergency Erase can thus reinstate a sound the bootloader without the hassle of re-assembly and re-accessing the device from ISP. Since all user specific data got lost by an Emergency Erase, the feature will not lessen security. An attacker will not gain any more information compared to an ISP-initiated chip erase.

The brave TSB-Installer for ATtinys

The TSB-Installer is a run-once Application for the respective ATtiny model that's regularly starting at $0000. Thus is can be installed via ISP, but also by way of any simple ATtiny bootloader that may be in place. The TSB-Installer allows to exchange an existing bootloader by a current version of TSB.
Basically, TSB-Installer consists of some deeply considered copy-and-verify stuff to transfer machine code of the respective TSB-version brought along to its target locations. The following sequence seems to provide for a quite stable TSB-Installer/Updater mechanism within the limitations of the ATtiny platform:

Check installed Installer's integrity. In case of doubt, do nothing and leave the old Bootloader accessible.
Disable modified reset-jump at $0000 and reinstate the Installer for the one and only reset target.
Erase previous bootloader.
Write new TSB firmware into upper flash pages, and verify each of them. In case any power-failure or verify error, hangup! Further Resets would always restart the sequence from level 1 to 4, until there is - hopefully - success with all pages correctly written and TSB-code successfully installed at target location.
Erase TSB-Installer from AppFlash. This will handover all controls to new TSB. Mission accomplished!

NOTES:
Level 1: It's not very likely, but we must consider what will happen if the upload of TSB-Installer's firmware has failed, e.g. by power outage or strange serial communication errors that slipped through the protocol. With corrupted data in the installer, we would run into the fatality of replacing an existing and functional bootloader with a broken one, that would leave us with a useless device, if there is no "Plan B" in place to regain ISP access.
To ensure that the Installer was uploaded in its completeness into the ATtinys flash, the current version uses a comparably simple and effective method of error-detection. Almost all bytes of the TSB-Installer-routine plus the attached TSB-Firmware are summed up to a 16-bit-checksum. This value is being compared with two bytes that were written into the 1st page of the Installer's program code. The checksum is, of course, to be calculated by the TSB-Software after the respective changes of port assignments have been applied by the "make customized firmware" part of the programme. (Thus it cannot be predefined in the assembly sourcecode.)
If the Installer finds that its calculated checksum was okay, it will continue with the mission-critical part; erase 1st page, copy and verify the TSB-stuff into its target. If, however, the Installer finds that the checksum does not match, it certainly does nothing more than waiting and the old bootloader will stay in force.

Level 2: The 1st page of Flash only contains a reset-jump, another jump to the integrity-checking routine of the TSB-Installer and the checksum. The reset-jump has been modified by the old Bootloader to point to its own starting address in order to keep itself accessible. The jump to the integrity-checking routine and the checksum itself are no longer needed once the integrity check was successfull. So, the TSB-Installer can safely erase the whole 1st page in one rush. This deactivates the old bootloader and makes the Installer the only reset-target at the same time. Should, for any reason, further resets or coldstarts occur, there is only the Installer to be started and it will obstinately proceed in its mission.

Level 3: Old bootloader is being completely erased from memory. To be precise: ALL memory pages, except those being occupied by the Installer, will be killed now. This is to ensure that no executable code, except from the Installer itself, remains in Flash.

Level 4: Copy TSB-Firmware from its temporary location up to its target memory on top of the ATtiny's flash. The transfer is done in a page-wise manner from top to bottom. This is to avoid overlap in the smallest ATtinys (with only 1 KB). Of course, all memory pages are being verified. Should any error occur on this level, the procedure will halt and stand by.
Further write attempts may be triggered by hardware resets or power-ups. This offers chance to possibly "cure" some defective flash (by application of: different voltage, clock frequency, temperature conditions).

Level 5: Now we are nearly done: New TSB firmware has already been written true and correctly to its target locations. To "activate" it, we must remove all programme code in the AppFlash area, that is from $0000 to BOOTSTART-1. This would lead the processor to always find TSB. Since it is impossible to erase the same flash where machine code is actually being executed, we'd rather jump directly into the subroutine "EraseAppFlash" of our newly installed TSB! It will reliably erase all flash memory below the new TSB and leave it with a clean AppFlash.

Top | Index

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 FreeBasic 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).

Mode 1 - Communication with a TSB-featured device:

Optional password request before any activity
Show Device Data Block (version, signature bytes, pagesize, memory-sizes etc.)
Programming, Verifying and Readout of Flash and EEPROM
Change Password
Change Timeout
Import and Export Flash/EEPROM data in Binary or Intel-Hex format
All serial ports known to the OS are supported (COM1-COM255, /dev/ttyS or /dev/ttyUSB)

Mode 2 - Generate TSB-Installer (ATtinys) or TSB-Firmware (ATmegas)

Submit controller model
Submit desired I/O-ports for serial communication (simply use same portline for one-wire configuration)
Store customized TSB file in Binary or Hex, ready for being flashed via ISP or existing bootloader

Top | Index

Remarks

"ATtinys don't support Bootloaders!"

That's what the ATmega fanboys and the self-entitled experts, especially in those "professionally-proggin-in-C" forums, always say, when it comes to the topic. Seems they're not necessarily aware of lying. Having advanced to a "higher-level" of programming, some people tend to develop a certain ignorance for hardware matters, and thus will never tease the best out of any Microcontroller, even if it was such handy, straightforward, versatile platform like the AVRs are. Rather than givin' some thoughts into more effective ways of programming and making reasonable use of peripherals, the preachers of dilettantism will likely prefer upgrading to more "mega" processors with more memory, interrupts and I/Os - only to host their miserably kludged LED-blinkin' app plus some mighty bootloader, mighty in terms of Kilobytes, you know, the sort with bloated protocols and half-baked crypto stuff...

A view to the AVR-ATtinys' security features

In a basic configuration the memory contents in a microcontroller aren't safer or unsafer than any other data stored unencrypted on electronic memory devices e.g. USB-sticks. Anyone coming along with a programming adaptor gaining physical access to that device will be enabled to read-out and modify controller's firmware and data. Even sophisticated bootloaders with "encryption" are nearly useless and can be easily circumvented if the hardware programming interface is still accessible, and, just to mention, in flash the executable portion of programme code will be unencrypted anyway.

Fortunately ATMEL implemented the Lockbit feature on most of their AVR microcontrollers, including many ATtinys. Setting the lockbits to "Mode 3" prevents any read and write access to EEPROM and Flash via hardware interfaces (i.e. ISP, debugWire). Having done so, only way to regain access is to perform a full Chip-Erase. Certainly this will also kill any Flash and EEPROM contents, and only at the very last moment, the fuse- and lockbits are reset to their defaults.

Since ISP still offers the Erase feature, bad people may take our controller underhand, erase the original version of the firmware and upload some fake version with, say "modified security features"... Such manipulation could even remain undiscovered as long as there is no additional means of authentication or checksum implemented either in the bootloader or application.

But now the good Bootloader gets on stage! With the Lockbits activated, an installed bootloader remains the only way to read or write memory contents in the microcontroller. But there's an important difference to plain ISP: Bootloaders may be secured with a strong password against unauthorized access!

Still an attacker could fully erase the chip and install his version of application and bootloader firmware, since the source code is freely available. Yet any parameters, data or passwords, that has been stored later to memory locations of the AVR, will get lost by the erase cycle, and there is no practical way for an attacker to restore them or "pretend" the knowledge of the secret. This allows for a simple but strong protection against unauthorized firmware modification:

If the authorized user is suddenly allowed to log in with any password (or none), firmware must have been manipulated in the meantime.
If the authorized user could only log in with his (secret) password, he has certainty, that neither the Bootloader nor the application firmware has been manipulated.

Note: The proposed concept of password protection does not impair user rights. Owner of the device and keeper of the secret password in one person is a free and responsible man to read and write any contents off or into his platform. In particular, there are no mechanisms in place that will only allow proprietary firmware to run on the chip. User has freedom of will to do what he desires with his hardware. No crypto-gags, no licence-to-pay or activation-stuff. Do what thou wilt shall be the whole of the Law.

Top | Index

Download

TSB download is no longer available.

Top | Index

Links

Top | Index

First Release: 09/2011 - Latest Revision: 10/2016