AVR mit Modbus automatischer Reset

[Manuel K. (Gast)]

Hallo!!

Ich habe für ein Uni Projekt eine einfache Modbus RTU Schnittstelle auf 
einem Atmega 32 implementiert. Ich verwende lediglich zwei 
Funktionscodes, FC03 und FC16. Der AVR ist Modus Slave. Es gibt 
insgesamt 10 Register, von denen zwei beschrieben werden und 6 gelesen 
werden können. Das ganze funktioniert im Prinzip auch so wie ich es mir 
vorgestellt habe. Jedoch hab ich das Problem, dass sich der µC nach 
einer nicht definierter Anzahl von Polls resetet. Dabei spielt es keine 
Rolle ob ich mit 100ms oder 1s Befehle sende. Nach einiger Zeit kommt 
der reset.

Der Testaufbau besteht aus dem Programm Modbus Poll, einem RS485 / USB 
Converter von In-Curcuit. Bus Treiber auf AVR Seite ist ein MAX485.

Ich habe meinen Quellcode etliche Male überprüft, kann aber keinen 
Fehler finden welcher zu einem Reset führen könnte.

Vielen Dank für eure Hilfe,

Manuel

[Arduinoquäler (Gast)]

Manuel K. schrieb:
> Ich habe meinen Quellcode etliche Male überprüft, kann aber keinen
> Fehler finden welcher zu einem Reset führen könnte.

Du müsstest auch noch deinen Aufbau zeigen.

Einen Reset bekommt der AVR eventuell durch die offene (lange?)
Leitung die zum ISP Connector führt. "Herumvagabundierende"
Felder induzieren auf der Leitung eine Störspannung die den
AVR resetten lässt. Unbedingt einen Pullup 2..10K vorsehen,
evtl. noch einen Kondensator 10..100nF.

[Arduinoquäler (Gast)]

- ARef gehört nicht an Vcc!

- C5 und C6 sind nahe an Vcc und AVcc?

- C1 und C2 haben keinen Wert, sind die vorhanden?

[Manuel K. (Gast)]

Hab gerade gemerkt, dass der Schaltplan nicht mehr ganz up to date 
ist....

Kondensatoren sind überall direkt an den Pins vorhanden.

Atmega 32:
Reset - Vcc
Vcc (10) - GND (11)
Vcc (30) - GND (31)
Aref (32) - GND (31)

MAX485
Vcc - GND

Der Pull Up mit 10k am Reset ist auch vorhanden. Die Leitungswege sind 
relativ kurz.

Aref, okay. Aber wohin damit?? Aber das kann ja eigentlich nicht die 
Ursache sein.

Du würdest also die Ursache für den Reset ehr in der Hardware als in der 
Software sehen?

(Zum Aufbau, der Lastwiderstand war nur zum testen des Schaltreglers 
drin, ist entfernt. Von den Buchsen im Schaltplan ist nur eine bestückt 
und angeschlossen. Der Rest kommt später hat aber mit dem Modbus erstmal 
nichts zu tun.)

[Manuel K. (Gast)]

Hab gerade nochmal mit Oszi gemessen. Der Reset Eingang bleibt die ganze 
Zeit brav auf 5V.
Es muss scheinbar doch am Programm liegen...

[Arduinoquäler (Gast)]

Manuel K. schrieb:
> Der Reset Eingang bleibt die ganze Zeit brav auf 5V.

Wobei es oft sehr schwierig sein kann so einen (vermuteten)
Spike mit dem Oszilloskop aufzufangen. Es tritt ja genau
einmal auf, kann sehr kurz sein, und dann ist wieder lange
Zeit Ruhe.

Manuel K. schrieb:
> Es muss scheinbar doch am Programm liegen...

Ja dein Buffer kann ja überlaufen, dann passieren die
wildesten Dinge. Ich habe dein Programm nicht daraufhin
überprüft.

[m.n. (Gast)]

Manuel K. schrieb:
> Ich habe meinen Quellcode etliche Male überprüft, kann aber keinen
> Fehler finden welcher zu einem Reset führen könnte.

Typisch für sporadische Abstürze ist ein zu klein gewählter Stack. 
Vergrößere ihn mal probeweise um 0x10 Bytes.

[Rufus Τ. F. (rufus)]

Manuel K. schrieb:
> IMG_7590.JPG

Und wie sieht das von unten aus?

[Oliver S. (oliverso)]

Ich habs mal eben durch den Compiler geschoben:

:\pocketcpp\avr-gcc-6.1.0-x86-mingw\avr\include\avr\signal.h:36:2: 
warning: #warning "This header file is obsolete.  Use 
<avr/interrupt.h>." [-Wcpp]

../main.c:404:15: warning: iteration 32 invokes undefined behavior 
[-Waggressive-loop-optimizations]

../main.c:411:15: warning: iteration 32 invokes undefined behavior 
[-Waggressive-loop-optimizations]

Die letzten beiden solltest du dir mal anschauen...

Oliver

[Patrick B. (p51d)]

Du hast in deinem Code mehrere Fehler!

#define rxbuffersize 32
#define txbuffersize 32
...
uint8_t rxbuffer[rxbuffersize];
uint8_t txbuffer[txbuffersize];
...
void cleanrxbuffer(void){
  for (int i = 0; i<=rxbuffersize; i++){
    rxbuffer[i] = 0;
  }
  rxbyte = 0;
}

void cleantxbuffer(void){
  for (int i = 0; i<=txbuffersize; i++){
    txbuffer[i] = 0;
  }

}

Generiert dir einen Array Overflow!
richtig wäre wohl:

void cleanrxbuffer(void){
  for (int i = 0; i < rxbuffersize; i++){
    rxbuffer[i] = 0;
  }
  rxbyte = 0;
}

void cleantxbuffer(void){
  for (int i = 0; i < txbuffersize; i++){
    txbuffer[i] = 0;
  }
}

Zusätzlich musst du an diversen Orten noch die Buffer-Grösse Prüfen (ob 
wirklich so viele Bytes empfangen wurden...):

volatile static uint16_t crc16(uint8_t *buffer, uint16_t buffer_length) {
  uint8_t crc_hi = 0xFF; // high CRC byte initialized
  uint8_t crc_lo = 0xFF; // low CRC byte initialized
  unsigned int i; // will index into CRC lookup
  
  if((buffer_length >= rxbuffersize) ||
    (buffer_length >= txbuffersize))
  {
    // ERROR
    return 0;
  }
  else
  {
    //pass through message buffer
    while (buffer_length--) {
      i = crc_hi ^ *buffer++;
      crc_hi = crc_lo ^ table_crc_hi[i];
      crc_lo = table_crc_lo[i];
    }

    return (crc_hi << 8 | crc_lo);
  }  
}

ISR(USART_UDRE_vect ){
  if ((txposition < txbuffer_length) &&
  (txbuffer_length < txbuffersize)){ //
    UDR = txbuffer[txposition];
    txposition++;
  }
  else{
    UCSRB |= (1<<TXCIE);
    UCSRB &=  ~(1<<UDRIE);
  }
}

Weiter würde ich bei "dataprocessing" auf die minimale Frame-Länge 
prüfen! Bei Modbus gibt es ja mindestes Slave-ID, Function-Code, CRC 
(weiss jetzt nicht, ob noch ein Register mehr dabei ist).
Das sind gerade die Dinge, die mir aufgefallen sind. Eventuell gibt's 
noch mehr Problemstellen.

[Manuel K. (Gast)]

Erstmal vielen Dank für die ganzen Tips und Verbesserungsvorschläge. 
Habe versucht das meiste in meinem Code zu berücksichtigen.

Leider hat es das Problem nicht gelöst. Ich hatte zwischenzeitlich das 
Netzteil in Verdacht, da sich die Reset Erscheinungen je nach Netzteil 
gehäuft haben.

Letztendlich lag der Fehler doch ganz wo anders. Ich hatte vergessen die 
CKOPT Fuse zu setzten. Hatte mich zwar vorher schonmal damit 
auseinandergesetzt aber scheinbar aus versehen deaktiviert. Das Problem 
an der CKOPt Fuse ist das es ne ganze zeitlang funktioniert und dann 
aufeinmal nicht mehr.

Naja wieder was gelernt, bei nächsten mal passiert mir das hoffentlich 
nicht mehr.

[Tim Grunolf (Gast)]

Warum nimmst für Modbus nicht einfach eine Library? Für den AVR gibt es 
viele Implementierungen (siehe Modbus-Artikel).

[Mathias O. (m-obi)]

Genau. Ich nehme freemodbus. Läuft prima.

[Manuel K. (Gast)]

Hat drei Gründe.

Es es nicht ausgeschlossen, dass das Projekt später kommerziell 
verwendet wird. Und ich habe keine Ahnung ob das wegen Lizenzen nicht 
schwierig werden könnte.

Es ist ein sehr spezieller Slave der aus Sicherheitsgründen alleine am 
Bus hängt und auch nur zwei Funktionscodes benötigt. Fehlermeldungen 
können am Gerät auch nicht ausgelesen werden. Von daher sind die meisten 
Librarys zu aufgeblasen.

Aber eigentlich war der Hauptgrund, dass ich es selbst machen wollte, 
zwecks Lerneffekt. Ich hab relativ viel Zeit für die Umsetzung von daher 
passt das schon. Und mittlerweile funktioniert es ja auch problemlos.

[Mathias O. (m-obi)]

Du denkst es macht sich jemand die Arbeit, lädt die Firmware vom 
Controller runter und schaut sich den Hexcode an um festzustellen ob da 
Lizenzen vorhanden sind???

[Axel R. (Gast)]

> ...Es ist ein sehr spezieller Slave
HUNDEBABIES, HUNDEBABIES :)

StromTuner