STM32F4 Checksummenberechnung: Hard Fault

[Ff (Gast)]

Hallo,
Ich versuche gerade Ulrich Radigs DMX-ARTNET-Interface 
www.ulrichradig.de/home/index.php/avr/dmx-avr-artnetnode nachzubauen. 
Ich möchte es auf einem STM32F429 zum laufen zu bringen. In der 
Berechnung der Checksumme im TCP-Stack gibt es ein Problem: Nach einigen 
Durchläufen wird in der ersten While-schleife der Funktion checksum() 
der Hard-Fault-Handler aufgerufen, ich kann mir nicht erklären wieso. 
Hat jemand eine Idee? Hat es was damit zu tun, das der Code von einem 8 
Bit-Prozessor kommt?

Hier die Funktion checksum()

unsigned int checksum (unsigned char *pointer, unsigned int result16, unsigned long result32)
{
  unsigned int result16_1 = 0x0000;
  unsigned char DataH;
  unsigned char DataL;
  
  //Jetzt werden alle Packete in einer While Schleife addiert
  while(result16 > 1)
  {
    //schreibt Inhalt Pointer nach DATAH danach inc Pointer
    DataH=*pointer++;

    //schreibt Inhalt Pointer nach DATAL danach inc Pointer
    DataL=*pointer++;

    //erzeugt Int aus Data L und Data H
    result16_1 = ((DataH << 8)+DataL);
    //Addiert packet mit vorherigen
    result32 = result32 + result16_1;
    //decrimiert Länge von TCP Headerschleife um 2
    result16 -=2;
  }

  //Ist der Wert result16 ungerade ist DataL = 0
  if(result16 > 0)
  {
    //schreibt Inhalt Pointer nach DATAH danach inc Pointer
    DataH=*pointer;
    //erzeugt Int aus Data L ist 0 (ist nicht in der Berechnung) und Data H
    result16_1 = (DataH << 8);
    //Addiert packet mit vorherigen
    result32 = result32 + result16_1;
  }
  
  //Komplementbildung (addiert Long INT_H Byte mit Long INT L Byte)
  result32 = ((result32 & 0x0000FFFF)+ ((result32 & 0xFFFF0000) >> 16));
  result32 = ((result32 & 0x0000FFFF)+ ((result32 & 0xFFFF0000) >> 16));  
  result16 =~(result32 & 0x0000FFFF);
  
  return (result16);
}

[Peter II (Gast)]

Ff schrieb:
> Hat jemand eine Idee? Hat es was damit zu tun, das der Code von einem 8
> Bit-Prozessor kommt?

sicher das du die Funktion mit den richtigen Parametern aufrufst?

Wenn im 1. oder 2.Prameter Unsinn steht kommt es zu einer 
Zugriffsverletzung.

[rag einfügen: Rechtsklick (Gast)]

CM4 liefert ziemlich extensive Informationen im Falle eines Faults 
(Fault Address, Fault Status) etc.

Wahrscheinlich läuft Dein pointer Amok.

PS: Deine Variablenbenamsung und Komentierung
sind ziemlich unsinnig.

[(prx) A. K. (prx)]

rag einfügen: Rechtsklick schrieb:
> PS: Deine Variablenbenamsung und Komentierung
> sind ziemlich unsinnig.

Das ist Radig'scher Code. Bei dessen TCP/IP Code kann man glatt zum 
Moby-Apologeten werden. Will hoffen, dass es sein erstes C Programm war.

[Little B. (lil-b)]

Peter II schrieb:
> sicher das du die Funktion mit den richtigen Parametern aufrufst?
>
> Wenn im 1. oder 2.Prameter Unsinn steht kommt es zu einer
> Zugriffsverletzung.

Seh ich auch so. Ein Hard Fault auf einem M4 entsteht in den meisten 
Fällen durch eine Zugriffsverletzung.

Nimm mal dieses Programm mit rein, vieleicht gibt dir das mehr 
Informationen zum Fault:
Beitrag "STM32F4 Fault Handling"

[Max (Gast)]

Benutzt du ein Discovery Bord mit STLinkv2?

Falls ja, könntest du openocd als gdb server starten und dann mit dem 
arm-none-eabi-gdb dich mit dem target verbinden.

Dann kannst du einen breakpoint im Hardfault handler setzen, das target 
resetten (`monitor reset`).
Wenn du im Hardfault handler gelandet bist, kannst du mit `where` einen 
Stacktrace ausgeben lassen und mit `frame` die stack frames 
zurueckspringen.
Damit kann man eigentlich gut den Befehl finden, der den Hardfault 
handler ausgelöst hat.

Wenn du Stacktrace und den Befehl, der den Hardfault handler ausgelöst 
hat postests, dann können wir dir viel besser helfen, als wenn wir nur 
den C Code zu sehen bekommen.

[Ff (Gast)]

Problem war, dass der int-Typ als 32 Bit Variable angelegt wurde. Habe 
die unsigned int und long durch uint16_t bzw. uint32_t ersetzt und es 
der Hard Fault-Interrupt ist weg.