www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik TWI am Atmega16 stürtzt ab


Autor: Debugger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich bin gerade am Debuggen eines Systems, das ich verkabeln sollte.

Es handelt sich dabei um einen Master (Atmega16) und 2 Slaves 
(Atmega16), die über TWI verbunden sind. Kabellängen zwischen Master und 
Slave: rund 4m.

Das ganze hat unter Laborbedingungen bereits funktioniert, 
Datenaustausch hat geklappt. Nun wird das System heute an seinem 
Bestimmungsort installiert, und der Master resettet sobald er Daten an 
die Slaves senden will. Verkabelung habe ich nun schon zum 5. Mal 
überprüft, die passt so.

Die Pullups sind am Master verbaut. Nur die kommen mir zu klein vor 
(1kOhm) (habe ich nicht verbaut, sondern Kollege).
Nur ist das ganze nun schon ganz schön verbaut und es wäre mit großem 
Aufwand verbunden diese Widerstände gegen größere zu tauschen. Deshalb 
erst mal die Frage an euch:

Könnt Ihr euch vorstellen, dass der Prozessor abstürzt, sobald er zu 
senden versucht, nur weil die Pullups zu klein gewählt sind? Vor allem: 
Das ganze hat in der Werkstatt schon funktioniert. Nun wurde nur die 
Verkabelung neu gemacht (Kabellängen in der Werkstatt: 1,5m ; jetzt: 
4m).

Vielen Dank für die Mithilfe im Voraus!!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Debugger schrieb:
> Könnt Ihr euch vorstellen, dass der Prozessor abstürzt, sobald er zu
> senden versucht, nur weil die Pullups zu klein gewählt sind?

Naja, die 5 mA (bei Vcc = 5 V) lassen natürlich die Stromversorgung
etwas einbrechen, aber so dramatisch sollte das noch nicht sein.

Ich tippe eher auf Erdschleifenprobleme oder sowas.

Wie sieht denn die /RESET-Beschaltung aus?

Autor: Heiko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde eher auf die geänderte Umgebung tippen. Die Schnittstelle ist 
für diese Leitungslängen garnicht gedacht. Ich überbrücke damit zwar 
auch bis zu 25m (bei 1,2K Ohm), aber mich stören hin und wieder 
fehlerhafte übertragungen nicht. Wie äußert sich denn der Absturz. Wenn 
die Schnittstelle hängt liegt es auch gerne an einer Leitung, die 
dauerhaft 0-Potential hat.

Autor: Debugger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versorgungsspannung hab ich schon gemessen, die liegt konstant bei 4,9V. 
Damit sollte der Controller noch klarkommen würd ich mal meinen.

Beschaltung von /Reset:


[code]

           10kOhm
            __
 vcc  o----|____|----------------------> /Reset vom Atmega
                    |
                    |
                    |
                    =  47pF
                    |
                    |
                    |
                    _  GND

Autor: Debugger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[quote]Wie äußert sich denn der Absturz.[/quote]

Das Programm startet wieder von vorne (Initialisierungen etc.).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
47 pF ist recht dünn, da kann dir schon mal ein Impuls reinfeuern.
Empfohlen sind 10 nF, allerdings sollte man dann den Widerstand
nach Vcc noch mit einer Diode brücken, da /RESET intern keine
Schutzdiode nach Vcc hat.  (Steht irgendwo in einer Appnote.)

Kannst du in die I²C-Leitungen (einschließlich Masse!) mal ein paar
"Angstwiderstände" reinsetzen?  Vielleicht 22 Ω oder so auf jede
Seite.  Das ist zwar noch keine echte Serienterminierung der
Leitung, könnte aber diese oder jene Störung ein wenig dämpfen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Debugger schrieb:
> Das Programm startet wieder von vorne (Initialisierungen etc.).

a) Watchdog schlägt zu, weil TWI-Bedingung nicht erfüllt ist / 
Fehlerbehandlung ungenügend?

b) unerlaubte Sprungbedingung in die Wüste, aus gleichem Grund?

Autor: Debugger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kondensatoren werde ich vergrößern.
Diese Serien-Widerstände sollten sich einbauen lassen.

Mein Programm hat keinen Watchdog enabled. Kann mir auch nicht 
vorstellen wo diese Sprungbedingung herkommen soll (Programm habe ich 
überprüft).

Aktuelle TWI Frequenz: 100kHz. Könnte auch auf 10kHz zurückgehen. Bringt 
das was?

Was sollte passieren, wenn ich die Kabel zu den Slaves abstecke und 
versuche per TWI an die Slaves zu senden?

Grüße

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Debugger schrieb:

> Aktuelle TWI Frequenz: 100kHz. Könnte auch auf 10kHz zurückgehen. Bringt
> das was?

Dann könntest du dir zumindest auch noch Serienwiderstände von
100 Ω in Daten- und Taktleitung problemlos leisten (damit ist die
Leitung recht gut abgeschlossen), möglicherweise sogar noch ein
paar Cs parallel.

> Was sollte passieren, wenn ich die Kabel zu den Slaves abstecke und
> versuche per TWI an die Slaves zu senden?

Hängt von deiner Implementierung ab.  Sie könnte beispielsweise in
einer Endlosschleife hängen und warten, bis der Slave sich meldet,
sie könnte auch mit einem Fehler aussteigen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht solltest Du doch mal den Code posten. Mit robustem Code ist 
es auch bei Fehlern am Interface unmöglich, den Controller abstürzen zu 
lassen. Es sei denn, Du hast wirklich ein physisches (sprich: 
elektrisches) Problem, welches dem Controller einen Latch-Up verpasst.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da er durch einen Reset (oder Sprung nach Adresse 0) rutscht, denke
ich erstmal nicht, dass es wirklich am Code liegt (es sei denn, er
hat Interrupts aktiviert und eine ISR vergessen, aber dann hätte der
Aufbau ja auch schon im Labor nicht funktioniert).

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Da er durch einen Reset (oder Sprung nach Adresse 0) rutscht, denke
> ich erstmal nicht, dass es wirklich am Code liegt

Wenn die Fehlerbehandlung in der TWI-Routine nicht funktioniert, dann 
vielleicht schon, da durch verrauschte Signale oder verschluckte 
Start-Stop-Kennungen erwartete Bedingungen nicht eintreffen.

Jörg Wunsch schrieb:
> es sei denn, er
> hat Interrupts aktiviert und eine ISR vergessen, aber dann hätte der
> Aufbau ja auch schon im Labor nicht funktioniert

Naja, ich hatte letzthin auch einige diffuse Probleme mit TWI, der 
Logic-Analyzer hat dann für Klarheit gesorgt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut Ballhause schrieb:
> Jörg Wunsch schrieb:
>> Da er durch einen Reset (oder Sprung nach Adresse 0) rutscht, denke
>> ich erstmal nicht, dass es wirklich am Code liegt
>
> Wenn die Fehlerbehandlung in der TWI-Routine nicht funktioniert, dann
> vielleicht schon, da durch verrauschte Signale oder verschluckte
> Start-Stop-Kennungen erwartete Bedingungen nicht eintreffen.

Wie kommst du von da aber zu Adresse 0?  Einen longjmp() an den
Anfang von main() wird man ja nicht programmieren. ;-)

Eher zu erwarten ist dann, dass sich der Code "aufhängt", weil er
auf eine Bedingung wartet, die unter den aktuellen Umständen nicht
eintrifft (beispielsweise eine Freigabe von SCL), und weil die
entsprechende Schleife keinen Abbruch-Zähler enthält.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Wie kommst du von da aber zu Adresse 0

Über einen (unbeabsichtigten) Sprung in eine nichtprogrammierte 
Flash-Adresse, über einen überlaufenden Pointer zum Beispiel. Trifft der 
Programmcounter auf eine Adresse mit Ihnalt $FF, wird bis Adresse $0000 
weitergezählt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut Ballhause schrieb:

>> Wie kommst du von da aber zu Adresse 0
>
> Über einen (unbeabsichtigten) Sprung in eine nichtprogrammierte
> Flash-Adresse, über einen überlaufenden Pointer zum Beispiel. Trifft der
> Programmcounter auf eine Adresse mit Ihnalt $FF, wird bis Adresse $0000
> weitergezählt.

Davon ist bei C-Programmierung normalerweise nicht auszugehen, vor
solchen Fehlern bewahrt einen der Compiler recht zuverlässig.

Aber du hast natürlich Recht: der OP hat nirgends geschrieben, in
welcher Sprache er das programmiert hat.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.