-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 18

Thema: Flash-Probleme

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    09.07.2007
    Beiträge
    42

    Flash-Probleme

    Anzeige

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

  2. #2
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.781
    Blog-Einträge
    8
    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

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018

    Re: Flash-Probleme

    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.
    Lieber Asuro programieren als arbeiten gehen.

  4. #4
    Benutzer Stammmitglied
    Registriert seit
    09.07.2007
    Beiträge
    42
    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

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    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.
    Lieber Asuro programieren als arbeiten gehen.

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    09.07.2007
    Beiträge
    42
    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

  7. #7
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.781
    Blog-Einträge
    8
    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:

    http://www.roboternetz.de/phpBB2/zei...=288268#288268

    Gruß

    mic

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  8. #8
    Erfahrener Benutzer Roboter Genie Avatar von m.a.r.v.i.n
    Registriert seit
    24.07.2005
    Ort
    Berlin
    Beiträge
    1.247
    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:
    http://www.roboternetz.de/phpBB2/zei...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.

  9. #9
    Benutzer Stammmitglied
    Registriert seit
    09.07.2007
    Beiträge
    42
    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

  10. #10
    Moderator Robotik Einstein Avatar von damaltor
    Registriert seit
    28.09.2006
    Ort
    Jena
    Alter
    31
    Beiträge
    3.912
    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.
    kleinschreibung ist cool!

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •