TinySafeBoot Bootloader One-Wire Interface

Hallo "tsb"!

Also, mit den von Dir genannten 8 MHz und 9600 Bd (Default der 
Host-Software) sollte es eigentlich funktionieren ;-) Vielleicht 
trotzdem mal mit 4800 probieren. Wenn es dann überraschenderweise geht, 
ist wohl ein Pullup erforderlich, weil die Signalflanken sonst zu 
wabbelig sind.

Wie war denn das Reset-Timing in der Two-Wire-Variante?
Notfalls sollte immer der Power-On-Reset funktionieren, um TSB 
aufzurufen. Nachdem mich etliche Leute darauf hingewiesen haben, dass 
sie /RESET in ihren Anwendungen für andere Zwecke nutzen wollen, habe 
ich schon vor einiger Zeit in TSB eine zusätzliche Warteschleife 
eingebaut, die nach einem Power-On-Reset erst stabile Bedingungen auf RX 
abwartet, und dann erst zum normalen Timeout (Warten auf "@@@") 
übergeht. Damit war TSB auch in scheinbar unmöglichen Anwendungen wieder 
erreichbar, es war also offenbar keine "Verschlimmbesserung". (Mal 
sehen, was noch kommt...)
Wenn TSB beim Aufruf feststellt, dass RX oder die kombinierte 
RX-TX-Leitung am Anfang keinen sauberen High-Pegel erreicht (entspr. 
Stoppbit/Leerlauf in RS232-TTL-Logik), dann wird natürlich zur 
Applikation weitergeleitet. Priorität hat immer, dass der Start der 
eigentlichen Anwendung nicht auf Dauer durch den Bootloader blockiert 
werden kann.

Natürlich macht TSB keinen Mucks, wenn eine oder alle nachfolgenden 
Bedingungen zutreffen:
- Zeitfenster verpasst (Hauptprogramm läuft bereits),
- Schnittstellenkommunikation unstabil, oder
- Passwort war definiert, aber der Anwender gibt was Falsches ein...

In keinem der oben genannten Fälle antwortet der Bootloader. Warum 
sollte er auch? Die Sicherheitsüberlegungen habe ich ja schon 
angesprochen. Der Chip soll durch Lockbits und physische Maßnahmen nach 
Bedarf komplett abgeschottet werden können.
Außerdem gibt es noch die in [2] so schön ausgebreitete Möglichkeit, 
mehrere Bausteine an einem One-Wire-Bus zu betreiben. Da wäre es 
fatal, wenn ein Device, das nicht persönlich angesprochen wurde, 
irgendwelche Zeichen raushaut...

(Diese Bus-Geschichte mit mehreren ATtinys funktioniert also definitiv 
auch mit TSB. Ich habe es mit bis zu 5 verschiedenen ATtinys auf 
derselben Leitung und nur einem gemeinsamen Pullup getestet. Die 
Timeouts müssen ungefähr übereinstimmen und alle sollten sich mit 
derselben Baudrate ansprechen lassen. Der Zeitpunkt des gemeinsamen 
Resets (einziger Schönheitsfehler im Grunde) ist nicht kritisch. Es 
sollten eben alle Devices ungefähr im selben Zeitfenster auf 
Synchro-Zeichen reagieren können. Auf dem Bus wird sich nur der TSB 
melden, dessen richtiges Passwort gesendet worden ist. Anstelle einer 
gemeinsamen Reset-Leitung geht auch die Brutalo-Methode mit einem 
gemeinsamen Power-On-Reset.)

So, das waren erstmal meine 50 Cent!

Viele Grüße,

Julien Thomas

Hi!

Also ich befürchte ja, das ist mal wieder so ein Spezialfall...
Einerseits ist beim PW-gesicherten TSB die Wahrscheinlichkeit praktisch 
Null, dass dieser auf zufällig gesendete Zeichen in irgendeiner Weise 
reagiert. Selbst wenn der String mit "@@@" anfangen würde und in einer 
für TSB auswertbaren Baudrate vorliegt, dann müssten die nachfolgenden 
Zeichen schon genau dem Passwort entsprechen, damit TSB darauf ungewollt 
reagiert. Kollisionen sind in dem Sinne also nicht zu befürchten.
Andererseits bedeutet das wohl in Deiner Anwendung eine Blockade durch 
TSB:
Der TSB-Timeout läuft ja nur VOR dem Empfang möglicher Synchro-Zeichen. 
Sobald innerhalb des Zeitfensters irgendein serieller "Zeichenmüll" 
reinkommt, wird TSB intern bis zur Passwort-Testschleife weiterkommen, 
aber ungeachtet falscher Baudrate und Synchronisation weiterhin nicht 
reagieren und auch nicht an die App weiterleiten. Das ist eigentlich so 
gewollt, weil jede von außen sichtbare Reaktion möglicherweise einen 
Rückschluss darauf zuließe, wieviele der bereits gesendeten Zeichen nun 
doch richtig waren (Brute-Force-Angriffe).
Ein weiterer Timeout oder eine Erkennung von zu viel unsynchronisiertem 
Zeichenmüll wäre außerdem ein erheblicher Mehraufwand und würde das 
flache Energieprofil der Passwortauswertung sogar wieder infrage 
stellen.
Den Watchdog kann und möchte ich als "Notstopp" nicht verwenden. Dann 
würde die TSB-eigene WD-Konfiguration möglicherweise mit dem 
Hauptprogramm kollidieren. TSB erkennt aber, dass es sich um einen 
WD-Reset handelt (MCUSR) und leitet dann sofort zur Anwendung weiter. 
Auf diese Weise ließ sich das Problem mit manchen ATtinys lösen, bei 
denen der vom WD selbst ausgelöste Reset dann den WD-Prescaler 
zurücksetzt, sodass sich eine zu langsame Reset-Routine in einer 
Endlosschleife aufhängen kann. (Das wurde hier sicher schon mehrfach 
diskutiert.)
TSB ist aber immer über Power-On-, Extern- und Brown-out-Resets 
erreichbar. Die entsprechenden Flags bleiben auch unangetastet.

Also ich sehe für Deine Anwendung nur zweieinhalb Möglichkeiten, mit TSB 
zusammenzuspielen:
- Eine andere Leitung nehmen
- Der andere, ständig sendende Controller wird zusammen mit dem 
TSB-Controller resettet und und dessen Timeout ist geringfügig länger 
eingestellt, als der von TSB, er wartet also etwas länger, als TSB, 
bevor er erste Daten sendet
ODER
- Der andere Controller wird zusammen mit dem TSB-Controller resettet 
(muss nur ungefähr stimmen) und sendet aber zu Anfang immer einen 
längeren Low-Pegel auf der One-Wire-Leitung, was TSB dazu veranlasst, 
die Anwendung ohne den regulären Timeout zu starten. Deine Anwendung 
müsste dann ggf. in ihrer Reset-Routine das Ende dieses Low-Pegels 
abwarten, da dies kein gültiges serielles Zeichen ist.


Viel Glück!

Julien