Hallo zusammen,
ich bin gerade dabei den Bootloader von P.Dannegger zu testen.
Dabei fiel mir auf, daß das SW-Update via Bootloader sehr oft nicht
klappt, da scheinbar falsche Werte vom µC empfangen werden (mal
ungültige BL-Version, mal CRC-Fehler usw.).
Verwendet wird ein MAX232CPE. Vom dem geht es via PCA82C250 auf den
CAN-Bus und von dort über einen weiteren PCA82C250 an einen Mega8, also
OneWire. (siehe Schaltplan)
Da die Verwendung verschiedener UART-Settings (Baudrate 1200 bis 115200,
Stopbits etc.) sowie Kondensatoren am MAX232 (1µ und 10µ) keine
Besserung brachte und der Fehler an 2 verschiedenen PCs sowohl mit einem
USB-RS232-Adapter als auch einem "echten" COM-Port auftritt, habe ich
mit einem Terminalprogramm den Verbindungsaufbau mit dem Bootloader
Schritt für Schritt nachvollzogen.
Hier zeigte sich, daß öfters scheinbar falsche Werte vom µC gesendet
werden.
Eine Stelle wo es z.B. oft klemmt, ist nach dem CONNECT, wenn der µC auf
das vom Rechner gesendete COMMAND (0xA5) mit SUCCESS (0xAA) antwortet.
Das Terminalprogramm empfängt dann statt des "AA" oft ein "5F".
Da ich einen Hardwarefehler vermute, habe ich mit dem Oszi die
RS232-Leitungen am MAX (Pin 13/14 zum PC) aufgezeichnet.
Wenn ich die Bits auszähle, kann ich keinen Fehler entdecken! Die Pegel
passen auch. Auf das "geechote" COMMAND (0xA5) folgt das SUCCESS (0xAA)
vom µC, obwohl vom Terminalprogramm ein "5F" angezeigt wird (siehe
Osziplot). Das gleiche Verhalten ist mit verschiedenen
Terminalprogrammen zu beobachten.
Jetzt bin ich echt ratlos :-(
Was mir noch aufgefallen ist:
Es ist oft so, daß es beim ersten Verbindungsaufbau das falsche "5F"
kommt und bei weiteren Versuchen dann stattdessen korrekt das "AA"
empfangen wird. Auch scheint der "echte" COM-Port tendentiell
besser zu funktionieren als der vituelle Port mit USB-Adapter.
Hat jemand von Euch vielleicht noch einen hilfreichen Tip?
MFG
Andy
Andy W. schrieb:> Hat jemand von Euch vielleicht noch einen hilfreichen Tip?
Stelle mal den Sample-Point (so wie bei CAN üblich) auf 70-80%.
Mal im Ernst: du kannst doch nicht erwarten daß bei einem
CAN-Transceiver etwas sinnvolles herauskommt wenn Du es mit einem UART
auswertest.
Gruß Anja
Hallo Anja,
ich verstehe nicht, worin das Problem bei UART über CAN bestehen soll.
Ich nutze den CAN nur als physikalisches Medium, der PCA82C250 ist ein
reiner CAN-Treiber. Wo soll der SamplePoint eingestellt werden???
Wie im Plot erkennbar, ist auf der RS232 ein sauberes 0xAA vom
Controller zu sehen, am PC kommt aber etwas anderes an.
Dieses Verhalten würde ich gerne verstehen.
Der Bus ist korrekt abgeschlossen, das ist im Schaltplanaussschnitt
leider nicht ersichtlich.
MFG
Andy
Guck mal im AVR Datenblatt nach den Baudratenbeispielen. Da steht auch
die rein rechnerische Fehlerrate bei die z.B. bei 0,2% liegen kann was
für einen Bootloader vermutlich schon zu viel ist - Störungen von Außen
kommen da ja noch zu...
Abhilfe schaffen hier Baud-Quarze mit krummen Werten wie 7,3728 Mhz, da
passt es genau und der (rechnerische) Fehler geht auf Null.
Gruß Noonien
Hallo Noonien,
das mit der nicht ganz passenden Baudrate hatte ich auch schon vermutet.
Ich weiss aber nicht, ob ich die Beispielrechnung auf Peters Bootloader
anwenden kann, da dieser nicht die Hardware-UART des µCs nutzt, sondern
beliebige Portpins.
Auch macht mich stutzig, daß das Verhalten eigentlich mit allen
Baudraten auftritt. Der Plot in meinem Post wurde mit 115200Bd gemacht.
Wenn ich mir die Bitbreite da anschaue (Cursor), sehe ich keine
gravierenden Abweichungen vom Sollwert bzw. timingmäßig im Vergleich zu
dem, was vom PC kommt.
Habe ich das falsch interpretiert?
Werde das mit dem Quarz auf jeden Fall testen!
MFG
Andy
Ist Dir eigentlich klar, dass das mit
RS232 <-> CAN <-> RS232
absoluter Schrott ist. Auf RS232 kann gleichzeitig gesendet und
empfangen werden, auf CAN nicht.
Deine gesendeten Daten müssen mit den empfangenen zwangsweise
interferieren.
Das kann so nicht gehen !!!
mal bei Voll-Duplex und Halb-Duplex nachschauen !!!
Gruss Klaus
Hallo Klaus,
mir ist der Unterschied zwischen Halb- und Vollduplex durchaus vertraut
:-)
Das sich hier RS232 und CAN unterscheiden, bedeutet aber nicht, dass es
"absoluter Schrott" ist.
Sowohl das PC-Downloadprogramm als auch der µC bekommt die gesendeten
Daten über den RX-Pin vom PCA82C250 als Echo zurück und
verwirft/inoriert diese. Es ist nur sicherzustellen, daß während des
Downloadvorganges kein anderes Programm über RS232 oder ein anderer
Controller über CAN sendet.
Wo ist also das Problem?
Wie auf dem Plot zu sehen ist, gibt es keinerlei Kollisionen, wenn das
falsche Zeichen empfangen wird. Es deutet eher auf ein Timingproblem
hin.
MFG
Andy
Sind noch irgendwelche anderen Busteilnehmer während der seriellen
Übertragung am Bus? CAN-Devices könnten einen Error Frame werfen, weil
das, was Du da sendest, natürlich nichts mit CAN zu tun hat. Und ein
Error Frame versaut Dir Deine Übertragung.
fchk
Hallo Frank,
es hängen nur die beiden Treiber am CAN, also keine Errorframes...
Das Ganze befindet sich zu Testzwecken auf einer Platine, der Bus ist
nur wenige Zentimeter lang :-)
MFG
Andy
Das Timing im 1- oder 2-Draht Modus ist unterschiedlich.
Im 2-Draht Modus wird schon gesendet, ehe das empfangene Stopbit zuende
ist.
Und dadurch geht Halb-Duplex nicht.
Du müßtest die Defines so ändern, daß zwar 1-Draht benutzt wird, aber
auf unterschiedlichen Pins.
Peter
vielleicht ist die Verzögerung beim ersten Bit zu lange evtl. schaltet
sich der CAN Baustein schlafen. Probiere mal eine sehr langsame
Übertragungsrate aus oder wie Stefan schrieb mal ohne die CAN Treiber
probieren.
Hallo zusammen,
ich bin nun endlich bei dem Problem weitergekommen:
Offensichtlich interpretiert das UART des PCs die empfangenen Bits
falsch, weil die Antwort des µCs zu schnell kommt. Damit meine ich nicht
die Baudrate, sondern die Zeitspanne nach dem Empfang des Kommandos bis
zum Senden der Antwort.
Ich habe jetzt in der "message.inc" bzw. "main_ok:" vor dem "rcall
putchar" zusätzlich ein "rcall wait_bit_time" eingefügt.
Nun funktioniert es reproduzierbar :-)
Erklären kann ich es mir nicht so richtig, aber vielleicht lässt sich
ein Fachkundiger zu einer plausiblen Erklärung hinreissen...
Danke nochmals an P.Dannegger!
MFG
Andy
Pruefe mal, ob dein MAXel sowas wie einen Power Down Mode enabled hat.
Das hat mich vor kurzem auch mal geaergert (und Stunden gekostet).
Wenn (ich glaube um die 20 Sekunden) nichts uebertragen wird,
dann ist der Chip eingeschlafen. Beim ersten Bit ist er dann wieder
aufgewacht. Das Bit war dann aber falsch / kaputt, und es kam dann zu
kaputten Zeichen, weil die Bits verschoben waren...
(ich hatte aber einen MAX3225ECPP o.ae.)
Power Down Mode:
Soweit ich das aber im Datenblatt sehe, gibt es sowas beim MAX3232CPE
nicht.
Du hast auch genau diesen im Einsatz (und nicht nur im Schaltplan) ?
Hallo Martin,
es ist genau der MAX232CPE wie im Schaltplan.
Vielleicht erwartet das UART PC-seitig einen kontinuierlichen
Datenstrom, d.h. die zurück-geeochten Daten und die Antwort des µCs
müssen direkt aufeinanderfolgen. Passt das Timing nicht ganz, kommt es
zu Bitverschiebern bei den Bytes von µC (die geechoten Bytes vom PC
werden ja IMMER korrekt empfangen)
Durch die jetzt eingefügte Wartezeit ist die Spanne zwischen dem letzten
Stopbit und dem nächsten Startbit scheinbar so groß, daß die
"Synchronisation" PC-seitig immer korrekt erfogt.
Aber die ist nur eine These...
BTW:
Ich verwende momentan den USB-RS232-Adapter. Mit der echten seriellen
konnte ich noch nicht testen.
MFG
Andy
schau auch mal im Gerätemanger beim jeweiligen Gerät unter der
Registerkarte Energieverwaltung: Der Computer kann das Gerät ausschalten
um Energie zu sparen. Dort löscht du dann den Hacken damit der USB-RS232
Adapter bzw. die serielle Schnittstelle nicht schlafen geht.
Andy W. schrieb:> Offensichtlich interpretiert das UART des PCs die empfangenen Bits> falsch, weil die Antwort des µCs zu schnell kommt. Damit meine ich nicht> die Baudrate, sondern die Zeitspanne nach dem Empfang des Kommandos bis> zum Senden der Antwort.
Du hast aber nicht die PC-UART auf 2 Stopbits eingestellt?
Peter
Hallo Peter,
da ich Deine fboot-Applikation unverändert nutze, sollte das Ganze
demnach mit 1Stopbit laufen.
Ich hatte jedoch mit Brays Terminal alle Stopbit-Varianten
durchprobiert-das Verhalten war ähnlich bescheiden.
Erst seit dem Einfügen der zusätzlichen Wartezeit funktioniert es.
Wie von Dir schon angemerkt, bedeutet dies nichts anderes als eine
Änderung von ein auf zwei Stopbits auf der µC-Seite.
Keine Ahnung, wo das Problem steckt.
MFG
Andy
BootloaderInterface.png
(54 KB)
RS232__tx_A5_rx_AA_.png
(8,8 KB)
