Hallo allerseits Ich habe das Problem, das mein Pollin AVR-NET-IO Bausatz von selbst seine IP-Generierung ändert. Das ganz tritt nicht nachvollziehbar sporradisch von selbst auf. Grundsätzlich geht das Board, aber mal ändert sich die IP mal die Netzmaske oder auch schon mal der Gateway. Auch geschah es, das das Board weder mit IP noch RS232 erreichbar war. Was ich bereits gemacht habe. Spannungsversorgung OK. 5,08V & 3,43V Durchgeführte Maßnahmen: Board vom 30.Juli 2012, Bausatz vollständig(FW1.03). IP-Einstellungen ändern sich gelegentlich von selbst! 1*gar nicht mehr erreichbar.(gleich mit Bausatz 6Mon. älter) Dann per ISP-Ponyprog bootloader.hex und Firmware(Netserver) programmiert. Lief dann für ca.2Tage. Erneut IP-Generierung (diesmal GW anstelle NETMASK) von selbst geändert. Mit Ponyprog Prozessor kpl. gelöscht. Bootloader.hex -> Firmware(Netserver[FailSafe-Mode]-> MAC mit AVR-NET-IO-MacSet.exe korrigiert. IP Generierung erneut eingestellt. 08.08.2012 z.Z. Testlauf. Sind diese Fehler anderweitig aufgetreten und was kann zur Beseitigung durchgeführt werden ? Gruß Martin
Hallo, dies ist leider eine bekannte Fehlfunktion. Bausatz auseinandernehmen, vollständig wiedereintüten und mit Anleitung vollständig zurückschicken. Kein Problem.
Such Dir die Datenblaetter von Prozessor und ENC. Rueste die dort vorgeschriebenen Stuetzkondensatoren nach. (die Pollin weggelassen hat) Danach gab es bei mir keine Probleme mehr. fonsana
> Martin Hofmann schrieb: > > Grundsätzlich geht das Board, aber mal ändert sich die IP mal die > Netzmaske oder auch schon mal der Gateway. > Auch geschah es, das das Board weder mit IP noch RS232 erreichbar war. > Hi Martin, verstehe ich richtig, Du machst DHCP mit dem Board?
Hi allerseits @Kundendienst Sehr krativ aber nutzloser Beitrag, da ich ja die abgezwickten Beinchen nicht mehr dranscheiden kann. @fonsana Das werde ich gleich mal durchführen/prüfen. Insgesamt scheint mir der Pollin Entwurf ein Bananen Produkt zu sein. Frucht reift beim Kunden. z.B. Reset ist bei ATMega16 und ENC28J60 nicht verbunden. OK. 5V & 3,3V, aber eine Diode dazwischen mit Kathode an Reset vom AVR bereinigt das. @w3llschmidt Ich habe rein gar nichts von DHCP geschrieben. Das Board wechselt ohne weiteres Zutun von selber die IP-Generierung. Das ist einer der Fehler.
Hatte ich auch, je ein 100nF SMD zwischen VDD und VSS und gut war's (und auch noch einer zwischen AREF und GND)
Ich glaube mich zu erinnern, dass es 6 oder 8 C's waren. Dazu gibt es hier oder auf der Mailing Liste von www.ethersex.de eine lange Diskussion. fonsana
Martin Hofmann schrieb: > @w3llschmidt > Ich habe rein gar nichts von DHCP geschrieben. Schlecht gelaunt? > Das Board wechselt ohne weiteres Zutun von selber die IP-Generierung. Das Board hat nach dem Wechsel dann quasi irgendeinde neue IP ? > Das ist einer der Fehler. Schon klar ...
Henrik Wellschmidt schrieb: > Martin Hofmann schrieb: >> @w3llschmidt >> Ich habe rein gar nichts von DHCP geschrieben. > > Schlecht gelaunt? Nö, wieso denn. Aber es gilt, wer lesen kann ... > >> Das Board wechselt ohne weiteres Zutun von selber die IP-Generierung. > > Das Board hat nach dem Wechsel dann quasi irgendeinde neue IP ? Nicht nur IP, sondern auch Netmask & Gateway betroffen. MAC hatte sich noch nicht geändert. MAC fällt aber nicht so sehr auf, da TCP-IP ja auch mit einer anderen MAC weiter geht. Ich vermute, das es etwas mit dem EEPROM zutun hat, da diese Werte dort abgespeichert liegen. > >> Das ist einer der Fehler. > > Schon klar ... ... Aber offensichtlich nicht gleich jedem. Lösungsvorschläge ?
NurEinGast schrieb: > Martin Hofmann schrieb: >> Lösungsvorschläge ? >> > Kondensatoren anlöten ? +1 noch mal fonsana
@fonsana C´s habe ich Schaltungsmäßig für ENC28J60 & ATMega32 verglichen. Soweit hat das Pollin schon richtig gemacht, wenn gleich ungeschickt (C7 10yF) mit zu langer Leitung & 2*Durchkontaktieren gelöst. C6 & C10 haben nur 10nF anstelle 100nF, aber das ist im Ethernet Ausgangszweig, der ja die Programmierung EEPROM vom AVR nicht beeinflusst. Ansonsten habe ich noch zusätzliche C´s 100nF an die Spannungsversorgungen von ENC & ATMega gelötet. Derzeit läuft die Schaltung zum Test, aber das tat sie vorher auch bis zum sporradischen Fehler. Leider konnte ich den Thread zu den C´s weder bei ethersex.de noch hier finden. Hast Du nen Link ? Oder ein Foto/Beschreibung wo Du was geändert/ergänzt hast ?
> Soweit hat das Pollin schon richtig gemacht, wenn gleich ungeschickt (C7 > 10yF) mit zu langer Leitung & 2*Durchkontaktieren gelöst Die gehören mit möglichst kurzer Leitung direkt an die ICs. Ich nehme immer SMD direkt zwischen VDD und VSS, das geht bei der Platine auf der Unterseite völlig problemlos.
tt2t schrieb: >> Soweit hat das Pollin schon richtig gemacht, wenn gleich ungeschickt (C7 >> 10yF) mit zu langer Leitung & 2*Durchkontaktieren gelöst > > Die gehören mit möglichst kurzer Leitung direkt an die ICs. Ich nehme > immer SMD direkt zwischen VDD und VSS, das geht bei der Platine auf der > Unterseite völlig problemlos. Hallo tt2t Dir ist schon klar, das C7 (10yF) am Pin 1 vom ENC28J60 Bezeichnung VCAP sitzt. Keinerlei weitere Verbindungen sonst wo hin. Die 3V Spannungsversorgung kommt an den Pins 15,19,20,25 & 29 ENC rein. Wie ich bereits schrieb, ist das nur ungeschickt gelöst. Ein Einfluss von C7 am ENC auf den Mikrocontroller kann ich nicht erkennen. Ich vermute, das die Werte im EEPROM des ATMega verändert werden. Wie ich schon schrieb, habe ich Block Kondensatoren 100nF an des Spannungseingängen des ENC & ATMega verteilt. Läuft derzeit zum Test, da Fehler ja sporradisch ist.
Martin Hofmann schrieb: > C´s habe ich Schaltungsmäßig für ENC28J60 & ATMega32 verglichen. > Soweit hat das Pollin schon richtig gemacht, wenn gleich ungeschickt (C7 Du hast das Datenblatt und die Diskussion auf www.ethersex.de nicht gelesen. Im Datenblatt steht unter anderem: All power supply pins must be externally connected to the same power source. Similarly, all ground references must be externally connected to the same ground node. Each VDD and VSS pin pair should have a 0.1 μF ceramic bypass capacitor (not shown in the schematic) placed as close to the pins as possible. Und VDD-VSS-Paare gibt es schon 5. Es kann natuerlich sein, dass Du eine verbesserte Version des Netio hast. fonsana
fonsana schrieb: > Du hast das Datenblatt und die Diskussion auf www.ethersex.de nicht > gelesen. Uebrigens: Die "Entwickler" bei Pollin auch nicht! OK, die Diskussion konnten sie nicht gelesen haben bevor es zu spaet war, die haben sie erst verursacht. fonsana
Laut Datenblatt beträgt die max. Betriebsspannung des ENC 3,45V. Bei meinen drei, die ich in Betrieb habe, habe ich die Widerstände des LM317 so ausgemessen das nur etwa 3,2V herauskommen. Der ENC wird auch gleich deutlich weniger warm. Ansonst SMD-Kondensatoren an die Stromversorgungs-Pin. Seit fast zwei Jahre kein Problem damit.
In einer anderen Schaltung mit Ethernet und AVR hatte ich das Problem, Daten im EEPROM zu verlieren, wenn ich ein NICHT gekreuztes Netzwerkkabel zwischen PC und Ethernet-Controller nutzte. Der Fehler trat mehrmals täglich auf. Das nicht gekreutze Kabel war prinzipiell kein Fehler, denn mein PC kann die Polarität seiner Ethernet Buchse automatisch umschalten. Die Verbindung hat ja auch funktioniert, bis auf den sporadischen Verlust einzelner Bits im EEPROM. Als Lösung hatte ich die Software so geändert, dass sie zuerst das EEPROM ausliest, und erst einige Millisekunden danach den Ethernet Transmitter einschaltet. Vorher passierte beides in umgekehrter Reihenfolge ohne Wartepause. Mit dem Oszilloskop konnte ich herausfinden, daß die Spannungsversorgung (in meinem Fall waren AVR und Ethernet Controller gemeinsam mit 3,3V versorgt) in dem Moment deutlich einbricht, wo die Link-LED an geht. Darum habe ich einen zusätzlichen 22yF Kondensator an VCC/GND gelötet, danach funktionierte die Schaltung sowohl mit der verbesserten Software, als auch mit der alten zuverlässig. Ich hatte mich entschlossen, beie Lösung beizubehalten: Also den zusätzlichen Kondensator und die geänderte Initialisierung. Ich glaube, daß bei mir folgendes Passiert: In dem Moment, wo die Software den Transmitter einschaltet, entsteht ein Kurzschluß, weil das Netzwerkkabel NICHT gekreuzt ist. Das Notebook erkennt dies und polt seine Buchse um. Dann kommt der Link zustande. Während des Kurzschlusses bricht die Versorgungsspannung ein. In der Tat ist mein Spannungsregler knapp bemessen, ich hätte einen stärkeren nehmen sollen. Jedenfalls leist die Software das EEPROM blöderweise genau in dem Moment aus, woe die Versorgungsspannung einbricht. Und darauf scheint das EEPROM empfindlich zu reagieren, wenngleich alle anderen Funktionen des AVR nicht beeinträchtigt sind. Vielleicht ist das auch Dein Problem. Versuch einfach mal, die Spannungsversorgung des Ethernet Controllers mit einem großzügigen Elko (z.B. 100yF) zu unterstützen. Eventuell hilft auch, ein anderes Netzteil zu verwenden, dessen Ausgangsspannung schneller ansteigt bzw im Einschaltmoment bei stark wechselnder Last nicht einbricht.
Stefan Frings schrieb: > Ich glaube, daß bei mir folgendes Passiert: In dem Moment, wo die > Software den Transmitter einschaltet, entsteht ein Kurzschluß, weil das > Netzwerkkabel NICHT gekreuzt ist. Das Notebook erkennt dies und polt > seine Buchse um. Dann kommt der Link zustande. Dann solltest du dir mal die Schaltung ansehen! Es kann kein Kurzschluss entstehen, denn das Ethernetkabel ist an beiden Enden induktiv an den PHY gekoppelt. Sascha
Und du meinst, dass die Induktive Koppelung einen Kurzschluss verhindert? Wie das? Egal ob Induktiv, Kapazitiv oder direkt - ich habe doch zwei Ausgänge miteinander gekoppelt. Wenn nun der eine "High" sagt, und der andere "Low" bekomme ich einen Kurzschluss. Da gibt es natürlich Bauteile, die die Stromstärke begrenzen, aber zumindest wird ein erheblich höherer Strom fließen, als vorgesehen. Oder etwa nicht?
Stefan Frings schrieb: > In einer anderen Schaltung mit Ethernet und AVR hatte ich das Problem, Sind dort alle vorgeschriebenen C's eingebaut? fonsana
Nein. Die Anzahl stimmte, aber deren Werte waren kleiner, als in den Datenblättern der IC's vorgeschrieben. Also kein Wunder, dass ich probleme hatte.
Hallo Leute! Hab auch das Problem das einzelne Bits im EEPROM umfallen. Meiner Meinung nach passiert es beim Anlegen der Versorgungsspannung. Hab 2 Boards (mit K8IO) im Einsatz, selbes Verhalten in unregelmäßigen Abständen. Zur Versorgung verwende ein Schaltnetzteil das mir 5 V für die NetIOs und 12V für die K8IO liefert. In unregelmäßigen Abständen kann ich eines oder beide Boards nicht ansprechen da sich die IP geändert hat. ---- Danach hab ich zusätzlich folgende Umbauten durchgeführt: Spannungsversorgung: Eingang/Ausgang IC2 ->100nF ; R1 240 Ohm und für R2 390 Ohm. ENC28J60: 100nF Kondensator gegen Masse bei Pin 15, 19, 20, 25, 28; R4 -> 2.00kOhm und 1% AtMega: zusätzlichen 100nF zwischen Pin 10 und 11 MAX232: (C17, C16, C15, C14) tauschen gegen 100nF LEDs: auslöten; Vorwiderstände bei Ethernet-LEDs verdoppelt R6, R7 ---- Leider nach den aufwendigen Umbauten noch immer selbes Verhalten… ---- Danach hab ich die Versorgung mit 3x 100uF stabilisiert, mir kommt vor etwas besser aber nach letzter Inbetriebnahme wieder IP bei einem Board verloren, ich dreh langsam durch. Hat jmd. eine Idee?! Lg und vielen Dank Werner
>Nein, was meinst du damit?
Er meint die BODLEVEL und BODEN Fuse. Wenn die falsch stehen kann es zu
Datenverlust im EPPROM führen.
OK Danke! Auslesen konnte ich die alten Werte leider nicht, hab sie nun neu gesetzt auf beiden Boards: LFuse auf 0xBF HFuses auf 0xC2 Bis jetzt alles OK. Meld mich.
LFuse auf 0xBF => 2,7V sollte also passen! Beide Boards funktionieren noch immer, hab jetzt schon oft aus/ein gesteckt, schaut gut aus...
Beide Boards laufen bisher perfekt. (mit LFuse 0xBF) Sollte der Fehler wiedermal auftreten, werde ich Bescheid geben.
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.