Hi Leute !!! Ich habe mir auf 3 ATTinys (2 x ATTiny45, 1 x ATTiny85), die in verschiedene Anwendungen integriert sind, den Fastboot Bootloader installiert, damit ich auch den Reset-Pin als I/O verwenden kann. Das Ganze funktioniert soweit auch problemlos, allerdings mit einem kleinen Schönheitsfehler: Nur bei einem von drei Anwendungsneustarts (Einschalten der Stromversorgung) startet auch der eigentlich Programmcode. Ansonsten passiert nach dem Einschalten leider NICHTS. Ich schalte dann immer so lange ein und aus, bis das Programm auch tatsächlich ausgeführt wird. Und wie gesagt, nach drei Versuchen klappts dann meistens auch. Woran könnte das liegen? Die Tinys sind alle mit 32,768 kHz (Uhrenquarz) getaktet und der Bootloader ist auf One-Wire (Port PB1) eingestellt. An PB1 hängt eine LED, falls das irgendwie wichtig ist. Das dürfte ja aber eigentlich nicht stören, oder muß der One-Wire-Port frei bleiben? Macht ja keinen Sinn, denn dann gewinne ich zwar den Reset-Pin als I/O dazu, verliere aber den One-Wire-Pin. Also gehe ich mal davon aus, daß das Problem irgendwo anders zu suchen ist (?). Grüße, The SphereX
The SphereX schrieb: > Bootloader ist auf One-Wire (Port PB1) eingestellt. An PB1 hängt eine > LED, falls das irgendwie wichtig ist. Das dürfte ja aber eigentlich > nicht stören, oder muß der One-Wire-Port frei bleiben? frei bleibe nicht. Aber es wäre ziemlich gut, wenn der Pin, solange er am Anfang noch als Eingang fungiert, auch einen gesicherten Pegel hätte. Mit einem Vorwiderstand und einer LED zwingst du dem Pin aber keinen Pegel auf. Hängt der Pin in der Luft, dann wirkt er wie eine Antenne. Ob das Programm den als 0 oder 1 einliest, hängt dann von den Umweltbedingungen wie eingeschalteter Staubsauger in der Nähe ab.
Demnach müßte ich also für die Zeit des Boot-Delays (in meinem Fall die standardmäßigen 330 ms), in welcher der Bootloader den Pin als Input schaltet und auf etwaige Programmierbefehle wartet, dafür sorgen, daß an PB1 ein gesicherter Pegel anliegt? Wie ließe sich das am günstigsten bewerkstelligen? Grüße, The SphereX
Mit 32kHz habe ich den Bootloader nicht getestet. Teste mal als Applikation eine Endlosschleife, die die LED einschaltet und nichts weiter.
Ahh, der Meister persönlich ;-). So, hab's gerade mal getestet. Mit dem Loop funktioniert es komischerweise ohne Probleme, d. h. die LED leuchtet sofort nachdem ich die Versorgungsspannung anlege. Was auch immer Dir das jetzt sagt?! Grüße, The SphereX
Hmmm .... Soll heißen: Es liegt am Programm? Nur das es ohne Bootloader bis jetzt auch ohne diese Startprobleme funktioniert hat. Ich habe lediglich vor kurzem eine kleine Änderung an der Anwendung vorgenommen, die einen zusätzlichen I/O-Pin erfordert. Der Programmcode hat sich dabei aber nur sehr unwesentlich verändert, weshalb ich mal einfach davon ausgehe, daß es nicht daran liegt. Dann ist mir im Übrigen auch noch aufgefallen, daß ich, solange die LED an PB1 angeklemmt ist, auch kein Programm-Update über den Bootloader durchführen kann. Die Ausgabe von FBOOT bleibt dann bei >>> ******* Push Reset Botton ******* COM 3 at 600 Baud: <<< stehen, und es tut sich nichts, außer das die LED flackert. Klemme ich diese ab, funktioniert auch die Übertragung (Connected (One wire)...). Obwohl recht unpraktisch, ist das so sicherlich auf dem Steckbrett noch machbar, in meiner fertig zusammengelöteten Anwendung funktioniert's natürlich nicht. Dementsprechend muß ich den µC für ein Update immer aus dem Schaltkreis entfernen. Grüße, The SphereX
The SphereX schrieb: > Nur das es ohne Bootloader > bis jetzt auch ohne diese Startprobleme funktioniert hat. Der Bootloader verlängert die Resetzeit, vielleicht paßt das Deinem Programm nicht. Du müßtest debuggen, wo Dein Programm hängen bleibt, z.B. kann man an einen Pin eine SW-UART senden lassen. The SphereX schrieb: > Dann ist mir im Übrigen auch noch aufgefallen, daß ich, solange die LED > an PB1 angeklemmt ist, auch kein Programm-Update über den Bootloader > durchführen kann. Die LED belastet die UART zu stark, Du brauchst nen Treiber-FET. Besser nimmt man daher nen Tasteneingang als Boot-Pin.
OK, dann danke ich Dir erst mal für die Infos! Künftig werde ich bei Verwendung des Bootloader darauf achten, nach Möglichkeit keinen LED ober ähnlich beschalteten Pin für das One-Wire-Interface zu benutzen. Rein aus Interesse habe ich mich aber trotzdem mal an dem von Dir vorgeschlagenen Debugging versucht, allerdings nicht per SW-UART, denn dafür fehlen mir leider die Möglichkeiten (Fähigkeiten ;-) ...). Stattdessen habe ich mich einfach zeilenweise vorangearbeitet und jeweils einen END-Befehl mit vorhergehendem Einschalten der LED in meinen Programmcode eingebaut, um zu sehen, wie weit dieser ausgeführt wird. Sehr weit bin ich dabei nicht gekommen, denn bereits nach der Hardware-Konfiguration (ADC, Timer0, Ports) im Programmcode war Schluß, d. h. die Dimensionierung der Variablen wurde schon nicht mehr ausgeführt. >>> $regfile = "attiny45.dat" $crystal = 32768 $hwstack = 36 $swstack = 8 $framesize = 24 Config Adc = Single , Prescaler = Auto , Reference = Avcc Config Timer0 = Pwm , Prescale = 1 , Compare B Pwm = Clear Down Config Portb.0 = Input Config Portb.1 = Output Config Portb.2 = Input Config Portb.5 = Output Pwm0b = 255 Portb.5 = 0 Taster Alias Pinb.0 Portb.0 = 1 ---> BIS HIERHER WIRD DER CODE AUSGEFÜHRT <--- Dim Betriebsstatus As Bit Dim Betriebsminuten As Word Dim Bmtagstart As Word Dim Bmtagende As Word Dim Cfg_clock_hours_d1 As Byte Dim Cfg_clock_hours_d2 As Byte Dim Cfg_clock_minutes_d1 As Byte Dim Cfg_clock_minutes_d2 As Byte Dim Tag As Byte Dim Stunde As Byte Dim Minute As Byte Dim Sekunde As Byte Dim Taster_lang As Bit Dim Tastendruck As Word Dim Timer_counter1 As Word Dim Timer_counter2 As Byte Dim Fade As Byte Dim Pause_led As Word Dim Uldr As Word Dim Uldr_temp As Word Dim Uvcc As Word Dim Uvcc_temp As Word Dim Vcc_messung As Word Dim Messungen As Byte Cfg_clock_hours_d1 = 0 Cfg_clock_hours_d2 = 0 Cfg_clock_minutes_d1 = 0 Cfg_clock_minutes_d2 = 0 Tag = 0 .... >>> Läßt sich aus diesem Ergebnis eventuell etwas ableiten? Grüße, The SphereX
Im Bootloader:
1 | ; remove comment sign to exclude Watchdog trigger: |
2 | ;.equ WDTRIGGER = 0 |
Mach das ; mal weg.
Der Einfachheit halber, d. h. damit ich nicht immer das komplette Programm mit seinen 3445 Byte beim Testen übertragen muß, habe ich nach dem oben genannten Programmbeginn einfach >>> Pwm0b = 1 End <<< eingefügt und den restlichen Code gelöscht, so daß mein Testprogramm quasi nur noch aus dem Konfigurationsteil und dem Anschalten der LED besteht. Damit sind's dann nur noch 175 Byte. Aber auch hier zeigt sich dasselbe Problem: Die LED leuchtet nicht! Die Ausführung bleibt also nach wie vor bei der Variablendimensionierung hängen. Grüße, The SphereX
Ergänzung: Das Programm läuft bis zur Dimensionierung der viertletzten
Variable, die nachfolgenden Befehle werden nicht mehr ausgeführt:
>>>
Dim Uvcc_temp As Word
Dim Vcc_messung As Word
Dim Messungen As Byte
Cfg_clock_hours_d1 = 0
Cfg_clock_hours_d2 = 0
Cfg_clock_minutes_d1 = 0
Cfg_clock_minutes_d2 = 0
Tag = 0
Pwm0b = 1
End
<<<
Grüße,
The SphereX
Hallo, ich weiß zwar nicht genau wie Bascom hier vorgeht, aber die Definition einer Variable ohne das ein Wert zugewiesen wird sollte erst mal keinen Code für den Controller erzeugen, da kann also auch nichts hängen bleiben. Ist ja nur für den Compiler der damit der Variablen einen Speicherplatz zuweist. Sascha
In der Tat, so sollte das wohl sein. Nur funktioniert es eben komischerweise mit Bootloader nur, wenn ich den Dimensionierungsteil weglasse. Ohne Bootloader war es bisher kein Problem. Grüße, The SphereX
Du kannst ja mal das Programm mit dem Bootloader laden und dann mit ISP auslesen und in den Simulator laden. 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.
Hi Peter !!! Nachdem Du ja angemerkt hast, den Bootloader noch nicht mit 32 kHz getestet zu haben, hätte ich eigentlich mein Programm gleich mal mit einer höheren Taktung probieren sollen, dann wäre mir wohl viel Herumprobieren erspart geblieben. Ich habe einen ATTiny45 dementsprechend einfach mal auf die standard 8 MHz (interner RCO) eingestellt, den Bootloader angepaßt und mein Programm dann nochmals damit getestet. Tja, und wie wohl zu erwarten war, gab's mit 8 MHz keine Probleme! Damit ist wohl klar, daß der Bootloader zumindest mit Taktungen <= 32 kHz irgendwie nicht zuverlässig funktioniert. Soll ich die "RJMP Prüfung" jetzt trotzdem noch mal durchführen, oder ist die Taktung tatsächlich schon des Rätsels Lösung? Grüße, The SphereX
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.