Forum: Mikrocontroller und Digitale Elektronik STM32 CAN im Debugging langsamer


You were forwarded to this site from EmbDev.net. Back to EmbDev.net
von user3424523 (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,
ich bin langsam am verzweifeln. Ich arbeite jetzt seit mehreren Jahren 
mit den STM32, aber jetzt komme ich einfach nicht weiter.

Ich habe hier zwei Custom PCBs, einmal ein Master mit STM32F407 und 
einmal ein Slave mit STM32L431, Kommunikation zwischen den beiden 
mittels CAN-Bus (CAN Transceiver jeweils ein MCP2558FDT von Microchip). 
Und es funktioniert jetzt auch schon seit Monaten ohne Probleme, seit 
heute Vormittag gehts aber nicht mehr. Also es geht schon, aber nicht 
wenn ich versuche zu debuggen.

Und eigentlich will ich auch gar nicht das Thema CAN debuggen, da das 
alles ja funktioniert. Nur sobald ich beim F407 mittels ST-Link V2 
debugge, funktioniert die CAN Kommunikation nicht mehr. Ich habe keinen 
einzigen Break-Point gesetzt.

Wenn ich mit CANH und CANL am Oszi anschaue, dann sehe ich, dass diese 
beiden Signale langsamer sind, sobald ich im Debugger bin (siehe 
angehängtes Bild). Ohne Debugger bekomme ich den grauen Verlauf bei 
CANH. Mit Debugger bekommen ich den türkisen Verlauf. Man sieht, dass es 
eigentlich des selbe Signal ist, aber einfach langsamer. Dann passt 
natürlich die Bitrate nicht mehr und es gibt Fehler auf dem Bus.

Wenn ich hingegen beim L431 debugge, habe ich keine Probleme und die 
Signalverläufe sind identisch wie ohne Debugger.

Ich habe schon längst versucht, wieder auf einen älteren Stand der 
Firmware zu wechseln und mir diese ausm git repo geholt, auch einen 
Stand, wo ich defintiv weiß, dass es noch funktioniert hat. Jedoch gehts 
heute einfach nicht mehr. Ich habe auch schon Debugger gewechselt, und 
natürlich auch die Boards mit den Controllern drauf.

Als Entwicklungsumgebung nutze ich SW4STM32.

Wo könnte der Fehler liegen? Jemand eine Idee?

von Walter T. (nicolas)


Lesenswert?

user3424523 schrieb:
> Ich habe schon längst versucht, wieder auf einen älteren Stand der
> Firmware zu wechseln und mir diese ausm git repo geholt, auch einen
> Stand, wo ich defintiv weiß, dass es noch funktioniert hat. Jedoch gehts
> heute einfach nicht mehr.

Stimmt der Prozessortakt noch? Und der Peripherie-Bus-Takt?

Hast Du Testprotokolle von damals, dass genau der Teil wirklich 
funktionierte, und keine vage Erinnerung ist?

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Walter T. schrieb:
> Stimmt der Prozessortakt noch? Und der Peripherie-Bus-Takt?

Wäre auch mein Ansatz. Prüfe mit dem Oszilloskop den Quarz. Gebe mit 
einem Timer eine einfache 50%-PWM aus und schaue ob sich deren Frequenz 
genau so ändert.

Eventuell sind es irgendwelche kuriosen EMV-Effekte die den Quarz 
beeinflussen...

von AVerr (Gast)


Lesenswert?

Benutzt du OpenOCD? Das erinnert mich an 
Beitrag "Re: STM32 läuft mit Debugger schneller als er soll" wo herausgefunden 
wurde dass OpenOCD die Taktfrequenz verstellt.

von user3424523 (Gast)


Lesenswert?

Tatsächlich, OpenOCD hat den Takt verstellt und mein Code konnte die PLL 
Register dann nicht mehr ändern.

Ich frage mich allerdings, warum das jetzt plötzlich aufgetreten ist? 
Ich kann mich nicht an ein Update in den letzten Tagen von SW4STM32 
erinnern, und bis Freitag Mittag hat es ja auch noch funktioniert.

Ich habe jetzt eingebaut, dass die PLL zunächst zurückgesetzt wird, 
bevor sie erneut konfiguriert wird. Funktioniert jetzt auch wieder. Aber 
erklärt dennoch nicht, warum das bis heute nie ein Problem war.

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
Noch kein Account? Hier anmelden.