STM32: CAN Loopback mit merkwürdigem Effekt

Hi Matthias,
auf dem Stamp ist ein STM32F103RET6 verbaut mit immerhin 512KB Flash.
Laut Referenz-Manual ein High Density Device:

● High-density devices are STM32F101xx and STM32F103xx microcontrollers 
where
the Flash memory density ranges between 256 and 512 Kbytes.
● XL-density devices are STM32F101xx and STM32F103xx microcontrollers 
where the Flash memory density ranges between 768 Kbytes and 1 Mbyte.

Damit liege ich mit meiner Definition im Makefile:

1

SYMBOLS  = -DSTM32F10X_XL

auf jeden Fall falsch - danke!

Die CAN-Struktur ist bislang nur ein Loopback zum "Mithören". In einem 
zweiten Schritt wollte ich es an ein bestehendes Netz anschließen.

Die Takte werden in der system_stm32f10x.c definiert - hier ist z.B. die 
SystemInit.

Ich werde gleich mal prüfen, was die Definition als High Density Device 
liefert.
Grüße
schnack

Hi,
also:
* die Definition habe ich geändert.
* außerdem hatte ich die startup_stm32f10x_xl.s statt 
startup_stm32f10x_hd.s gewählt (darauf hast Du Dich vermutlich 
bezogen..)

Beides war falsch und beides habe ich korrigiert. Aber das war es leider 
nicht. Weiterhin habe ich diesen "merkwürdigen" Effekt. Ich prüfe jetzt 
auch, ob der Code zum Init der eval-Boards noch mehr enthält.
Grüße
schnack

Hi Matthias,
ok- ich bin kein Assembler-Experte. Mein Verständnis ist, daß die 
Syteminit() im Reset-Handler aufgerufen wird.
Aus dem Assembler-File startup_stm32f10x_hd.s:

1

    .section  .text.Reset_Handler

2

  .weak  Reset_Handler

3

  .type  Reset_Handler, %function

4

Reset_Handler:  

5

6

/* Copy the data segment initializers from flash to SRAM */  

7

  movs  r1, #0

8

  b  LoopCopyDataInit

9

10

CopyDataInit:

11

  ldr  r3, =_sidata

12

  ldr  r3, [r3, r1]

13

  str  r3, [r0, r1]

14

  adds  r1, r1, #4

15

16

LoopCopyDataInit:

17

  ldr  r0, =_sdata

18

  ldr  r3, =_edata

19

  adds  r2, r0, r1

20

  cmp  r2, r3

21

  bcc  CopyDataInit

22

  ldr  r2, =_sbss

23

  b  LoopFillZerobss

24

/* Zero fill the bss segment. */  

25

FillZerobss:

26

  movs  r3, #0

27

  str  r3, [r2], #4

28

29

LoopFillZerobss:

30

  ldr  r3, = _ebss

31

  cmp  r2, r3

32

  bcc  FillZerobss

33

/* Call the clock system intitialization function.*/

34

  bl  SystemInit   

35

/* Call the application's entry point.*/

36

  bl  main

37

  bx  lr    

38

.size  Reset_Handler, .-Reset_Handler

Am Ende ruft er SystemInit() und dann main() auf. Wenn er das nicht 
täte,
dürfte ja doch gar nichts funktionieren- oder?


Grüße
schnack

Hallo,
der Effekt tritt differenzierter auf, als ich bisher bemerkt habe: wenn 
ich das Target via JLINK flashe und starte, klappt das CAN-Polling mit 
Remap - aber nicht nach einem Reset (wie oben beschrieben)
Wenn ich dagegen mit dem STMFlashLoader via USART flashe, tritt der 
Fehler sofort auf.
Offenbar "verbessert" der JLINK die Lage etwas...

Hi Matthias,
so ganz ist mir das nicht klar: Die SetupSystem() habe ich in den 
Sourcen nicht gefunden. Aber ich habe in der system_stm32f10x.c die 
Funktion SetSysClockTo72() gefunden. Diese scheint gerade die Settings 
Deiner SetupSystem() zu wählen (s.u.). Diese Funktion wird wiederum in 
der SystemInit durch

1

(...)

2

  /* Configure the System clock frequency, HCLK, PCLK2 and PCLK1 prescalers */

3

  /* Configure the Flash Latency cycles and enable prefetch buffer */

4

  SetSysClock();

5

 (...)

aufgerufen. Ich habe den Eindruck, daß alle Takte laufen - so wie es 
sein soll. Da ich ja via JLINK zumindest initial die CAN-Frames sehen 
kann, hoffe ich, daß es irgendein Detail ist, was noch fehlt.

1

static void SetSysClockTo72(void)

2

{

3

  __IO uint32_t StartUpCounter = 0, HSEStatus = 0;

4

5

  /* SYSCLK, HCLK, PCLK2 and PCLK1 configuration ---------------------------*/    

6

  /* Enable HSE */    

7

  RCC->CR |= ((uint32_t)RCC_CR_HSEON);

8

9

  /* Wait till HSE is ready and if Time out is reached exit */

10

  do

11

  {

12

    HSEStatus = RCC->CR & RCC_CR_HSERDY;

13

    StartUpCounter++;  

14

  } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));

15

16

  if ((RCC->CR & RCC_CR_HSERDY) != RESET)

17

  {

18

    HSEStatus = (uint32_t)0x01;

19

  }

20

  else

21

  {

22

    HSEStatus = (uint32_t)0x00;

23

  }  

24

25

  if (HSEStatus == (uint32_t)0x01)

26

  {

27

    /* Enable Prefetch Buffer */

28

    FLASH->ACR |= FLASH_ACR_PRFTBE;

29

30

    /* Flash 2 wait state */

31

    FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);

32

    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;    

33

34

35

    /* HCLK = SYSCLK */

36

    RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;

37

38

    /* PCLK2 = HCLK */

39

    RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE2_DIV1;

40

41

    /* PCLK1 = HCLK */

42

    RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE1_DIV2;

43

44

#ifdef STM32F10X_CL

45

    /* Configure PLLs ------------------------------------------------------*/

46

    /* PLL2 configuration: PLL2CLK = (HSE / 5) * 8 = 40 MHz */

47

    /* PREDIV1 configuration: PREDIV1CLK = PLL2 / 5 = 8 MHz */

48

49

    RCC->CFGR2 &= (uint32_t)~(RCC_CFGR2_PREDIV2 | RCC_CFGR2_PLL2MUL |

50

                              RCC_CFGR2_PREDIV1 | RCC_CFGR2_PREDIV1SRC);

51

    RCC->CFGR2 |= (uint32_t)(RCC_CFGR2_PREDIV2_DIV5 | RCC_CFGR2_PLL2MUL8 |

52

                             RCC_CFGR2_PREDIV1SRC_PLL2 | RCC_CFGR2_PREDIV1_DIV5);

53

54

    /* Enable PLL2 */

55

    RCC->CR |= RCC_CR_PLL2ON;

56

    /* Wait till PLL2 is ready */

57

    while((RCC->CR & RCC_CR_PLL2RDY) == 0)

58

    {

59

    }

60

61

62

    /* PLL configuration: PLLCLK = PREDIV1 * 9 = 72 MHz */ 

63

    RCC->CFGR &= (uint32_t)~(RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLSRC | RCC_CFGR_PLLMULL);

64

    RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLXTPRE_PREDIV1 | RCC_CFGR_PLLSRC_PREDIV1 | 

65

                            RCC_CFGR_PLLMULL9); 

66

#else    

67

    /*  PLL configuration: PLLCLK = HSE * 9 = 72 MHz */

68

    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE |

69

                                        RCC_CFGR_PLLMULL));

70

    RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL9);

71

#endif /* STM32F10X_CL */

72

73

    /* Enable PLL */

74

    RCC->CR |= RCC_CR_PLLON;

75

76

    /* Wait till PLL is ready */

77

    while((RCC->CR & RCC_CR_PLLRDY) == 0)

78

    {

79

    }

80

81

    /* Select PLL as system clock source */

82

    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));

83

    RCC->CFGR |= (uint32_t)RCC_CFGR_SW_PLL;    

84

85

    /* Wait till PLL is used as system clock source */

86

    while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS) != (uint32_t)0x08)

87

    {

88

    }

89

  }

90

  else

91

  { /* If HSE fails to start-up, the application will have wrong clock 

92

         configuration. User can add here some code to deal with this error */

93

  }

94

}

95

#endif

Hi Matthias,
danke für Deine Unterstützung!
Ja, die blinkende LED läuft einwandfrei. Inzwischen habe ich den Fehler 
einkreisen können. Erstmal habe ich die Takterzeugung für die Periperie 
angepaßt und die Frameerzeugung klappt nun stabil (auch nach Reset). Ich 
kann jetzt auf beiden CAN-Ports je nach Remap die CAN-Frames (am TX-Pin) 
sehen- dafür gibt es folgenden Endlos-Code:

1

  TestRx = CAN_Polling();

2

3

  /* CAN transmit at 500Kb/s and receive by interrupt in loopback mode */

4

5

while (1) {

6

  TestRx = CAN_Interrupt();

7

8

9

  if (TestRx == SUCCESS)

10

        success2();

11

12

13

  miniDelayLoop(); // winziger Delay

14

}

Wobei zu beachten ist, daß das Interrupt-Handling nicht aktiviert ist.
Sobald ich im Code (davor) die Funktion NVIC_Configuration() starte, 
gibt es keine Frames mehr. Ich kann nur vermuten, daß ich beim 
Konfigurieren des Interrupts den Prozessor einen Fehler mache und beim 
Auftreten des Interrupts läuft er in die Pampa. Der Interrupt 
USB_LP_CAN1_RX0_IRQn hat aber bei allen Devices (, die CAN unterstützen) 
den gleichen Index:

1

 USB_LP_CAN1_RX0_IRQn        = 20,     /*!< USB Device Low Priority or CAN1 RX0 Interrupts       */

haben. Hier die fragliche Funktion, die ich (gegenüber der REferenz) um 
den das Statement NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0); ergänzt 
habe.

1

void NVIC_Configuration(void)

2

{

3

  NVIC_InitTypeDef NVIC_InitStructure;

4

5

  NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0); // FLASH Vector Table ab 0x08000000 (Default)

6

7

  /* Enable CAN1 RX0 interrupt IRQ channel */

8

#ifndef STM32F10X_CL

9

  NVIC_InitStructure.NVIC_IRQChannel = USB_LP_CAN1_RX0_IRQn;

10

#else

11

 NVIC_InitStructure.NVIC_IRQChannel = CAN1_RX0_IRQn;

12

#endif /* STM32F10X_CL*/

13

  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;

14

  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;

15

  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

16

  NVIC_Init(&NVIC_InitStructure);

17

}

(...) und in der Testfunktion CAN_Interrupt wird der so konfigurierte 
Interrupt aktiviert:

1

 /* CAN FIFO0 message pending interrupt enable */ 

2

  CAN_ITConfig(CAN1, CAN_IT_FMP0, ENABLE);

Das Problem tritt aber nur auf, denn NVIC_Configuration() aufgerufen 
wurde - die Interrupt-Aktivierung habe ich nicht auskommentiert, ist 
also immer aktiv.


[EDIT]
Baudratenberechnung: ich meine, ich habe die Beispielwerte nicht 
geändert, werde aber den Link auswerten.
Konfiguriert ist:

1

 CAN_InitStructure.CAN_SJW=CAN_SJW_1tq;

2

  CAN_InitStructure.CAN_BS1=CAN_BS1_8tq;

3

  CAN_InitStructure.CAN_BS2=CAN_BS2_7tq;

4

  CAN_InitStructure.CAN_Prescaler=5;

Nach Deinem Excel-Sheet (super Sache :-) ) läuft dies auf 450kHz hinaus, 
bzw. 2.2us. Im Oszi sind es ca. 2,24 us.
[/EDIT]

Grüße
schnack

C. D. schrieb:
> NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0); // FLASH Vector Table ab 
0x08000000 (Default)

Aha, lass dir mal den Wert von der Vector-Table ohne den Funktionsaufruf 
ausgeben.

Hi Matthias,
hier liegt ja vielleicht der Hund begraben:

> Bist Du sicher, dass das Startup .s zu win-arm passt? In Bsp. sehen die
> dort anderes aus.

Die Startup-Datei habe aus dem Verzeichnis für ride-gcc entnommen 
(attachment).
Bislang hat damit alles - na ja, also die blinkende LED immerhin - 
funktioniert. Ich bin jetzt (nach Deinem Hinweis) von der XL auf die HD 
Variante umgestiegen.
Grüße
schnack

Hallo,
also der Wert der Vektor-Tabelle habe ich durch hinsteppen ermittelt, 
siehe attachment. Nun ist 134217728 = 0x8000000.
Die Statements mit reg sind (völlig überflüssig und) von mir.
Grüße
schnack

-> Attachment
Grüße
schnack

Hallo Matthias,
Dein Linker-Skript (auf 512K Flash, 64K RAM modifiziert) hat leider 
keine Änderung gebracht.

Ich fasse noch einmal zusammen:

A) Mit Aufruf "NVIC_Configuration()":
* CAN-Frames nach Download via JTAG, keine ISR-Behandlung
* nach Reset keine CAN-Frames, offenbar springt er beim Empfang in eine 
ISR und "verendet" dort (These dazu unten)

B) Ohne Aufruf "NVIC_Configuration()":
* CAN-Frames nach Download via JTAG oder USART, keine ISR-Behandlung
* nach Reset das gleiche Verhalten

Und schließlich:

A*) Mit Aufruf "NVIC_Configuration()":
Wenn ich (nicht in Eclipse) direkt im gdb (CodeSourcery) debugge, gibt 
er nach monitor reset und continue ebenso keine Frames aus. Bei 
Unterbrechen der Ausführung mit Crtl-C meldet er:

1

Program received signal SIGTRAP, Trace/breakpoint trap.

2

0x080030c8 in WWDG_IRQHandler ()

Wieso er in den Windowed Watch Dog Handler läuft, ist mir allerdings 
komplett ein Rätsel - schließlich ist dieser Interupt nicht 
konfiguriert. Offenbar ist dies der Interrupt-Handler, den er irrtümlich 
nach CAN-Frame Empfang aktiviert - und der besteht nur aus einer 
Endlosschleife..

Grüße
schnack