STM32 CAN im Debugging langsamer

Gast #6898749
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?
Angehängte Dateien:
#6898753
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?
Gast #6901150
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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren