Fastboot startet Programmcode nicht zuverlässig

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

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

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

Hat leider nichts gebracht.

Grüße,
The SphereX

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

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

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