Hi Leute !!! Ich mußte leider feststellen, daß der "Fastboot" Bootloader von Peter Dannegger mit Taktraten <= 32 kHz nicht zuverlässig funktioniert. Zu diesem Problem hatte sich Peter auf meine Fragestellung hin hier im Forum auch schon geäußert, leider ohne eine konkrete Lösung. Beitrag "Fastboot startet Programmcode nicht zuverlässig" Deshalb habe ich kurzerhand einfach mal "TinySafeBoot" als alternativen Bootloader ausprobiert. Doch auch hier dieselbe Problematik: > ATTiny45 @ 8 MHz: problemlose Funktion > ATTiny45 @ 32,768 kHz (Uhrenquarz): Fehlermeldung bereits beim Aufrufen der Bootloader- u. Device-Infos Mit "TinySafeBoot" bekomme ich meinen Programmcode also nicht mal auf den µC geschrieben, was mit "Fastboot" ja immerhin noch relativ problemlos funktionierte. Es ist leider auch so, daß ich weder in den Infos zu "Fastboot", noch zu "TinySafeBoot", entsprechende Hinweise zu einer minimal erforderlichen Taktfrequenz finden konnte. http://www.jtxp.org/tech/tinysafeboot.htm#tsb-installer Die Seite ist ja recht professionell mit vielen Infos gestaltet, doch auch hier kein entsprechender Hinweis (etwa unter "Voraussetzungen für TSB"). Meine Frage wäre nun, warum die von mir festgestellte Taktfrequenzproblematik nicht thematisiert wird, und ob jemand eventuell noch einen weiteren, 100% 32 kHz kompatiblen Bootloader kennt, den ich alternativ verwenden könnte? Grüße, The SphereX
Was geht konkret nicht? Wo liegt das Problem? Welche Meldungen bzw. Fehlermeldungen?
Fastboot -------- > Kommunikation mit dem Bootloader über FBOOT: keine Probleme > Übertragung meines Programmcodes auf den µC: keine Probleme > Starten der Anwendung (Einschalten der Stromversorgung): nur bei einem von drei Versuchen startet auch tatsächlich mein Programm, ansonsten passiert nichts --> nähere Erläuterungen siehe: Beitrag "Fastboot startet Programmcode nicht zuverlässig" TinySafeBoot ------------ Beispiel: Aufrufen der Bootloader- u. Device-Infos > Kommunikation mit dem Bootloader (ATTiny45 @ 8 MHz): >>> tsb com3:600 I One-Wire interface detected. TINY SAFE BOOTLOADER VERSION : 20140414 STATUS : F0 SIGNATURE : 1E 92 06 DEVICE : ATtiny45 FLASH : 4096 APPFLASH : 3392 PAGESIZE : 64 EEPROM : 256 APPJUMP : FFFF TIMEOUT : 255 > Kommunikation mit dem Bootloader (ATTiny45 @ 32,768 kHz): >>> tsb com3:600 I One-Wire interface detected. Password : Login Password ... OK ERROR. <<< Grüße, The SphereX
> One-Wire interface detected. Da könnte das Problem liegen. Schau dir den Quellcode an und da die Teile die für das Timing des Busses verantwortlich sind. Bei 32 KHz beträgt die kleinste Zeiteinheit 30,4 µs! Könnte schon knapp werden. > ERROR. Ist nicht hilfreich. P. S. Das ist eine grauenhafte Seite mit Augenkrebsgefahr: http://www.jtxp.org/tech/tinysafeboot.htm#tsb-installer
Und was soll ein Bootloader in einem tiny ? Die tinies sind fuer hochvolumige Produkte gedacht, wo es auf jeden cent ankommt. Dort ist das Aufschrauben des Gehauses, wenn es ueberhaupt ein Schraubgehause ist schon zu teuer. Die instruktion des Kunden, zusammen mit dem noetigen Support macht den ganzen Gewinn weg.
@ AVR32 " ... Bei 32 KHz beträgt die kleinste Zeiteinheit 30,4 µs! Könnte schon knapp werden. ... " Auf welchen der beiden Bootloader beziehst Du Dich hier (evtl. auf beide)? Denn wie gesagt, beim Fastboot funktioniert ja kommunikationstechnisch alles problemlos, nur das der Bootloader den Programmcode mal ausführt und mal nicht. Das ist natürlich sehr unpraktisch, denn die Anwendung soll ja laufen, sobald ich den An-Schalter betätige. Aktuell muß ich das leider mindestens drei mal machen, bevor der Bootloader das Programm startet. Laut Peter Dannegger wurde Fastboot übrigens von ihm noch nicht mit 32 kHz getestet. " ... ERROR. Ist nicht hilfreich. ... " In der Tat, aber ausführlicher äußert sich TSB leider nicht. @ hacky " ... Und was soll ein Bootloader in einem tiny ? ... " Was soll ein Bootloader überhaupt auf irgendeinem µC? Da gibt's doch genügend Gründe: vereinfachtes Interface für FW-Updates, Passwortschutz des Programmcodes, Reset-Pin kann als I/O genutzt werden ... In meinem Fall war es wie gesagt letzterer, also ich brauchte den Reset-Pin als I/O. Grüße, The SphereX
The SphereX schrieb: > Ich mußte leider feststellen, daß der "Fastboot" Bootloader von Peter > Dannegger mit Taktraten <= 32 kHz nicht zuverlässig funktioniert. Na ja, du hast festgestellt, daß das bei dir in deiner Schaltung mit deinem Programm nicht funktioniert. Es gibt nach wie vor keinen Hinweis, daß es am bootloader liegt. Die LED hängt ja immer noch am Pin, einen FET zur Entlastung hast du nicht eingebaut, und was genau ein Bascom-Programm zu Anfang macht, was eventuell die Zusammenarbeit mit dem bootloader erschwert, hast du dir im Assemblerlisting auch nicht angesehen. Immerhin hast du ja herausgefunden, daß es mit einem Trivialprogramm auch bei 32kHz funktioniert. Oliver
Woher kommt der Takt? Vielleicht aus RC Oszillator mit hoher Toleranz?
Warum nimmst du nicht einen 4,194304 MHz-Quarz und teilst den im Uhrenbetrieb per Clockprescaler auf 32,768KHz runter? Oder gleich einen Controller, der alles von Haus aus kann. Der hätte allerdings 20 Pins mehr als der Tiny. mfg.
The SphereX schrieb: > @ hacky > > " ... Und was soll ein Bootloader in einem tiny ? ... " > > Was soll ein Bootloader überhaupt auf irgendeinem µC? > > Da gibt's doch genügend Gründe: vereinfachtes Interface für FW-Updates, > Passwortschutz des Programmcodes, Reset-Pin kann als I/O genutzt werden Weiterer Vorteil: Bessere Eignung für Bananensoftware. Wird grün ausgeliefert und reift (durch zahlreiche Updates) beim Kunden... Dadurch kann man sich das Debugen vor der Auslieferung sparen :-) Updates sind relativ einfach möglich, indem man die Kopfhörerbuchse eines Computers als serielle Schnittstelle missbraucht. Das Update wird dann einfach als .wav oder .mp3 ausgeliefert...
@ Oliver Ich habe in erster Linie 3 Dinge herausgefunden, die mich zu der Vermutung gebracht haben, daß es wohl am Takt des µC liegt: > ohne Bootloader, ATTiny45 @ 32,768 kHz: läuft problemlos > Fastboot + ATTiny45 @ 8 MHz: läuft problemlos > Fastboot + ATTiny45 @ 32,768 kHz: Startprobleme Dazu kam dann noch, daß das Ganze mit TinySafeBoot ähnlich aussieht, nur das ich mit diesem Bootloader und der 32 kHz Taktung nicht mal eine Programmübertragung zum µC hinbekomme, sehr wohl jedoch wiederum bei einem Takt von 8 MHz. Diese Ergebnisse sind doch mehr als eindeutig (?), dachte ich zumindest, so daß weitere Nachforschungen erst mal überflüssig sind. Beim TinySafeBoot ist mein eigentlicher Programmcode im Übrigen ja sowieso zunächst nicht relevant, da ich hier wie gesagt bei 32 kHz nicht mal eine vernünftige Verbindung zum Bootloader herstellen kann. @ thomase " ... Warum nimmst du nicht einen 4,194304 MHz-Quarz ... " Ich wollte die Schaltung eigentlich nicht neu bestücken (Uhrenquarz läuft dort ja schon länger problemlos). Wobei ich eben nicht mit derartigen Problemen bei 32 kHz im Bootloader-Betrieb gerechnet hätte. Außerdem takte ich die µC nur ungern höher, als unbedingt nötig, wenn wie hier zur Stromversorgung eine Knopfzelle dient, und damit quasi jedes µA zählt. " ... Oder gleich einen Controller, der alles von Haus aus kann. Der hätte allerdings 20 Pins mehr als der Tiny. ... " Eben! Wäre für meine Anwendung auch eindeutig und sprichwörtlich überdimensioniert (Platz-u. Strombedarf). @ Schreiber " ... Bananensoftware. Wird grün ausgeliefert und reift (durch zahlreiche Updates) beim Kunden ... " Der ist gut, muß ich mir merken ;-). Grüße, The SphereX
The SphereX schrieb: > Außerdem takte ich die µC nur ungern höher, als unbedingt nötig, wenn > wie hier zur Stromversorgung eine Knopfzelle dient, und damit quasi > jedes µA zählt. das macht nicht viel aus, wenn der µC die meiste Zeit im Sleep-Modus ist
Siebzehn Für Fuenfzehn schrieb: > Und was soll ein Bootloader in einem tiny ? [...] Die instruktion des Kunden, zusammen mit dem noetigen > Support macht den ganzen Gewinn weg. Der Bootloader ist ja in der Regel auch nicht für den Kunden. Der ist meist dazu gedacht am existierenden Geräten/Prototypen im zusammengebauten/eingebauten/vergossenen Zustand noch Code- oder Parameteränderungen durchzuführen. Gerade solch kleine Geräte sind meist zu klein um alle ISP-Pins rauszuführen, jedoch eine Zweitverwendung einer existierenden herausgeführten Leitung für einen Halbduplex-Eindraht-Bootloader (und auch zu Debugging- und Meßzwecken während der Entwicklung) ist meist möglich und außerordentlich nützlich. Bei so kleinen kompakten Geräten sogar noch viel mehr als bei großen Platinen wo man eh überall bequem hinkommt.
The SphereX schrieb: > dachte ich zumindest, so daß weitere Nachforschungen erst mal > überflüssig sind. Je nun, das ist alles dein Problem. Du kannst weiter planlos rumraten, und eine Bootloader nach dem anderen ausprobieren, oder du kannst versuchen, das Problem zu verstehen und zu lösen. Ist dein Projekt. Oliver
Wenn du deine Applikation laden kannst mit pedas loader, geht der auch. Wenn eine simple Applikation geladen werden kann und sauber läuft, ist es deine Applikation die ein Problem hat. Wenn sie ohne loader geht, ist dein Problem, dass der loader irgendwelche Ressourcen anders hinterlässt als der reset. Watchdogs, Interrupts, konfigregister. Just my thoughts..
@ dunno " ... Wenn sie ohne loader geht, ist dein Problem, dass der loader irgendwelche Ressourcen anders hinterlässt als der reset. Watchdogs, Interrupts, konfigregister. ... " So etwas in der Art wird's wohl sein. Nur würde das wiederum nicht erklären, warum es mit Fastboot und höhergetaktetem µC funktioniert! Und mein Programmcode, der auszuführen ist, bleibt ja derselbe. Insofern ist es mir nach wie vor ein Rätsel, wieso das Ganze offensichtlich in Abhängigkeit der Taktfrequenz Probleme bereitet. Ich nutze dabei auch zum ersten Mal einen Bootloader, kann hier entsprechend auch auf keine Erfahrungswerte zurückgreifen. Und nach meinem Verständnis "verstoße" ich mit meinem Programmcode auch nicht gegen die zwei einzigen Regeln (Anforderungen an die Applikation), die sowohl für Fastboot, als auch für TinySafeBoot gelten: Zitat: > Die Applikations-Firmware muss bei Adresse $0000 beginnen, und der erste Maschinenbefehl muss ein Sprungbefehl zur eigentlichen Reset-Routine der Applikation sein. (Standard, wenn der Code von einem Compiler erzeugt wurde). > Applikation und Bootloader dürfen zusammen nicht mehr Speicherplatz belegen, als tatsächlich vorhanden ist. (Die TSB-Software zeigt den tatsächlich zur freien Verfügung stehenden Speicherplatz an.) Im prinzip braucht man also beim Programmieren nichts zu beachten, so zumindest deute ich die beiden Anforderungen. Alles andere wäre ja wohl auch kontraproduktiv, denn ein Bootloader sollte schließlich unbemerkt, also quasi unsichtbar, im Hintergrund agieren. Es sollte demnach auch nicht nötig sein, die eigene Applikation, die ohne Bootloader auch absolut fehlerfrei funktioniert, in irgendeiner Form zusätzlich an den Bootloader anzupassen. Und noch mal zur Parallele zu TinySafeBoot. Hier schlägt ja bei 32 kHz bereits ein normaler Verbindungsversuch zum Bootloader fehl, ohne das auch nur ein Bit meines Programmcodes den µC jemals erreicht hat. Dementsprechend hat es hier schon mal definitiv nichts damit zu tun. Sehr wohl aber mit der Taktfrequenz, denn bei höherem Takt funktioniert die Kommunikation. Also ganz egal, wie ich das Ganze auch betrachte, ich bleibe immer wieder an der µC-Taktfrequenz als Problemursache hängen. Grüße, The SphereX
The SphereX schrieb: > Also ganz egal, wie ich das Ganze auch betrachte, ich bleibe immer > wieder an der µC-Taktfrequenz als Problemursache hängen. Das es mit 8MHz funktioniert, ist ein Symptom, keine Ursache. Egal, was du auch schreibst, so lange du die LED nicht ablötest und für einen definierten Pegel am Pin sorgst, ist alles andere egal. Hast du mal nach der Programmierung den Flash ausgelesen und geprüft, ob auch das drinsteht, was drin stehen sollte? Wenn die Hardware garantiert in Ordnung ist, und der Flashinhalt trotzdem nicht stimmt, dann kannst du an den bootloadern zweifeln. Sonst nicht. Oliver
Hallo SphereX,
ich verwende auch ein atTiny85 @8MHz (RC Clock) mit PeDas Fastboot 2.9
und verwende Linux und WinOS Clientsoftware.
Aber, im Gegensatz zu Dir, mit getrennten TX und RX Leitungen, die auf
einen USB Schnittstellenwandler mit FT232RL gehen.
Ich würde die Fusebits umstellen und den atTiny mit 8MHz nach einem
Reset betreiben.
Und im eigentlichen Programm dann über das Register
CLKPR - Clock Prescale Register
den Vorteiler auf einen Wert aus CLKPS3:0 E {1,2,4,..,256} verstellen.
Hi Leute !!! So, ich habe noch ein wenig herumexperimentiert, damit man mir hier nicht etwa noch fehlendes Engagement vorwirft ;-). @ oliverso " ... Egal, was du auch schreibst, so lange du die LED nicht ablötest und für einen definierten Pegel am Pin sorgst, ist alles andere egal. ... " Das hatte ich ganz vergessen zu erwähnen. Ich habe die Schaltung auf dem Steckbrett nachgebaut und die LED dabei von vornherein testweise weggelassen. Das Problem besteht allerdings weiter! " ... Hast du mal nach der Programmierung den Flash ausgelesen und geprüft, ob auch das drinsteht, was drin stehen sollte? ... " Obwohl ich denke, daß sich für mich dadurch keine neuen Erkenntnisse ergeben, habe ich das dann doch mal noch getan und den Flash diassembliert (Siehe Anhang!). Zitat Peter Dannegger: " ... Das erste Wort muß mit dem RJMP zum Bootloader ersetzt worden sein. Und der RJMP direkt unter dem Bootloader muß der Einsprung in das Bascom Programm sein. ... " Ich kenne mich mit Assembler zwar nicht wirklich aus, aber soweit ich das nach dem Überfliegen des Codes beurteilen kann, sind zumindest die erwähnten Jumps dort, wo sie auch sein sollten. Also auch hier kein Hinweis auf einen Fehler! Demnach muß ich auch nach diesen Tests mit Fastboot bei meiner Vermutung bleiben, daß die zu geringe Taktfrequenz ursächlich ist. Was "TinySafeBoot" angeht, so habe ich einfach mal dessen Programmierer Julien Thomas kontaktiert und zu dem Problem befragt. Er hat mir dann freundlicherweise den Sachverhalt folgendermaßen erklärt: " ... also mit 128kHz und 300 Bd ging es gerade noch, wenn ich mich recht erinnere. Bei 32 kHz müsste dann 60 oder 75 Bd noch funktionieren... Auch wäre die zusätzliche Verzögerung, die ich ab Version 20140331 eingebaut habe, um mögliche Instabilitäten auf RXD abzuwarten, mit 32kHz bis zu einer Sekunde lang. D.h. Du müsstest nach dem Controller-Reset und vor dem Senden des ersten Taktzeichens noch mindestens 1 Sekunde abwarten. Das geht dann nur, wenn in Deiner Schaltung manuell resettet wird (die TSB.EXE fügt pauschal nur eine Verzögerung von 1/3 s ein). Also, um Deine Frage zu beantworten: Vielleicht geht's (ich werde mir das bestimmt nochmal ansehen, habe selber eine Uhrenanwendung mit tn45 und 32kHz-Quarz), aber spaßig wird es wahrscheinlich nicht ... " Also lag ich auch hier mit meiner Vermutung goldrichtig. Bleibt also abzuwarten, ob Julien diesbezüglich noch mal tätig wird und entsprechende Anpassungen vornimmt. Falls nicht, so gilt auch für TinySafeBoot: minimale Taktfrequenz für einen stabilen Betrieb >= 128 kHz !!! Vielleicht meldet sich ja auch Peter noch mal zu Wort (?). @ Uwe S. Danke für den Hinweis, aber ich brauche die Uhrenquarz-Taktung eben für die in meinem Programm implementierte Uhr, die auch eine gewisse Ganggenauigkeit haben sollte. Dafür sind die Uhrenquarze nun mal prädestiniert. Grüße, The SphereX
The SphereX schrieb: > Obwohl ich denke, daß sich für mich dadurch keine neuen Erkenntnisse > ergeben, habe ich das dann doch mal noch getan und den Flash > diassembliert (Siehe Anhang!). Als Anhang nutzt das nix. Du musst das ausgelesene Programm mit dem vergleichen, was drin stehen soll. Oliver
Na Du bist ja vielleicht lustig. Wieso nutzt das jetzt nichts, und woher soll ich bitteschön wissen, "was drin stehen soll". Die einzige Anleitung, die ich zu diesem Punkt von Peter bekommen habe, ist die, den Flash auszulesen und nachzuschauen, ob die beiden RJMP Befehle korrekt gesetzt sind. Und genau das habe ich gemacht, mit dem Ergebnis, daß ich keine Auffälligkeiten feststellen konnte. Peter hatte mich ja gebeten, diesen Schritt durchzuführen. Inwiefern ihn mein Ergebnis jetzt bei der Fehleranalyse weiterbringt, kann ich natürlich nicht sagen. Dazu müßte er sich halt noch mal äußern. Grüße, The SphereX
The SphereX schrieb: > Na Du bist ja vielleicht lustig. Wieso nutzt das jetzt nichts, und woher > soll ich bitteschön wissen, "was drin stehen soll". Was ist denn jetzt was von den beiden Dateien? Oliver
Ja gut, hätte ich vielleicht noch etwas aussagekräftiger benennen können. > Original.asm: Flash-Inhalt nach ISP-Übertragung meines Programms auf den µC, auf dem sich KEIN Bootloader befindet > Fastboot.asm: Flash-Inhalt nach Übertragung meines Programms mittels Fastboot auf den mit Fastboot bestückten µC Ein Vergleich der Dateien zeigt dann auch, daß der µC mit Fastboot vor der Ausführung des BASCOM-Codes zunächst ordnungsgemäß per RJMP zum Bootloader umgeleitet wird. Dieser führt dann mein Programm aus. Also alles soweit im grünen Bereich. Grüße, The SphereX
The SphereX schrieb: > Also > alles soweit im grünen Bereich. Eben. Das Anwendungsprogramm ist in beiden Fällen identisch. Also hat der bootloader zumindest schon mal korrekt ge-bootloaded. Bleibt also die Frage, warum der die Anwendung nicht startet. Der bootloader prüft auf Port B0, passt das zu deiner Hardware? Oliver
" ... Bleibt also die Frage, warum der die Anwendung nicht startet. ... " Nur noch mal zur Erinnerung, falls das irgendwie untergegangen sein sollte: Er startet meine Anwendung schon, aber eben nur mit einer "Trefferquote" von 33 %. Mal funktioniert's, dann wieder nicht. " ... Der bootloader prüft auf Port B0, passt das zu deiner Hardware? ... " Das ist korrekt so. Grüße, The SphereX
The SphereX schrieb: > " ... Bleibt also die Frage, warum der die Anwendung nicht startet. ... > " > > Nur noch mal zur Erinnerung, falls das irgendwie untergegangen sein > sollte: Er startet meine Anwendung schon, aber eben nur mit einer > "Trefferquote" von 33 %. Mal funktioniert's, dann wieder nicht. Das ist keine vernünftige Aussage. Denn entweder der µC springt die erste Adresse deines Programms an oder er tut es nicht. Sobald aber der Sprung passiert, ist der Bootloader draussen und spielt keine Rolle mehr. Da ist irgendwas anderes im Gange. Uninitialisierte Variablen oder irgendwas in dieser Richtung. Was ist zum Beispiel mit dem Watchdog? Ist der aktiv?
:
Bearbeitet durch User
The SphereX schrieb: > Nur noch mal zur Erinnerung, falls das irgendwie untergegangen sein > sollte: Er startet meine Anwendung schon, aber eben nur mit einer > "Trefferquote" von 33 %. Mal funktioniert's, dann wieder nicht Also ich hatte das mal, als ich auf nen arm den eingebauten flash-schreiberoutinen nen zu niedrigen Takt gegeben habe. Dadurch wurden die Zellen zu kurz bestromt und waren flüchtig programmiert. Kenne die Mechanismen auf avrs nicht, keine Ahnung obs Sinn macht, aber die sporadische funktionsrate lässt mich dran denken.
@ Karl Heinz " ... Denn entweder der µC springt die erste Adresse deines Programms an oder er tut es nicht. ... " So stelle ich mir das ja eigentlich auch vor. " ... Sobald aber der Sprung passiert, ist der Bootloader draussen und spielt keine Rolle mehr. ... " Eben. Aber die Betonung liegt auf "Sobald". Ich vermute, daß der Bootloader, aus welchem Grund auch immer, den Sprung zu meinem Programm eben nicht immer durchführt. " ... Da ist irgendwas anderes im Gange. Uninitialisierte Variablen oder irgendwas in dieser Richtung. Was ist zum Beispiel mit dem Watchdog? Ist der aktiv? ... " Das Programm läuft ja ohne Bootloader problemlos, wurde von BASCOM also auch ohne Fehlermeldung kompiliert. Und selbst wenn wir mal hypothetisch davon ausgehen, daß eventuell der BASCOM-Compiler einen Fehler erzeugt hat, dann würde das Programm ja in jedem Fall, sowohl mit, als auch ohne Bootloader, und egal bei welcher Taktfrequenz nicht laufen, was es aber bei höherem Takt (z. B. 8 Mhz) mit Bootloader tut. Der Watchdog ist im Übrigen NICHT aktiv. Grüße, The SphereX
hast du mittlerweile mal einen verify gemacht, per bootloader programmierte baugruppe mit dem kompilat? sofern das verify nicht fehlschlägt hat der bootloader seine arbeit korrekt getan. prüfe ob der bootloader vielleicht den watchdog verwendet und schalte ihn sicherheitshalber bei startup deiner applikation aus. irgendwann sagtest du mal, dass eine einfach-applikation auch mit 32khz und pedas loader funktioniert...? also solltest du deine applikation zerlegen, quasi alles abschalten, nur led blink oder so.. flashen, testen. erstes modul an, flashen, testen.. bis du irgendwann ein modul anmachst und es nicht mehr funktioniert. das ist dann das, das eine variable oder register nicht korrekt initialisiert.
" ... hast du mittlerweile mal einen verify gemacht, per bootloader programmierte baugruppe mit dem kompilat? sofern das verify nicht fehlschlägt hat der bootloader seine arbeit korrekt getan. ... " Alles bereits ohne Befund durchgespielt: Siehe Post 03.12.2014 15:06 " ... prüfe ob der bootloader vielleicht den watchdog verwendet und schalte ihn sicherheitshalber bei startup deiner applikation aus. ... " Ich verwende den Watchdog in meiner Applikation nicht, demnach ist er sowieso inaktiv. " ... irgendwann sagtest du mal, dass eine einfach-applikation auch mit 32khz und pedas loader funktioniert...? also solltest du deine applikation zerlegen, quasi alles abschalten, nur led blink oder so.. flashen, testen. erstes modul an, flashen, testen ... " Das habe ich auch schon alles gecheckt, inklusive dem "Zerlegen" meines Programms. Ausführliche Darstellung der Ergebnisse in meinem ersten Thread zu dieser Problematik, der leider auch ohne Lösung im Sande verlief. Beitrag "Fastboot startet Programmcode nicht zuverlässig" " ... bis du irgendwann ein modul anmachst und es nicht mehr funktioniert. das ist dann das, das eine variable oder register nicht korrekt initialisiert. ... " Wenn es denn nur so einfach wäre. Aber ich bin nach wie vor der Ansicht, daß es definitiv nicht an meinem Programm liegt. Auch wenn eine simple LED-AN-Applikation ohne irgendwelche Variablendefinitionen u. Ä. bei 32 kHz mit Fastboot ohne Probleme läuft, meine Anwendung jedoch nicht, heißt das im Umkehrschluß noch lange nicht, daß der Fehler in meinem Programm zu suchen ist, da dieses ja immerhin, und ich wiedrhole es gern noch einmal, bei höherem µC-Takt mit Fastboot und ohne Bootloader ja sowieso, reibungslos funktioniert! Wo soll ich da nach einem Fehler in meinem Code suchen? Es ist wohl vielmehr so, daß Fastboot wie auch immer geartete Probleme mit meinem Programm hat, zumindest bei Taktfrequenzen <= 32 kHz. Das klingt sicherlich sehr merkwürdig, und ich verstehe es ja selbst nicht, aber nur so kann es sein. Und da im Zusammenhang mit dem Thema "Bootloader" immer die Rede davon ist, daß es keiner besonderen Anpassung des eigenen Programmcodes an den jeweiligen Bootloader bedarf, liegt der Fehler, wenn man es überhaupt so nennen kann, eindeutig bei Fastboot, denn auch ich habe nichts anderes gemacht, als dasselbe Programm, welches nun schon seit einigen Monaten (ohne Bootloader) vor sich hin funktioniert hat, jetzt Fastboot zu übergeben. Tja, und plötzlich treten halt die besagten Probleme auf. Wie auch immer, ich glaube, daß ich mit dieser Problematik hier wohl leider nicht weiterkomme. Und ich möchte Eure Nerven ja auch nicht überstrapazieren ;-). Letztlich kann hier wohl nur einer Licht ins Dunkel bringen: Peter Dannegger ....... Grüße, The SphereX
Hm, und könntest du mit dem höheren Takt hochfahren und erst in deiner Applikation auf 32kHz runtertakten? Dann liefe der bootloader mit einer Takt in dem er sich wohlfühlt und funktioniert... Hätte auch noch den Vorteil dass der SW-Download schneller geht.
:
Bearbeitet durch User
Wie ermittelst du so Aussagen wie: zu ca 33% startet es nicht richtig? mach doch mal 100 Starts mit 32kHz und 100 mit höherem Takt! Ich vermute das es bei höherem auch auftritt, nur nicht so häufig. Alternative wenn noch Platz im Flash ist, mach in deinem Programm ganz am Anfang mal n "Softwarereset", also alle Peripherie zurücksetzen ( so viel isses ja nicht ;-) Was auch noch viel bringt, lass mal jemand anderen über deinen Code gehen ( Codereview ) mit Schwerpunkt Initialisierung von Variablen, Arrays etc... Hans
Für eine Uhrenfunktion braucht man tunlichst einen 32kHz-Quarz, aber wieso sollte der µC auch mit dieser Taktfrequenz laufen?
... schrieb: > Für eine Uhrenfunktion braucht man tunlichst einen 32kHz-Quarz, aber > wieso sollte der µC auch mit dieser Taktfrequenz laufen? siehe Datenblatt Device 32 kHz Osc. Type Cap (Xtal1/Tosc1) Cap (Xtal2/Tosc2) ATtiny25/45/85 System Osc. 16 pF 6 pF
@ beric " ... Hm, und könntest du mit dem höheren Takt hochfahren und erst in deiner Applikation auf 32kHz runtertakten? ... " Die Idee an sich ist als Workaround ja gar nicht mal schlecht, funktioniert nur leider nicht. Die 32 kHz sind ja genau genommen 32,768 kHz, also die Frequenz des externen Uhrenquarz. Um Deine Idee umsetzen zu können, müßte der ATTiny45 die Möglichkeit bieten, mit dem internen RCO zu starten und dann per Befehl im laufenden Programm die Taktquelle auf den externen Quarz zu wechseln. Das ist meines Wissens allerdings nicht möglich. @ Hans M. " ... mach doch mal 100 Starts mit 32kHz und 100 mit höherem Takt! Ich vermute das es bei höherem auch auftritt, nur nicht so häufig. ... " Ich hab's jetzt einfach noch mal mit 20 Starts getestet. Das sind zwar immer noch keine 100, aber immerhin schon aussagekräftiger als nur 3 ;-). Dabei bin ich zu folgendem Ergebnis gekommen: > ATTiny45 @ 32 kHz + Fastboot: 10 von 20 Starts erfolgreich > ATTiny45 @ 8 MHz + Fastboot: 20 von 20 Starts erfolgreich Also selbst wenn ich bei 8 MHz noch 80 Versuche mehr mache, wird das an den 100% erfolgreicher Starts wohl nichts mehr ändern. Beim genaueren Betrachten ist mir dann allerdings noch Folgendes aufgefallen: Die 50% bei 32 kHz verteilen sich absolut gleichmäßig, d. h. erfolgreicher und fehlerhafter Start wechseln sich ab. Ob das Zufall ist? Kann's ja eigentlich nur sein, denn wie ist es sonst zu erklären? Irgendwie fast schon unheimlich ;-). Weiter konnte ich beobachten, daß selbst bei den erfolgreichen Start die Zeit, die vergeht, bis mein Programm tatsächlich gestartet wird, von ca. 1 bis 5 Sekunden variiert, wohingegen bei 8 MHz alle 20 Starts auch nach ca. 500 ms erfolgt sind. Ich weiß nicht, inwieweit diese Erkenntnisse jetzt noch irgendjemanden hier zu einem Geistesblitz verhelfen, aber je genauer ich hinschaue, umso merkwürdiger wird das Ganze. " ... Was auch noch viel bringt, lass mal jemand anderen über deinen Code gehen ( Codereview ) mit Schwerpunkt Initialisierung von Variablen, Arrays etc. ... " Also wenn Du das übernehmen würdest ... sehr gerne ;-). Ich habe mein Programm ja wie gesagt bereits debugged, also Zeile für Zeile verfolgt, bis zu dem Punkt, ab dem die Unregelmäßigkeiten auftauchen. Da bleibt dann von den ursprünglichen 3445 Byte Porgrammcode nicht mehr viel übrig. Im Prinzip wird nur der Konfigurationsteil ausgeführt, dann hängt das Ganze (Siehe Anhang!).
Update: TSB-Versionen ab März 2015 können jetzt bis hinunter auf 16 kHz kommunizieren. Danke SphereX für Hinweise und Testing!
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.