Hallo, ich setze auf einem Atmega 328p mit 8MHz den TinySafeBoot Bootloader [1] ein. Auf der Prototypen-Platine habe ich damit im "normalen Modus" über den UART mit 2 Pins (RX und TX) die Programmdateien übertragen. Auf der fertigen Platine steht aber nur ein Pin zur Verfügung, da der Anschluss der Platine mit Servo-Steckern aus dem Modellbau ausgeführt wird - also GND, VCC, SIG. RX und TX im Half-Duplex zusammen zu schalten ist kein Problem [2, Abschnitt "SWART Beispiel"]. Die letztendliche Verschaltung wird nach dem Fastboot TTL/FTDI-Beispiel aus dem Wiki realisiert [3]. Der TSB-Bootloader wird mit dem Kommando "tsb m328p d0d0" erzeugt. Wenn ich diesen flashe kann ich allerdings keine Programm-Dateien mehr übertragen. Das Host-Programm erkennt zwar "ONE-WIRE Interface detected", aber fragt danach nach einem Passwort. Dieses habe ich beim Erstellen des Bootloaders allerdings nicht gesetzt und die Host-Software bricht mit "ERROR" nach leerer Eingabe ab. Ebenfalls fragt "tsb comX I" nach einem Passwort, welches allerdings normalerweise die Bootloader-Informationen ausgeben sollte. Hat jemand ein ähnliches Problem? Auf der Homepage von TSB wird angegeben, dass im invertierten UART Half-Duplex übertragen wird, welches eigentlich mit dem Fastboot Adapter (Widerstand zwischen TX und RX, RX dann direkt nach "Außen") keine Probleme machen sollte. Schöne Grüße [1] http://www.jtxp.org/tech/tinysafeboot.htm [2] http://www.gfai.de/~heinz/techdocs/swart.htm [3] http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger#One-Wire
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
Moin Julien, erstmal großes Lob an deine Software, gefällt mir sehr gut und habe ich mitlerweile auf einigen Controllern laufen. Einen extra Pull-Up setze ich heute abend mal ein, hatte eigentlich angenommen, dass die Leitungen durch die internen Pull-Ups auf einem sauberen Pegel gehalten werden. UART im Half-Duplex aus der Applikation heraus funktioniert ansonsten. Wie ist es eigentlich genau sichergestellt, dass der Bootloader nicht am Anfang auf irgendwelchen Datenwust antwortet? Auf deiner Seite ist ja beschrieben, dass auf ein spezielles Zeichen gewartet wird. Verstehe ich es richtig, dass damit bei einem Power-On-Reset auch der Bootloader in einen Time-Out laufen kann und dann die Applikation startet? Die Platine wird dauerhaft per UART mit einem anderen Controller verbunden sein, der definitiv vor dem Start des TSB Bootloaders schon Daten senden wird. Schöne Grüße, Stefan
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
:
Bearbeitet durch User
Freunde, ich habe das gleiche Problem wie du, fragt nach einem Passwort und erzählt .ERROR. aber alles, was in dem Paket ist erfolgreich ... Bitte respektiert Autoren lag die früheren Versionen des TSB werden es Ihnen danken!
Freunde, ich habe das gleiche Problem wie du, fragt nach einem Passwort und erzählt .ERROR. aber alles, was in dem Paket My TSB ist erfolgreich ... Bitte respektiert Autoren lag die früheren Versionen des TSB werden es Ihnen danken!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.