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
Angehängte Dateien:
-
BootloaderInterface.png
54 KB -
RS232__tx_A5_rx_AA_.png
8,8 KB
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
BTW: da fehlen noch die Abschlußwiderstände für den CAN. R11 mußt du auch an die Baudrate anpaßen. 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
Hallo Peter, das hatte ich bereits geändert, der ONEWIRE-Mode is "hart" includiert, aber mit unterschiedlichen Pins - unten die angepassten Abschnitte aus Deinem Bootloader. Mehr ist doch nicht zu ändern oder? Ich stehe momentan echt vor einem Rätsel. MFG Andy -------------------------------------------------- Onewire Mode einstellen -------------------------------------------------- /* .if SRX == STX && SRX_PORT == STX_PORT .equ ONEWIRE = 3 .else .equ ONEWIRE = 0 .endif */ .equ ONEWIRE = 3 //Update Andy --------------------------------------------------- Portpins festlegen --------------------------------------------------- .equ STX_PORT = PORTD .equ STX = PD4//PD1 .equ SRX_PORT = PORTD .equ SRX = PD2//PD0 .if ONEWIRE .macro IOPortInit sbi SRX_PORT, SRX sbi STX_PORT, STX sbi STX_DDR, STX .endmacro .macro TXD_0 cbi STX_PORT, STX .endmacro .macro TXD_1 sbi STX_PORT, STX .endmacro .macro SKIP_RXD_0 sbic SRX_PIN, SRX .endmacro .macro SKIP_RXD_1 sbis SRX_PIN, SRX .endmacro
Hi. Funktioniert der Bootloader wenn du die CAN Bustrieber weglässt und den AVR direkt mit dem MAX232 verbindest? Gruß Stefan
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.
Als UART würde ich bei der Antwort auf dem Screenshot auch eine 0x55 sehen. Das Startbit ist viel zu lang.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.