Hallo zusammen, vielleicht hatte ja einer von euch schon mal das selbe Problem: Ich versuche auf einem STM32H743 mithilfe des lwip Stacks (ohne RTOS) eine Kommunikation über UDP zu etablieren. Das Versenden von Paketen funktioniert einwandfrei, das Empfangen funktioniert allerdings nicht. Die Funktion "low_level_input" reagiert wenn ich eine Paket an den STM schicke, allerdings wird in der Funktion "ethernet_input" das Paket nicht an "ip4_input" übergeben dabei wird die Debug-Message:"Can't move over header in packet" ausgeben. Diese Fehlermeldung wird ausgelöst durch den Fehler "not enough space for new header size" durch "pbuf_header_impl" in "pbuf.c". Da ich ein absoluter Neuling im Bereich lwip bin, verstehe ich nicht wirklich wo das Problem liegen könnte. Bei der Konfiguration habe ich mich an diese Anleitung gehalten: https://community.st.com/docs/DOC-1811-faq-ethernet-not-working-on-stm32h7 Wenn einer von euch einen Rat hat würde ich mich sehr freuen! mfg
Gast
#5466408
zum test den cache( beide ... ) der MCU mal deaktivieren aber grundsätzlich ... wo ist dein code hier? hänge den bitte ran ...
Hi, erstmal vielen dank für die schnelle Antwort! Code, siehe unten, habe ich erstmal nicht gepostet, weil ich dachte das Problem liegt im lwip Stack. Den DCache muss ich erst Enablen, sonst funktioniert lwip_init() nicht. Danach deaktiviere ich ihn wieder, weil ich sonst maximal drei Pakete hintereinander senden kann. Die MPU Konfiguration habe ich dem FAQ entnommen. main.c (abgespeckt)
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
143 | |
144 | |
145 | |
146 | |
147 | |
148 | |
149 | |
150 | |
151 | |
152 | |
153 | |
154 | |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | |
171 | |
172 | |
173 | |
174 | |
175 | |
176 | |
177 | |
178 | |
179 | |
180 | |
181 | |
182 | |
183 | |
184 | |
185 | |
186 | |
187 | |
188 | |
189 | |
190 | |
191 | |
192 | |
193 | |
194 | |
195 | |
196 | |
197 | |
198 | |
199 | |
200 | |
201 | |
202 | |
203 | |
204 | |
205 | |
206 | |
207 | |
208 | |
209 | |
210 | |
211 | |
212 | |
213 | |
214 | |
215 | |
216 | |
217 | |
218 | |
219 | |
220 | |
221 | |
Gast
#5466488
schau mal nach was dein linkerscript mit dem speicher macht. im STM gibt es DTCM, SRAM( mehrere regionen ) Je nach dem wo dein ethernetbuffer liegt und die descriptoren kann es da schon probleme geben . Die andere Frage: warum kein RTOS und interrupt betrieb? die CPU nur mit dem bisschen ethernet zu verheizen ist ... doof
In dem linkerscript habe ich bereits alle Zuweisungen von "DTCMRAM" nach "RAM D1" geändert, sonst Funktioniert auch das Senden nicht.... Das habe ich allerdings auch manuell gemacht. Das ganze soll, wenn es denn mal läuft, noch in ein größeres Projekt eingebettet werden, deswegen erst einmal so, ohne RTOS, um es überhaupt zum laufen zu bringen.
Gast
#5466518
Tim B. schrieb: > habe ich bereits alle Zuweisungen von "DTCMRAM" nach > "RAM D1" geändert, sonst Funktioniert auch das Senden nicht.... > Das habe ich allerdings auch manuell gemacht. dann bitte das file anhängen ... eth buffer descriptoren init von diesen und ggf die größe der TX/RX buffer
Angehängt das linkerfile Die Initizialisrung der Descriptoren lautet wie folgt:
1 | |
2 | |
3 | |
Größe ist:
1 | |
2 | |
ansonsten habe ich auch alles auf Default gelassen ( Projekt mit MXCube erstellt)
Tim B. schrieb: > __attribute__((at(0x30040000))) Schau mal im Map File nach ob das funktioniert hat. Gnu LD kann normalerweise keine festen Addresszuweisungen außerhalb des LD Skripts - man muss mit __attribute__((section("foo"))) arbeiten AFAIK.
Gast
#5467335
ich habe sections im LD angelegt.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
__attribute__((__section__(".eth"),used))
ich nutze überall 8 byte alignment ...
hat mir schon öfters kopfschmerzen bereitet warum der M7 dann meinte
hier und da langsamer zu sein
Vielen Dank schon mal an alle! Habe es jetzt hinbekommen, in dem ich in pbuf.c die Abfrage rausgenommen habe die den Fehler geliefert hat... meiner Meinung nach war die if Bedingung fehlerhaft.
Gast
#5467532
Und die Entwickler haben einen solchen Fehler, der alle RX Frames wegwirft "übersehen"?
Ja wahrscheinlich!....ne keine Ahnung warum das so ist Hier der problematische C Code
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Das Problem ist, wenn ein Paket versendet werden soll ist ">" die richtig Beziehung. Wenn man aber empfängt, müsste die Abfrage andersherum, sprich "<", sein. Da ich beides will, habe ich das jetzt einfach rausgeschmissen, funktioniert offensichtlich auch so. Die Pakete sind ja sowieso über Checksums abgesichert, wenn da was schief geht sollte man es spätestens da noch merken. Falls jemand noch eine bessere Idee, oder Erklärung hat gerne her damit!
Gast
#5467565
der lwip code funktioniert eigentlich ganz gut. habe selbst einen F7 mit RTOS + lwIP laufen. Ob das eine gute idee war das so umzufriemeln .. wird sich zeigen wenn du eine applikation laufen hast. Wenn es hier zu kuriositäten kommt .. schreib dir JETZT schonmal auf das du hier was geändert hattest ...
Gast
#5467591
ich vermute hier eher ein falsches speichermanagement
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.