Kein Debugger und keinSWO nach REMAP_CAN1

[gewiss (Gast)]

Guten Abend,

Ich verwende STM32F103VCT mit dem CANOPEN_Stack der Firma EMTAS. Für den 
CAN verwende ich die PIN PB8-PB9.

Wenn das Programm normal startet, arbeitet der CAN-Bus wie gewünscht.

Wenn ich jedoch debuggen möchte, bricht der Debugger ab, sobald das 
Makro "__HAL_AFIO_REMAP_CAN1_2 ();" durchgeführt wird

Auch das "STM32 ST-LINK Utility" kann keine Verbindung herstellen und 
die Ausgabe über SWO funktioniert nicht.

Wenn ich das Makro entferne, funktionieren die SWO und der Debugger 
normal.
Klarer weiße ohne Can da dieser ja auf den oben genannte Pin 
angeschlossen ist.
Auf dem Nucleo Boar mit dem STM32 F103rB funktioniert das debuggen und 
der SWO.

Wie finde ich den Fehler?



Danke für Ihre Hilfe

[Stefan F. (Gast)]

Ich bin was STM32 angeht noch totaler Anfänger. Wenn mir das passieren 
würde, dann würde ich einen Interrupt Handler für den Hardfault 
schreiben und prüfen, ob der dabei aufgerufen wird. Wenn ja, würde ich 
als nächstes nachschauen, welche Register Detail-Informationen zu dem 
Fault liefern.

Klingt das plausibel?

[gewiss (Gast)]

Stefanus F. schrieb:
> Ich bin was STM32 angeht noch totaler Anfänger. Wenn mir das passieren
> würde, dann würde ich einen Interrupt Handler für den Hardfault
> schreiben und prüfen, ob der dabei aufgerufen wird. Wenn ja, würde ich
> als nächstes nachschauen, welche Register Detail-Informationen zu dem
> Fault liefern.

Wie erwähnt im Normalen Betrieb funktioniert die Software!
Einziges Manko das die SWO Ausgabe nicht funktioniert.
Auf dem Nucleo Board mit dem STM32F103RB funktioniert alles.

[Niklas G. (erlkoenig)]

gewiss schrieb:
> Wie finde ich den Fehler?

Google?
https://os.mbed.com/questions/76094/how-to-use-STM32F103RB-CAN/

https://community.st.com/s/question/0D50X00009XkevESAR/lost-swd-debugging-connection-at-halafioremapcan12-

Wenn man sich den Sourcecode der Makros anschaut:

#define __HAL_AFIO_REMAP_CAN1_2()  AFIO_REMAP_PARTIAL(AFIO_MAPR_CAN_REMAP_REMAP2, AFIO_MAPR_CAN_REMAP)

#define AFIO_REMAP_PARTIAL(REMAP_PIN, REMAP_PIN_MASK) do{ uint32_t tmpreg = AFIO->MAPR; \
  tmpreg &= ~REMAP_PIN_MASK;    \
  tmpreg |= AFIO_MAPR_SWJ_CFG;  \
  tmpreg |= REMAP_PIN;          \
  AFIO->MAPR = tmpreg;          \
}while(0U)

/*!< SWJ_CFG configuration */
#define AFIO_MAPR_SWJ_CFG_Pos                (24U)                             
#define AFIO_MAPR_SWJ_CFG_Msk                (0x7U << AFIO_MAPR_SWJ_CFG_Pos)   /*!< 0x07000000 */
#define AFIO_MAPR_SWJ_CFG                    AFIO_MAPR_SWJ_CFG_Msk             /*!< SWJ_CFG[2:0] bits (Serial Wire JTAG configuration) */

/*!< CANRX mapped to PA11, CANTX mapped to PA12 */
#define AFIO_MAPR_CAN_REMAP_REMAP2_Pos       (14U)                             
#define AFIO_MAPR_CAN_REMAP_REMAP2_Msk       (0x1U << AFIO_MAPR_CAN_REMAP_REMAP2_Pos) /*!< 0x00004000 */
#define AFIO_MAPR_CAN_REMAP_REMAP2           AFIO_MAPR_CAN_REMAP_REMAP2_Msk    /*!< CANRX mapped to PB8, CANTX mapped to PB9 */

#define AFIO_MAPR_CAN_REMAP_Pos              (13U)                             
#define AFIO_MAPR_CAN_REMAP_Msk              (0x3U << AFIO_MAPR_CAN_REMAP_Pos) /*!< 0x00006000 */
#define AFIO_MAPR_CAN_REMAP                  AFIO_MAPR_CAN_REMAP_Msk           /*!< CAN_REMAP[1:0] bits (CAN Alternate function remapping) */

erhält man als (fast) vollständig substituierte Version:

do{ uint32_t tmpreg = AFIO->MAPR; \
  tmpreg &= ~(3 << 13);
  tmpreg |= (7 << 24);
  tmpreg |= (1 << 14);
  AFIO->MAPR = tmpreg;
}while(0U);

Das bedeutet es wird korrekt CAN auf Modus 2 geschaltet:
"10: CAN_RX mapped to PB8, CAN_TX mapped to PB9 (not available on 36-pin 
package)"

Allerdings wird so ganz nebenbei auch "7" auf "Serial wire JTAG 
configuration" geschrieben. Angeblich hat das "Other combinations: no 
effect". Da es bei dir ja zu Problemen kommt, würde ich stattdessen mal 
die gewünschte Konfiguration drüberschreiben.

Aus deinem Pixelmatsch-Schaltplan ist leider nur vage zu erraten dass du 
SWD benutzt. Um also SWD aktiviert zu lassen, versuche statt des 
Makro-Aufrufs mal:

AFIO->MAPR = (AFIO->MAPR & ~(AFIO_MAPR_CAN_REMAP_Msk | AFIO_MAPR_SWJ_CFG_Msk)) | AFIO_MAPR_CAN_REMAP_REMAP2_Msk | AFIO_MAPR_SWJ_CFG_JTAGDISABLE_Msk;

Für SWD+JTAG entsprechend AFIO_MAPR_SWJ_CFG_RESET nehmen.

[gewiss (Gast)]

Niklas G. schrieb:
> Allerdings wird so ganz nebenbei auch "7" auf "Serial wire JTAG
> configuration" geschrieben. Angeblich hat das "Other combinations: no
> effect". Da es bei dir ja zu Problemen kommt, würde ich stattdessen mal
> die gewünschte Konfiguration drüberschreiben.
>
> Aus deinem Pixelmatsch-Schaltplan ist leider nur vage zu erraten dass du
> SWD benutzt. Um also SWD aktiviert zu lassen, versuche statt des
> Makro-Aufrufs mal:
> AFIO->MAPR = (AFIO->MAPR & ~(AFIO_MAPR_CAN_REMAP_Msk |
> AFIO_MAPR_SWJ_CFG_Msk)) | AFIO_MAPR_CAN_REMAP_REMAP2_Msk |
> AFIO_MAPR_SWJ_CFG_JTAGDISABLE_Msk;
> Für SWD+JTAG entsprechend AFIO_MAPR_SWJ_CFG_RESET nehmen.

Meine Hal war zu alt in der neuen ist das Macro richtig.

[Stefan F. (Gast)]

Ich euch schon aufgefallen, dass hier andauernd Bugs in der HAL 
auftreten?

[gewiss (Gast)]

Stefanus F. schrieb:
> Ich euch schon aufgefallen, dass hier andauernd Bugs in der HAL
> auftreten?

In meinem Fall bin ich ja selber Schuld die Canopen Lib hat die neuere 
Hal Dabei gehabt und ich bin bei meiner alten Version geblieben!

Gruße

[Niklas G. (erlkoenig)]

Sollte nicht Schritt 1 bei der Fehlersuche sein, alle Software zu 
aktualisieren... Wer will schon alte Bugs suchen...

[Stefan F. (Gast)]

Niklas G. schrieb:
> Wer will schon alte Bugs suchen...

Ist ein Argument, aber für bestehende Projekte überwiegt bei mir:

Wer will schon auf neue Bugs treffen?

[Niklas G. (erlkoenig)]

Stefanus F. schrieb:
> Wer will schon auf neue Bugs treffen?

Wenn man schon einen (alten) Bug gefunden hat, kann man zumindestens 
prüfen ob er in aktuellen Versionen repariert ist. Wenn man dann neue 
Bugs findet, kann man die Lösung in die alte Software portieren - ist ja 
sogar Open Source.

[Stefan F. (Gast)]

Niklas G. schrieb:
> Wenn man schon einen (alten) Bug gefunden hat, kann man zumindestens
> prüfen ob er in aktuellen Versionen repariert ist.

Ack

[Bimbo. (Gast)]

Stefanus F. schrieb:
> Ich euch schon aufgefallen, dass hier andauernd Bugs in der HAL
> auftreten?

Deswegen nutze ich HAL auch nur, wenn ich etwas größeres einbinden 
möchte, z.B. USB CDC - wofür ich (noch) keinen eigenen Treiber 
geschrieben habe. Und dann wird - ausschließlich - das nötigste 
eingebunden. Sprich RCC, GPIO, etc. konfiguriere ich alles durch MEINE 
Registerzugriffe.
Am Ende habe ich nur die Bibliotheken von ST in irgendeinem Ordner 
liegen und füge zwei oder drei Funktionen dessen in meinem Code ein, 
fertig.