Hallo zusammen! Ich habe eine Frage zum STM32H753 Controller mit CAN-FD. Dieser sendet im im External Loopback Modus ganz normal. Ich kann Daten senden und empfange meine eigenen Nachrichten. Die gesendeten Nachrichten sehe ich korrekt in einem CAN-FD-Logger. Beim Umschalten auf den Modus "Normal" sendet der µC nicht mehr. Ich sehe im Logik-Analyzer auf der TX Leitung nur, dass diese auf Low gezogen wird, kurz drauf wieder High. Der Logger meldet dann einen Stuff-Bit-Error, was ja eine logische Konsequenz ist. Wieder umgeschaltet auf External Loopback und alles läuft... Was kann das sein? Vielen Dank! :-)
Gast
#6274600
Code....?
Gast
#6275108
Schaltplan.... ?
Gast
#6275230
Du hast schon einen zweiten CAN-Knoten im normal mode am Bus und alles korrekt terminiert?
Hi, zum Schaltplan: Es ist ein original STM32H753I-EVAL2 mit CAN-FD-Schnittstelle. zum Code:
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 | |
222 | |
223 | |
224 | |
225 | |
226 | |
227 | |
228 | |
229 | |
230 | |
231 | |
232 | |
233 | |
234 | |
235 | |
236 | |
237 | |
238 | |
239 | |
240 | |
241 | |
242 | |
243 | |
244 | |
245 | |
246 | |
247 | |
248 | |
249 | |
250 | |
251 | |
252 | |
253 | |
254 | |
255 | |
256 | |
257 | |
258 | |
259 | |
260 | |
261 | |
262 | |
263 | |
264 | |
265 | |
266 | |
267 | |
268 | |
269 | |
270 | |
271 | |
272 | |
273 | |
274 | |
275 | |
276 | |
277 | |
278 | |
279 | |
280 | |
281 | |
282 | |
283 | |
284 | |
285 | |
286 | |
287 | |
288 | |
289 | |
290 | |
291 | |
292 | |
293 | |
294 | |
295 | |
296 | |
297 | |
298 | |
299 | |
300 | |
301 | |
302 | |
303 | |
304 | |
305 | |
306 | |
307 | |
308 | |
309 | |
310 | |
311 | |
312 | |
313 | |
314 | |
315 | |
316 | |
317 | |
318 | |
319 | |
320 | |
321 | |
322 | |
323 | |
324 | |
325 | |
326 | |
327 | |
328 | |
329 | |
330 | |
331 | |
332 | |
333 | |
334 | |
335 | |
336 | |
337 | |
338 | |
339 | |
340 | |
341 | |
342 | |
343 | |
344 | |
345 | |
346 | |
347 | |
348 | |
349 | |
350 | |
351 | |
352 | |
353 | |
354 | |
355 | |
356 | |
357 | |
358 | |
359 | |
360 | |
361 | |
362 | |
363 | |
364 | |
365 | |
366 | |
367 | |
368 | |
369 | |
370 | |
371 | |
372 | |
373 | |
374 | |
375 | |
376 | |
377 | |
378 | |
379 | |
380 | |
381 | |
382 | |
383 | |
384 | |
385 | |
386 | |
387 | |
388 | |
389 | |
390 | |
391 | |
392 | |
393 | |
Am Bus hängt aktuell ein zweites Node und ein Logger. Das zweite Node antwortet auch immer schön brav auf die Nachrichten, die der STM im External-Loopback-Mode sendet. Das sehe ich im Logger. Der Logger selbst bestätigt wohl auch den Nachrichtenempfang... Ich finde komisch, dass die TX Leitung zwischen µC und Bus-Treiber nur auf Low geht und sonst nix macht.... EDIT: Terminierung passt auch. Da hab ich sogar auch einiges getestet!
Gast
#6277761
Daniel F. schrieb: > Es ist ein original STM32H753I-EVAL2 mit CAN-FD-Schnittstelle. Mit nur EINEM Bord bekommst Du kein Ausfahrsignal. CAN funktioniert immer nur mit >1 Teilnehmern. Lies dir erstmal die Spezifikation an, wie der Bus funktioniert.
Gast
#6277771
Daniel F. schrieb: > Am Bus hängt aktuell ein zweites Node und ein Logger. > Das zweite Node antwortet auch immer schön brav auf die Nachrichten, die > der STM im External-Loopback-Mode sendet. Das sehe ich im Logger. > Der Logger selbst bestätigt wohl auch den Nachrichtenempfang... > > Ich finde komisch, dass die TX Leitung zwischen µC und Bus-Treiber nur > auf Low geht und sonst nix macht.... > > EDIT: Terminierung passt auch. Da hab ich sogar auch einiges getestet! Sry, leider zu spät gesehen. Das ist merkwürdig. Der Logger ist auch als aktiver Teilnehmer geschaltet? Was antwortet Node2? Nur das Ack oder eine Nachricht? Befindet sich Node2 im normalen Modus?
Wenn du keinen anderen Teilnehmer hast, muss die RX Leitung die gleichen Logik-Pegel bekommen wie die TX Leitung. Und Software-Seitig müsstest du als Folge daraus einen Missing ACT Fehler bekommen. Ansonsten ist was an deinem MCP2562FD kaputt oder der Rx-Pin am STM ist falsch konfiguriert.
Domenik schrieb: > Das ist merkwürdig. Der Logger ist auch als > aktiver Teilnehmer geschaltet? Was antwortet Node2? Nur das Ack oder > eine Nachricht? Befindet sich Node2 im normalen Modus? Der Logger sollte antworten, da er nicht inaktiv ist. Ich kann ja auch mit ihm senden. Der "Silent-Mode" ist nicht an. Allerdings kommt die Nachricht ja schon nicht an, daher kommt kein ACK. Node 2 antwortet mit einer Nachricht. Genaueres kann ich dazu nicht sagen. Das ist ein fertiges Gerät. Die Antwort sehe ich aber nur auf dem Logger, da der STM ja im External-Loop-Mode ist. Christian K. schrieb: > Wenn du keinen anderen Teilnehmer hast, muss die RX Leitung die gleichen > Logik-Pegel bekommen wie die TX Leitung. Und Software-Seitig müsstest du > als Folge daraus einen Missing ACT Fehler bekommen. > > Ansonsten ist was an deinem MCP2562FD kaputt oder der Rx-Pin am STM ist > falsch konfiguriert. Dass der kaputt oder falsch konfiguriert ist, schließe ich aus. Ich kann ja senden und bekomme die Antworten aus dem externen Loopback. Daher passt RX und TX am µC schonmal. Der MCP ist ja "nur" ein Logikwandler, oder hat der noch einen Puffer intern? Was passiert denn beim MCP, wenn er nach dem ersten Bit erkennt, dass er den BUS nicht auf LOW treiben kann. Der High Pegel ist ja dominant. Wenn der RX diesem nicht folgt, hört der µC dann sofort mit dem Senden auf? Das könnte das Verhalten erklären... EDIT: Der internal Loopback bleibt ja im STM, der external Loopback geht durch den MCP, oder?
ERLEDIGT! Habe das Problem gelöst: Nachdem ich die neue Platine nun bestückt habe und alles funktioniert, hab ich nochmal genauer nachgesucht. Auf dem EVAL Board ist ein offener Jumper in der RX Leitung. Deshalb hat der µC nicht weiter gesendet, weil er vermutlich dachte, dass auf dem Bus eine dominante Kommunikation läuft. Gesehen habe ich das nicht, weil der Jumper nicht auf der Schaltplanseite mit der CAN-Schnittstelle ist, sondern auf der "Hauptseite" des µC. Beim CAN steht aber der PIN vom µC an der Leitung, daher dachte ich, dass der direkt dahin geht... Also: Problem gelöst! Zur Fehlersuche hätte ich RX und TX mit einem Logikanalysator vergleichen sollen, wie hier vorgeschlagen wurde! Danke an alle Beteiligten!
Gast
#6488062
Hallo zusammen, ich wollte mich an dem Projekt von Danie F. orientieren und mit meinen STM32G4 eine CAN Comunikation aufbauen. Ich nutze den FDCAN Bus 2 auf der MCU. Leider bekomme ich einige Errors wenn ich den oben gezeigten Code nutze: z.B.:
1 | |
2 | |
oder
1 | |
2 | |
Da ich noch recht neu im Thema STM32 bin waere ich ueber einige Tipps ehr dankbar, thx and cya Thommy
Gast
#6488068
Da hilft es oftmals nur in die HAL (und Ref Man) reinzuschauen und sich die Definitionen selbst zu suchen.
Hi. Das wird nicht funktionieren, wenn du einfach den Code oben kopierst. Der Code wurde mit dem "Konfigurator" der STM32CubeIDE erstellt und dann ergänzt. Du solltest auch den Konfigurator nutzen, dort eine Config mit deinem Board erstellen und dann lediglich die main abändern. Zu der Cube IDE findest du Tutorials, die dir eine "Grundkonfig" ermöglichen. Der Rest ist ausprobieren. Leider sind die Beispiele von ST anders erstellt und so kann man das mit dem Konfigurator nicht so gut nachvollziehen...
Gast
#6488159
Hallo Domenik, hallo Daniel , danke fuer die schnelle Antworten. Ich hab mit i der STM32CubeIDE ein passendes Projekt erstellt und auch in der ICO File den FD CAN Bus als Connectivity FDCAN2 definiert. Daraus hat die IDE auch meinen Code generiert mit dem das Senden auch geklappt hat. Leider bekomm ich dann als ich den Code mit dem vom Daniel ergänzt habe der Fehler im RX Bereich. Soll heissen, dass die Funktion MX_FDCAN2_Init() automatisch generiert wurde. Allerdings nicht so umfangreich wie im oben gezeigten Code
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 | |
und ich wollte nur das Empfangen ergaenzen was leider nicht wirklich funktioniert. Danke fuer eure hilfe. Thx and cya Thommy
Hi, es gibt verschiedene Einstellungen, wie du senden und empfangen kannst. Du musst eine passende Einstellung für das Empfangen wählen. So wie ich das sehe hast du nur das Senden aktiviert. Um zu Empfangen musst du Filter anlegen. Diese Filter bestimmen dann, welche Nachrichten (von welchen IDs) empfangen werden und was mit diesen passiert:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Damit der Filter aber die Nachrichten in den RXBUFFER schreiben kann, musst du den Buffer erstellen. Das ist bei mir diese Codezeile:
1 | |
2 | |
Das kannst du im Konfigurator bei FDCAN einstellen. Anbei dazu ein Bild. Wenn der Buffer nicht deklariert wurde, dann ist klar, dass es zum Fehler kommt...
Und noch was: Damit du den Filter nutzen kannst, musst du natürlich auch diesen definieren:
1 | |
Gast
#6488254
Hi Danile, danke fuer deine Unterstuetzung. Leider steh ich etwas auf dem schlauch. Bei mir sieht die Konfiguration doch etwas anders aus und der RX Buffer ist nicht vorhanden (sieh Bild). Kann es sein, dass die API fuer den STM32G4 den FDCAN noch nicht vollstaendig unterstuetzt? (Quelle: https://forums.mbed.com/t/fdcan-support-for-stm32g474-nucleo/9924) Thx and cya Thommy
Hi, ob der G4 das unterstützt, keine Ahnung. Sollte aber doch in der Doku nachzulesen sein... Die Filter kannst du ja aktivieren. Und irgendwie muss der ja auch empfangen können. Schau dir doch mal die Application Notes zu dem Prozessor an...
Gast
#6682927
Vielen Dank für diesen Beitrag. Habe 2 Tage mit dem CAN-FD-Problem verschwendet und am Ende war es nun der hier beschriebene Jumper. Ohne diesen Beitrag würde ich wahrscheinlich immer noch suchen :-)
Daniel F. schrieb: > zum Schaltplan: Es ist ein original STM32H753I-EVAL2 mit > CAN-FD-Schnittstelle. > > zum Code: Der gehört in den ANHANG, siehe Netiquette!
Falk B. schrieb: > Der gehört in den ANHANG, siehe Netiquette! Das Thema ist ein Jahr alt und hat sich mittlerweile ERLEDIGT...
Daniel F. schrieb: >> Der gehört in den ANHANG, siehe Netiquette! > > Das Thema ist ein Jahr alt und hat sich mittlerweile ERLEDIGT... Ja, ich hatte das Datum übersehen. Trotzdem ist die Aussage richtig, vielleicht heherzigt es ja Einer beim nächsten Mal. Vielleicht sogar DU?
Mann muss das übrigens gar nicht unter Netiquette suchen. Es reicht schon, die Regeln unter "Wichtige Regeln - erst lesen, dann posten!" zu lesen, bevor man postet.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.


