Hallo zusammen, ich versuche schon seit einiger Zeit einen UDP-Server auf dem SoC Smart Fusion 2, welcher als µC einen Cortex M3 beinhaltet, zum Laufen zu bringen. Es wird kein OS verwendet. UDP/IP über Ethernet sind die gewünschten Protokolle. Dafür wird die Funktion udp_connect_init in der main vor der while (1) Schleife und nach der Initialisierung der Treiber aufgerufen. Beim Debuggen ist zu sehen, dass netif, buffer, Header und route alle richtig angelegt werden. Sogar die Errorwerte sind alle 0 (was genau so sein soll). Erst im letzen Schritt, nachdem udp_sendto_if in der Datei udp.c zurückgegeben wird, erscheint immer die Fehlermeldung: No source available for "0x8000044". Hab schon das Forum durchsucht und keine Lösung dafür gefunden. Weiß jemand was der Fehler sein könnte? UDP-Echo funktioniert ebenfalls nicht. Der Übergang von Software auf die Hardware scheint die Fehlerquelle zu sein. Kompilieren funktioniert und debuggen funktioniert bis zur oben beschriebenen Funktion. Danach kommt die Fehlermeldung. Hatte schon mal jemand das gleiche Problem oder hat einen Lösungsvorschlag? Das ist die selbst erstellte Funktion: void udp_connect_init (void) { struct udp_pcb *pcb_TX; uint8_t test = 25; uint8_t test2 = 26; ip_addr_t ip_addr_Dest; ip_addr_t ip_addr_Src; struct pbuf *p_out; uint8_t test3[100] = "Hallo\n\r"; uint16_t lenght = sizeof(test3); //uint8_t test4[7] = "Hallo\n\r"; //p->payload = &test3; IP4_ADDR(&ip_addr_Src, 192, 168, 0, 23); IP4_ADDR(&ip_addr_Dest, 192, 168, 0, 10); /* get new pcb */ pcb_TX = udp_new(); if(pcb_TX == NULL) { #if 0 LWIP_DEBUGF(UDP_DEBUG, ("udp_new failed!\n")); #endif return; } test = udp_bind(pcb_TX, IP_ADDR_ANY, 4711); pcb_TX->local_ip = ip_addr_Src; pcb_TX->local_port = 4711; pcb_TX->remote_ip = ip_addr_Dest; pcb_TX->remote_port = 1235; /* Writing Data in p_out*/ p_out = pbuf_alloc (PBUF_RAW, lenght, PBUF_RAM); p_out->payload = &test3; test2 = udp_send(pcb_TX, p_out); pbuf_free(p_out); } Beste Grüße Jan
Jan N. schrieb: > erscheint immer die > Fehlermeldung: No source available for "0x8000044". Sicher dass das nicht eine Addresse in der Interrupt Vector Tabelle ist? Eventuell ist der Vector nicht (korrekt) belegt und zeigt in den Wald. Du hättest besser den genauen MCU Typ angegeben, so sehe ich nur dass das ein STM32 ist.
Ich bin noch recht neu in dem Gewerbe, von daher bitte ich Fehler zu verzeihen. Es handelt sich um eine Adresse in der Interrupt Vector Tabelle und ist ein Hardfault. Der Prozessor ist ein ARM Cortex M3. Trotzdem verstehe ich nicht wie der zustande kommt. Laut Debugger ist die Software richtig geschrieben. Wenn man sich den Datenbuffer anschaut, ist dieser richtig gefüllt. Trotzdem werden die Daten im letzten Schritt nicht rausgesendet.
Stell diese Frage besser im Forum "FPGA, VHDL & Co.". Die Implementierung des M3-Core im FPGA, die Anbindung der Peripherie und die verwendeten Entwicklungswerkzeuge sind schon sehr speziell. In diesem Forum sehen alle nur einen STM32.
Steppe kurz vorm Absturz die einzelnen Assembler-Instruktionen durch, damit du siehst welche es auslöst. Da gibts bestimmt eine STR-Instruktion mit verdächtiger Adresse... Nach Aufruf des HardFault-Handlers kannst du auch den Stack analysieren um zu sehen wo der Fehler aufgetreten ist. Siehe dazu im ARMv7M Architecture Reference Manual S. 536.
:
Bearbeitet durch User
Bitte 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.