Hi, ich möchte einen ATmega168PA mittels RS485 auch "aus der Ferne" mit neuer Software befüllen können. Als RS485 Treiber verwende ich auf beiden Seiten einen Max485ECPA. Die Richtungsumschaltung ist am ATmega am Pin D.4 (XCK) angeschlossen wie laut Datenblatt vom Bootloader gefordert. Das Funktioniert auch, ein mittels ICP geflashtes Testprogramm Legt den Pin auf High und schiebt mir Daten rüber. Die Gegenstelle PC-Seitig ist ein FT232RL ebenfalls mit Max485 Chip. Die Datenrichtungsumschaltung ist da auch angeschlossen an einem Cbus-Pin, dieser ist als TXDEN konfiguriert. Funktioniert alles, auch der Loopback test geht. Dabei schickt der ATmega alles was er bekommt nach ende der Übertragung wieder zurück. Der Bootloader weigert sich allerdings standhaft auf die gesendeten "UUUU" zu reagieren. Habe nur ich das Problem oder ist das schon mal jemandem auch passiert? Grüße Rolle
:
Verschoben durch User
Hallo Rolle, sendest Du nur die UUUU's oder auch ein anderes Zeichen im Anschluss? Im RS485 Modus muss nach den UUUU's ein (beliebiges) anderes Zeichen gesendet werden, da der Bootloader bei einer halb-duplex RS485 Verbindung - im Gegensatz zu voll-duplex RS232 - nicht einfach etwas senden darf, sobald er die UUUU's erkannt hat. Daher das andere Zeichen. Siehe auch den Abschnitt im Infosheet dazu: "The non-RS485 bootloader versions wait for the 'U' characters for connecting and after baud rate adjustment and checking some 'U' characters, the welcome message and prompt is sent directly. This leads into trouble on halfduplex systems, hence the RS485 bootloader versions wait for the 'U' characters and do the baud rate adjustmetn and checking, but wait for one other character than a 'U' and after receiving this other character, the RS485 direction is changed and the welcome message is sent." Hope that helps... ER!K von chip45 -- http://www.chip45.com
Hi Erik, ich verwende euer Uploadtool, Haken bei RS485 ist selbstverständlich gesetzt. Auch mittels einem Terminalprogramm habe ich das schon getestet. Ich sende "UUUUUUUI". Das Zeichen nach den Us soll dem Chip ja signalisieren das er jetzt senden darf. Soweit habe ich das Datenblatt verstanden. Trotzdem kommt aus dem Chip nix raus. Auch mit einem Monitorprogramm für die Serielle habe ich schon reingeschaut. Es kommt nix zurück. Ich werde weitere Prüfungen machen, also ob der ATmega den Umschaltpin für die Datenrichtung korrekt bedient. Getestet mit ATmega 168PA und ATmega88PA. Meine Testprogramme laufen korrekt und senden, die RS485 Sache sollte eigentlich ok sein. Ich habe zuerst ehrlich gesagt auf einen Fehler auf meinen Leiterplatten getippt. Da reicht ja schon eine abgehauene Lötzinnkugel oder so was und man sucht sich nen Wolf... Hast du eventuell nen Tip oder einen Testaufbau den ich nachbauen kann? Grüße Rolle
Es gab da mal ein Problem mit dem Atmega2561 Board: Auf dem Board ist der Direction Pin des RS485 Treibers mit PD.4 des Atmega2561 verbunden. Der chip45boot2 erwartet den Direction Pin allerdings an XCK1, was beim Atmega2561 PD.5 ist! Nachdem PD.4 und PD.5 gebrückt sind, funktioniert der Bootload per RS485 wie erwartet... Evtl. ist das hier ein ähnliches Problem?
http://www.chip45.com/products/crumb2561-4.0_avr_atmega_modul_board_atmega2561_usb_rs485.php War das hier.
Hi Thorsten, das Board das ich verwende ist ein Selbstgeätztes. Bei mir hängt der Umschalter an PD4, das ist der XCK Pin. Da habe ich mir beim Layouten extra eine Notiz gemacht damit ich das nicht vergesse. Was für ein RS485 Modul wurde verwendet auf der PC seite um den Bootloader anzusprechen? Ich baue mir gerade ein ganz einfaches zum Testen. Beschaltung aus dem Datenblatt des FT232RL, keine Optokoppler zur Potentialtrennung. Zum Testen sollte das reichen. Wenns damit auch nicht geht bin ich mit meinem Latein am ende. Grüße Rolle
Ich verwende normal so ein FTDI USB RS485 Kabel mit eingespritzter Elektronik, allerdings "original" von FTDI oder einen ganz billigen Delock USB-RS485 Adapter auch mit FTDI Chip, ich mein von Reichelt. Geht beides einwandfrei. Wie siehts bei dir mit Masse und Terminierung aus?
Hi Thorsten, also Masse ist natürlich verbunden da die RS485 Chips ja nur einen begrenzten Spannungsbereich vertragen. Bei sehr langen Strecken im Industriebereich bin ich es sonst gewohnt das die Signale per Optokoppler getrennt werden. Damit ist man Potentialverschleppungen los. Terminiert ist mit 120 Ohm an beiden Enden (Metallfilmwiderstand, kein gewickelter). Getestet habe ich die qualität der Übertragung schon mal spaßeshalber mit 50m Netzwerkleitung dazwischen. Als Test ein paar WS2812B LEDs an ein ende ans andere den LED-Player. Da rennen 800Khz über die Leitung und das juckt den MAX485 nicht geht einwandfrei. Flanken sehen laut Oszi auch gut aus. Platine für den RS485 Wandler ist grade fertig geätzt jetzt wird gelötet. Grüße Rolle
Glaube in diesem Fall eher nicht an ein Hardware Problem. Trotzdem hat failsafe Terminierung schön Wunder gewirkt. Ne Mütze Schlaf und morgen nochmal alles durchgucken könnte auch helfen ;)
@Thorsten, danke für den Tip das Probiere ich mal die winzigen SMD-Widerstände kann ich ja zum testen mal zwischen die Leiterbahnen klemmen. Grüße Rolle
Wenn du ein Oszi o.ä. zur Hand hast, check mal was der DE Pin deines MAX so macht während du a) normal Daten schickst und vor allem empfängst b) du versuchst, mit dem Bootloader Kontakt aufzunehmen Ich vermute allerdings, dass dein Problem ein anderes ist: Der Bootloader lauscht ja nur sehr kurz nach dem Start/ Reset, ob ihm jemand was schicken will, bevor er das Hauptprogramm läd. Du musst also erstmal einen Reset auslösen! Das kann per Software passieren (da gibts im Tool ein Feld wo man eine Message definieren kann, muss man natürlich selbst implementieren... der Watchdog ist dein Freund!) oder von Hand. Ich erinnere mich auch noch, dass es auch möglich ist, den Bootloader zu "schnappen", indem man die Versorgung erst einschaltet, während das Chip45 Tool schon angefangen hat ihn zu suchen. Evtl sehr oft probieren, irgendwann wirds "grün". Da gibts doch auch noch so ein Feld "wait" oder "delay" oder sowas, das war auch durchaus wichtig und man musste etwas rumprobieren bis es zuverlässig klappte. Ist lange (und viele neue Projekte her...) Wobei... wenn da NUR der Bootloader drauf ist, sollte er warten... ausprobieren! Ansich ist der Chip45 Bootloader sehr gut, habe ihn vor einiger Zeit in einigen Geräten "verbaut", und nach ein paar Startschwierigkeiten lief der sehr zuverlässig...
Hi an alle, also das Problem hat sich erledigt, es war tatsächlich Hardware (und ich war schuld). Der Pullup und Pulldown der auf dem Bus für definierte Pegel sorgt wenn kein Sender aktiv ist war schuld. Die waren zwar dran, aber Aufgrund eines Layoutfehlers meinerseits Vertauscht. B hing auf VCC, A auf Gnd. Grade am Prototypen die SMDs mal runtergelötet und durch bedrahtete Widerstände ersetzt. A auf VCC und B auf GND. Läuft sofort und der Bootloader connected. Datenübertragung funktioniert Problemlos. Drauf gekommen bin ich beim messen am ATmega mittels Oszi, ich wollte sehen ob der uC den MAX485 korrekt umschaltet. Das machte der auch aber da es ja eine Totzeit gibt (wenn auch sehr kurz) war der Bus in einem seltsamen Zwischenzustand in den paar Mikrosekunden. Das sorgte dafür das am PC seltsame Zeichen angekommen sind (Punkte usw.) Damit klappt die Erkennung natürlich weder mit dem Windowsprogramm von Chip45, noch mittels Terminal kommt da verwertbares an. Das LAyout wird nun geändert und ich kann das endlich "richtig" herstellen und nach Funktionsprüfung der restlichen Hardware verbauen. Danke an alle die bei der Fehlersuche geholfen haben, besonders an Thorsten der mich mit seinem Tip mit dem Oszi den DE Pin des Max mal anzusehen auf die richtige Spur gebracht hat. Grüße Rolle
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.