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.
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.