Flash-Probleme

[helmut_w]

Hi!

Ich habe gerade _mehrere_ der 135 Threads
mit "Flash-Probs" durchgesehen ... und
leider nichts gefunden. Allerdings ist
es für mich unverständlich, dass z.Bsp.
mehr Umgebungslicht helfen kann! (Da
wird doch das Verhältnis Nutzsignal :
Stör- verschlechtert, ... und das soll
helfen >> verrückt!)

Ich habe hier ein anderes Problem:
Das Flashen funktioniert, natürlich
sind einige CRC- und auch timeout-
Fehler dabei! Das Programm ist (angeb-
lich) korrekt angekommen; leider geht's
aber ab und zu nicht. Allerdings nach
nochmaligem Flashen geht's dann wieder.

(Zuerst dachten wir an eigene Fehler!;((
Aber das gleiche Programm kann nicht 'mal
ok. sein und dann wieder nicht!)

Wir verwenden Akkus, die voll waren. Auch
ist lt. Datenblatt ein Betrieb von unter
3 V, auch beim Flashen, möglich! Und da
waren wir mit 4,8 V weit drüber! (Auch
die Diode ist bei uns überbrückt!)

Übrigens verwenden wir den fertig aufge-
bauten USB-Trans.! Bei Übertragung im
(dunklen) Karton kommen auch c- bzw. t-
Fehler vor; allerdings etwas weniger!
Die meisten Fehler treten bei Beleuchtung
mit Leuchtstofflampen am Abend/Nacht auf!
Die Übertragung kommt aber immer bis zum
Ende!

Beim Betrachten der Schaltpläne komme ich
zu folgender Erkenntnis: Bei der seriellen
Übertragung wird eine Bit-Art (0 oder 1?)
mit 36 kHz "zerhackt" und die andere wird
überhaupt nicht übertragen. (Also nicht
wie z.Bsp. beim (TV-) RC5-Code: kürzere
und längere (36-kHz-) Impulse, die 1er
bzw. Nullen repräsentieren!)

cu Helmut

PS: Weiß jemand, wie beim ASURO die kor-
rekte Programm-Übertragung (beim Boot-
loader) überprüft wird? CRC lässt eine
Quersumme vermuten, aber Mehrfach-Fehler,
die sich kompensieren, sind da 'halt
wieder möglich!)

[radbruch]

Hallo helmut_w

Die Beschreibung deiner Probleme ist wirklich ungewöhnlich, sowas habe ich in den anderen 135 Thread zu diesem Thema auch noch nicht gelesen.

Das Programm ist (angeb-
lich) korrekt angekommen; leider geht's
aber ab und zu nicht. Allerdings nach
nochmaligem Flashen geht's dann wieder.

(Zuerst dachten wir an eigene Fehler!;((
Aber das gleiche Programm kann nicht 'mal
ok. sein und dann wieder nicht!)

Könnte es sein, dass die Probleme nicht vom Flashen verursacht werden, sondern schlicht dein Programm nicht funktioniert? Zeig uns doch mal dein Programm und erkläre uns, was dann manchmal funktioniert und manchmal nicht. Wenn es korrekt angekommen ist, sollte es der asuro auch korrekt ausführen.

Kannst du andere Programme (z.B. den Selbsttest) flashen und wenn ja, funktionieren die dann?

Gruß

mic

[Sternthaler]

Hallo helmut_w,
du fragst wie die Programm-Übertragung überprüft wird.
Die erzeugten *.hex-Dateien sind im sogenannten Intel-Hex-Format aufgebaut.
Hier gibt es eine schöne, kurze Beschreibung zu dem Aufbau.
Da sieht man, das jeweils eine Zeile mit maximal 20 Byte, genau ein Byte als Prüfziffer spendiert bekommt. So weit ich weis darf der Datenblock maximal 16 Byte enthalten.
(Wie gut damit die Fehlererkennung ist, sollte ich eigendlich ausrechnen können. Ist aber leider nicht mehr so.)
Deine Vermutung mit dem CRC war als schon richtig. Allerdings taugt dieses Format nicht zur Korrektur von Fehlern, sondern nur zur Kontrolle.
Dann sendet der Bootloader einfach ein 'das war wohl nix' zurück, wenn die Prüfung fehlgeschlagen ist, und das Flash-Programm gibt ein 'c' aus.

Das 't' kann auch relativ einfach erkannt werden. Die Übertragungsrate beim Asuro ist mit 2400 Baud konstant. Somit ist die maximale Zeit zum übertragen einer Datenzeile aus der *.hex-Datei bekannt. Wenn der Asuro nach dieser Zeit, plus ein bischen Toleranz, nicht mit einem 'Ja, die Daten sind gut', oder eben mit dem Prüfsummenfehler geantwortet hat, kann das Flash-Programm entsprechend das 't' ausgeben und es nochmal versuchen.


Leider habe ich aber auch keine Lösung für dein Problem.
Allerdings sagst du:
"Auch ist lt. Datenblatt ein Betrieb von unter 3 V, auch beim Flashen, möglich!"
Mhhhm, hier habe ich aber gelesen, das das Empfänger-IC sehr kritisch mit der Spannungsversorgung unter 5 V wäre.
Steht aber bestimmt in einem der 137 Beiträgen. Ich habe noch 2 weitere gefunden.

[helmut_w]

Hi!

Danke für Eure Antworten!

Aus "SFH5110-36.pdf" von infineon / Osram:
(Da sind die "Beilagen" ganz gut!)

Kennwerte (TA = 25 °C)/Characteristics
Bezeichnung Symbol Wert/Value Einheit
min. typ. max.
Betriebsspannung VCC 4.5 5.0 5.5 V
----------
ICC max = 5 mA
bei VCC = 5 V, ICC typ = 1,3 mA
.......

Rv <= 100 Ohm (zwischen VCC und Pin 3)
*) only necessary to suppress power supply disturbances
(nur notwendig, wenn - wie beim Asuro - die Vers.-Spg.
durch die Motoren versaut ist!)
(Ende Datenblatt)
-----------------
Hier ist aber lt. Schaltplan R17 = 470 Ohm drin!!!

U_Rv = I * Rv
bei 1,3 mA => 611 mV => 4,8 V - 0,6 V = 4,2 V
" ca. 3 mA => 1.410 mV => 4,8 V - 1,4 V = 3,4 V
----------
Und das ist der "begrabene" Hund!!
_Danke_ für Deinen Hinweis!
"
Mhhhm, hier habe ich aber gelesen, das das Empfänger-IC
sehr kritisch mit der Spannungsversorgung unter 5 V wäre.
"

Bereits bei "Normal"-Betrieb ist die Versorgungs-Spg.
_unter_dem_Mindestwert_ von 4,5 V!

Da muss man was machen: Wir werden wohl den zu großen R
ersetzen! Aber vorher schauen wir 'mal mit 'nem Oszi ...

Meine Erfahrungen werde ich hier posten; aber das dauert,
weil wir uns nur immer mittwochs im Club treffen!

cu Helmut

[Sternthaler]

Hallo helmut_w,
viel Erfolg und mit dem Oska, und einen großen Haufen wichtiger Erkentnisse.
Erfahrungsberichte sind gerne gesehen.

P.S.: Ich kann mit meinem USB-Dingsda gut 1,5 Meter überbrücken. Muss dann aber recht genau gezielt werden. Der RS-232 schafft 'nur' 1,2 Meter.
Wie groß der besagte Widerstand bei mir ist weiss ich nicht. Einfach nach Bauplan zusammengelötet. Also bestimmt auch 470 Ohm.

[helmut_w]

Nachtrag:

Hi radbruch!

Danke für Deine Antwort!

"
Könnte es sein, dass die Probleme nicht vom
Flashen verursacht werden, sondern schlicht
dein Programm nicht funktioniert? Zeig uns
doch mal dein Programm und erkläre uns, ...
"
Du hast leider nicht richtig gelesen!;o((

Das gleiche Prog. "test.c" hat vor 'ner Woche
funktioniert. Dann wurde in die "asuro.c"
das bei "int encoder[2]" vergessene
"volatile" eingefügt und dann nochmals
kompiliert; und da hat nur noch der Motor
gebrummt.

Den Code habe ich leider nicht hier, da er
auf 'nem anderen PC schläft!( Aber er hat
als Kern neben Init(); und EncoderInit();
MotorDir(FWD,FWD);
MotorSpeed(100,100);
while(encoder[0]<200);
MotorSpeed(0,0);
....

Die Einfach-Test-Aufgabe war, nach 'ner
Strecke - hier ca. 40 cm - anzuhalten.

Wir hatten nämlich zuvor anstatt mit '200'
mit '500' experimentiert, was aber nicht
ging. Darauf hatte ich bei Arexx nach-
gefragt und von dort kam der Hinweis mit
dem " _volatile_ int encoder[2]"!

Ein anderes Prog. war ein Versuch die
Funktion 'go()' etwas zu modifizieren:
Wir hatten den Asuro mit 'ner "for"-
Schleife beschleunigt; allerdings hielt
er zwischendrin jedesmal kurzfristig an.
Da haben wir das 'MotorSpeed(BREAK,BREAK);'
und das 'Msleep(1);' rausgeschmissen und
ein 'go1()' draus gemacht.
Beim ersten Versuch fuhr er phantastisch
geradeaus und kam fast zum Ausgangspunkt
zurück! (mit einer Beschleunigung in
Vorwärts- und Rückwärtsrichtung!)

Ne Woche später fuhr er 'nen großen Bogen
und der Ausgangspunkt wurde bei der Rück-
fahrt um fast einen Meter verfehlt (bei
einer Strecke von 3 Metern!)

Ein drittes Prog. funktionierte beide Male
korrekt!

Für mich sind das nicht erkannte Übertra-
gungsfehler, die das Programm manchmal
etwas verfälschen und manchmal überhaupt
nicht mehr funktionieren lassen!

cu Helmut

[radbruch]

Hallo

Du hast leider nicht richtig gelesen!

Das kann ja mal vorkommen, ich bitte um Nachsicht. Zu deinem Problem kann ich nur noch soviel sagen: Ich lese hier seit einem halben Jahr täglich mit und habe noch nicht gelesen, dass ein vom asuro als übertragen gemeldetes Programm nicht funktioniert. Mit einer Ausnahme! Das war inkas asuro, dessen ATMega war wohl defekt. Aber da ging dann gar nichts mehr:

https://www.roboternetz.de/phpBB2/ze...=288268#288268

Gruß

mic

[m.a.r.v.i.n]

Hi,

...dass ein vom asuro als übertragen gemeldetes Programm nicht funktioniert.

MIr selbst ist es auch schon gelegentlich passiert, dass ein geflashtes Programm nicht funktionierte. Nach nochmaligem Flashen ging es dann.
Vor längerer Zeit gab es auch mal dazu einen Thread:
https://www.roboternetz.de/phpBB2/ze...ag.php?p=90932

Seit ich den IR RS232 Transceiver modifiziert habe, ist das Thema gegessen. Es gibt seitdem praktisch keine Übertragungsfehler mehr, volle Akkus natürlich vorausgesetzt.

[helmut_w]

Hallo
und zuerst 'mal ein großes Dankeschön für Eure Mühe,
die Ihr Euch gemacht und diesen Thread mit Eurem
Wissen gefüllt habt!

Auch ich habe -mit Eurer Hilfe!- mir auch noch so'ne
Zusammensammenfassung erstellt:

Mit Sternthalers Hilfe habe ich mein Wissen über das
Intel-hex-Format aufgefrischt!)
Allerdings hat das im engeren Sinne mit der Prog.-
Übertragung vom PC zum Asuro nichts zu tun, denn
dafür ist doch das Flash-Prog. mit dem Bootloader
zuständig. Da sollte Henk von Arexx, der dieses Prog.
kennt, eigentlich 'was dazusagen! (Alternativ werde
ich mir 'mal den Link auf einen Bootloader vormerken,
den ein Privat-Profi geschrieben hat. - Vielleicht
reichen meine C-Kenntnisse zur Analyse der Fehler-
erkennung darin aus? *)

*) Vielleicht kann mich da auch der eine oder
andere hier unterstützen, denn ich habe von Euch
schon ganz Tolles gesehen, das ich selbst _so_
noch nicht programmiert haben könnte! (Aber ich
arbeite dran!)

mic, der radbruch, und auch einige andere denken
wie ich: Zuerst sucht man den Fehler 'mal zuerst
bei sich selbst!) ... und dann freut man sich
tierisch, wenn's denn nicht so ist!) (z.Bsp.,
wenn bei m.a.r.v.i.n das Gleiche auch schon
passiert ist!)

Viele weisen immer wieder auf die Versorgungs-U
hin und ich denke, dass die beim SFH5110-36 im
Asuro wohl die kritische Stelle sein könnte.
(siehe mehr hierzu weiter oben!)

Eine Verbesserung könnte ein zusätzlicher Akku
sein; denn da bekommen wir die 6 V wie bei
Batterie-Betrieb! Damit wäre dann von Haus aus
eine höhere Spg. auch am IR-Empfänger vorhanden.
((Allerdings kommen bei den meisten von Euch
recht selten Fehler beim Prog.-Flashen vor, so
dass dies dann doch nicht unbedingt an einer
zu niedrigen U_Batt liegen muss, oder!?))

Eine Idee hätte ich noch: Wenn ich, zusätzlich
zum "normalen" Prog., ein Modul zur Rücküber-
tragung des Flash-Speichers an den Anfang setze.
Da kann ich dann die Daten mit denen vergleichen,
die in der hex-Datei gespeichert sind. ...
Hat jemand einen Tipp hierfür?

Noch einen schönen Sommer-Abend!

cu Helmut

[damaltor]

hmm... sowas sollte dann allerdings in assembler programmiert werden, um platz zu sparen. möglich ist es allerdings wohl.
allerdings würde die prüfung dann genauso lang dauern wie das flashen.

ich empfehle dir, deinen atmega zu tauschen: schreib eine englische email an
info@arexx.nl
und erkläre dein problem. der support ist sehr nett und ersetzt dir dern prozessor bestimmt.

ich hatte jetzt in der zeit den ich den asuro schon habe 1x das pech, das ein geflashtes programm nicht ausgeführt wurde. ich hab es einfach ignoriert. wenn das allerdings häufiger vorkommt, dann sollte man da was gegen tun.