Beim Versuch, einen STM32L471RGT6-Chip über SWD zu debuggen, stoße ich auf einen ACK_FAULT, wenn ich eine AP-Anforderung zum Anhalten des Kerns sende.
Ich habe die folgenden Sequenzen implementiert, die alle korrekt funktionieren und für jede relevante DP/AP-Anforderung ein ACK_OK erhalten:
Der nächste Schritt besteht darin, den Kern anzuhalten, Halt-on-Reset zu aktivieren und den Kern zurückzusetzen, um ihn in einen bekannten Zustand zu bringen, um den Flash-Speicher neu zu programmieren. Wenn ich den Halt-Befehl sende, indem ich 0xA05F0003 (DBGKEY | C_HALT | C_DEBUGEN) an 0xE000EDF0 (DHCSR-Register in AHB-AP) schreibe, erhalte ich ein ACK_OK.
Aber dann, wenn ich versuche, dasselbe Register zu lesen, um das S_HALT-Bit zu überprüfen, erhalte ich anstelle eines ACK_WAIT oder ACK_OK, wie ich erwartet hatte, ein ACK_FAULT (0b001 LSB). Ich habe die gesamte Initialisierungssequenz erneut versucht, aber stattdessen das CTRL/STATUS-Register am Debug-Port unmittelbar nach der AP-Anforderung zum Anhalten des Kerns gelesen, und das STICKYERR-Flag ist tatsächlich gesetzt.
Weiß jemand, warum diese AP-Anfrage fehlerhaft ist und wie man sie löst?
Das Problem, das ich herausfand, war, als ich in das CSW-Register schrieb, um die Zugriffsfeldgröße in AHB-AP zu konfigurieren, habe ich versehentlich die dokumentierten Bits MasterType[29], Hprot1[25], Res1[24] und DbgStatus[6] gelöscht in den Kernen der Cortex-M-Serie .
Mein Fehler bestand darin, nur die ARM-Debug-Schnittstellenspezifikation als Referenz für das CSW-Register zu verwenden, das keine Dokumentation zu diesen AHB-AP-implementierungsspezifischen Bits für die Kerne der Cortex-M-Serie enthält.
In der ARM-Debug-Schnittstellenspezifikation dokumentiert es das DeviceEn[6]-Bit als schreibgeschützten und nicht als implementierungsspezifischen Lese-/Schreibzugriff und geht nicht näher auf die in [30:24] reservierten implementierungsspezifischen Bits ein.
Ich bestätigte, dass dies das Problem war, als ich ein Oszilloskop verwendete, um die Datenphase der ersten CSW-Schreibanforderung von einem SEGGER-Programmierer zu untersuchen, der mit derselben Platine verbunden war, und feststellte, dass es 0x23000052 schrieb, was ist
MasterType[29] = 0b1
Hprot1[25] = 0b1
Reserved[24] = 0b1
DbgStatus[6] = 0b1
AddrInc[5:4] = 0b01
Size[2:0] = 0b010