32 kHz kompatibler Bootloader gesucht

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

@ 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

Woher kommt der Takt? Vielleicht aus RC Oszillator mit hoher Toleranz?

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

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

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

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

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

" ... 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:
> 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

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!).