STM32F091RC CAN funktioniert nur auf PortB nicht auf PortA

[mega_clever (Gast)]

Hallo zusammen,

bin dabei einen CANopen-Stack auf dem Nucleo-64 091RC Board mit dem µC 
STM32F091RC in Betrieb zu nehmen. Laut Datenblatt sollte es möglich sein 
CAN_RX an Pin PA11 und PB8 und und CAN_TX an Pin PA12 und PB9 zu hängen.

Leider funktioniert es bei mir nur am Port B, wenn ich den 
CAN-Controller an Port A hänge werden keine CAN-Telegramme versendet. 
Hier der Code:

//#define CAN_PORT_A

#if defined( CAN_PORT_A )

  RCC_AHBPeriphClockCmd( RCC_AHBPeriph_GPIOA, ENABLE );

  GPIO_PinAFConfig( GPIOA, GPIO_PinSource11, GPIO_AF_4 ); /* see page 41 
in data sheet */
  GPIO_PinAFConfig( GPIOA, GPIO_PinSource12, GPIO_AF_4 );

  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11 | GPIO_Pin_12;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
  GPIO_Init( GPIOA, &GPIO_InitStructure );

#else
  RCC_AHBPeriphClockCmd( RCC_AHBPeriph_GPIOB, ENABLE );

  GPIO_PinAFConfig( GPIOB, GPIO_PinSource8, GPIO_AF_4 ); /* see page 42 
in data sheet */
  GPIO_PinAFConfig( GPIOB, GPIO_PinSource9, GPIO_AF_4 );

  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
  GPIO_Init( GPIOB, &GPIO_InitStructure );
#endif

Wäre super, wenn mir jemand helfen könnte.

[mega_clever (Gast)]

Hier noch Auszüge aus dem Datenblatt.

[pegel (Gast)]

Ich verstehe nicht ganz, wieso es an B funktioniert, oder hast Du noch 
irgendwo ein "RCC_APB1ENR_CANEN" versteckt?

[mega_clever (Gast)]

pegel schrieb:
> Ich verstehe nicht ganz, wieso es an B funktioniert, oder hast Du noch
> irgendwo ein "RCC_APB1ENR_CANEN" versteckt?

Ich habe nur die Portpin-Initialierung veröffentlicht. Die 
Initialisierung vom CAN-Controller ist ja unabhängig von der 
Pin-Initialisierung.

[Guest (Gast)]

Sicher das du an den richtigen Pins bist? An den Nucleos steckt man ja 
auch gern mal daneben.

Unabhängig davon wozu der Pull-Up?

[Jan H. (jan_h74)]

Beim Wechsel von pinconfig erst sysclock starten (hier für ein F3).
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);

[mega_clever (Gast)]

Guest schrieb:
> Sicher das du an den richtigen Pins bist? An den Nucleos steckt man ja
> auch gern mal daneben.
>
> Unabhängig davon wozu der Pull-Up?

Ich habe auch mal versucht den Pin 11 und Pin 12 vom Port A als normale 
GPIO-Pins zu schalten. Das hat einwandfrei funktioniert. Also gesteckt 
ist alles richtig. Ich schaffe es nur nicht den CAN-Controller mit 
diesen Pins zu verbinden. Errata-Sheet habe ich auch schon 
durchgeschaut. Aber vielleicht ist es doch ein Bug im Silicium.

[mega_clever (Gast)]

Jan H. schrieb:
> Beim Wechsel von pinconfig erst sysclock starten (hier für ein F3).
> RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);

Hallo Jan,
was soll das bringen? Bei mir ist generell eines der ersten Dinge die 
ich mache den Systemtakt richtig zu setzen also bevor ich mit der 
Initialisierung der Portpins starte.

[pegel (Gast)]

mega_clever schrieb:
> Ich habe nur die Portpin-Initialierung veröffentlicht.

Wird es nicht Zeit, uns das komplette Projekt zu präsentieren?

[pegel (Gast)]

mega_clever schrieb:
> #if defined( CAN_PORT_A )

Wenn Du so etwas öfter benutzt, sollte man genau nachsehen.

Da ist man gern mal falsch abgebogen.

[Johannes S. (Gast)]

PA und PB sind auch elektrisch anders, PB ist lt. Datasheet als FTf 
gekennzeichnet. Wie ich das verstehe kann der mehr Strom treiben und 
kann höhere Taktraten. Wird der CAN Bus da am Limit betrieben?

[mega_clever (Gast)]

pegel schrieb:
> mega_clever schrieb:
>> #if defined( CAN_PORT_A )
>
> Wenn Du so etwas öfter benutzt, sollte man genau nachsehen.
>
> Da ist man gern mal falsch abgebogen.

Nicht wenn man Atollic TrueStudio benutzt ;-). Hier werden die per 
Compilerswitch deaktivierten Bereiche automatisch "ausgegraut".

[pegel (Gast)]

mega_clever schrieb:
> Nicht wenn man Atollic TrueStudio benutzt

Sehr gut. Dafür liebe ich CubeIDE auch.

[mega_clever (Gast)]

Johannes S. schrieb:
> PA und PB sind auch elektrisch anders, PB ist lt. Datasheet als FTf
> gekennzeichnet. Wie ich das verstehe kann der mehr Strom treiben und
> kann höhere Taktraten. Wird der CAN Bus da am Limit betrieben?

Das habe ich auch schon gesehen. Der CAN-Bus wird nur mit 250kbit/s 
betrieben. Das sollte kein Problem sein. Ich  habe auch schon direkt mit 
dem Oszi am CAN_TX-Pin (PortA Pin12) gemessen. Hier ist keinerlei 
Aktivität zu messen.

[Pieter (Gast)]

moin,

ich arbeite mit dem STM32F103.
Der hat ein CAN-Modul, diese kann auch zwischen 2 Portpins umgeschaltet 
werden.
Gibt es bei dem MC auch so etwas wie: AFIO MAPR CAN REMAP

VG
Pieter

[mega_clever (Gast)]

Pieter schrieb:
> moin,
>
> ich arbeite mit dem STM32F103.
> Der hat ein CAN-Modul, diese kann auch zwischen 2 Portpins umgeschaltet
> werden.
> Gibt es bei dem MC auch so etwas wie: AFIO MAPR CAN REMAP
>
> VG
> Pieter

Hallo Pieter,
Remapping gibt es bei diesem µC nicht. Den Pins können nur die in der 
obigen Tabelle aufgelisteten Funktionen zugeordnet werden.

[Johannes S. (Gast)]

Das Nucleo F091RC habe ich auch, ich habe da mal ein Testprogram mit 
Mbed reingeschoben. Die Daten kommen ordentlich auf PA oder PB raus, der 
Chip kann es also.
Was ich auf die Schnelle als Unterschied sehe ist, das in Mbed mit 
NoPullUp initialisiert wird.
Nachtrag:
Init mit PullUp macht hier aber auch keinen Unterschied, funktioniert. 
Ich habe allerdings keinen CAN Treiber/Bus dran.

[mega_clever (Gast)]

Johannes S. schrieb:
> Das Nucleo F091RC habe ich auch, ich habe da mal ein Testprogram mit
> Mbed reingeschoben. Die Daten kommen ordentlich auf PA oder PB raus, der
> Chip kann es also.
> Was ich auf die Schnelle als Unterschied sehe ist, das in Mbed mit
> NoPullUp initialisiert wird.
> Nachtrag:
> Init mit PullUp macht hier aber auch keinen Unterschied, funktioniert.
> Ich habe allerdings keinen CAN Treiber/Bus dran.

Hallo Johannes,

seltsam. Und bei dir sieht der Code für die Pin-Initialisierung gleich 
aus wie bei mir? Ich mache am Montag mal einen Test mit einem anderen 
NUCLEO-Board. Eventuell ist irgend etwas defekt. Ohne CAN-Transceiver 
habe ich auch schon getestet.

Vielen Dank für deine Bemühungen. Schönes langes WE.

[Johannes S. (Gast)]

der Code sieht bei mir etwas einfacher aus:

//CAN can(PA_11, PA_12);
CAN can(PB_8, PB_9);

aber im Konstruktor passiert natürlich noch was. Für die STM Targets 
benutzt mbed auch LL/HAL, die Pins werden in einer Pinmap Liste gesucht 
und es wird eine einheitliche Routine zum initialisieren verwendent.
Die Parameter für CAN sind dann z.B.:
https://github.com/ARMmbed/mbed-os/blob/af4c8a94f3913ceda9069ec79cba81a793d695fe/targets/TARGET_STM/TARGET_STM32F0/TARGET_STM32F091xC/TARGET_NUCLEO_F091RC/PeripheralPins.c#L263-L274
GPIO_AF4_CAN = 0x4

habe gerade nochmal in 
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/pinmap.c
nachgesehen, der OutputTyp müsste da auf OpenDrain gesetzt sein für die 
AlternateFunctions. Debuggen klappt mit dem Board gerade nicht, der 
pyOCD erkennt das nicht, sonst könnte ich noch durchsteppen.

CubeMX initialisiert auch mit AF_PP, ich habe noch mal angehängt wie 
CubeMX das initialisiert für PA/PB und die defines für den Mode.