STM32: CAN Loopback mit merkwürdigem Effekt

[U. E. (Gast)]

Hi,
als frischgebackener Besitzer eines STM32F103 Stamp Moduls ich habe das 
CAN Loopback Beispiel aus der ST Standard Lib (3.4.0) ausprobiert und 
bin dabei auf einen merkwürdigen Effekt gestoßen.

Im Loopback-Modus kann man die CAN-Nachrichten auf dem Tx-Pin mitlesen.
(Der ganze Quellcode ist im Attachment)
Ich habe dafür wie folgt initialisiert:

    GPIO_InitTypeDef  GPIO_InitStructure;

    /* GPIO clock enable */
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO |RCC_APB2Periph_GPIO_CAN, ENABLE);

    /* Configure CAN pin: RX */
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_CAN_RX;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPU;
    GPIO_Init(GPIO_CAN, &GPIO_InitStructure);

    /* Configure CAN pin: TX */
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_CAN_TX;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(GPIO_CAN, &GPIO_InitStructure);

    GPIO_PinRemapConfig(GPIO_Remap_CAN , ENABLE);

An Pin 9 (Port B) kann ich dann das Tx-Signal auslesen.

Dann wird das CAN-Polling ausgeführt, danach die Interrupt-basierte 
CAN-Übertragung. Im Referenzbeispiel sind die Funktionen bereits 
ausformuliert.

Der Erfolg der CAN-Übertragungen soll über zwei LED's, der Mißerfolg 
über eine dritte LED angezeigt werden.
Beispiel für die "Erfolg"-LED bei CAN-Loopback:

  /* activating peripheral port A */
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA,ENABLE);

    /* setup Port 7 for Ports A as output with 2MHz clock: */
    GPIO_InitStructure.GPIO_Pin   = GPIO_Pin_7;
    GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_Out_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
    GPIO_Init(GPIOA, &GPIO_InitStructure);

    GPIOA->BSRR  = GPIO_Pin_7; /* LED On */

Bei einem Erfolg des CAN-Interrupt-Beispiels soll die LED an PortA, Pin7 
angehen. Der Fehler wird angezeigt durch eine LED auf Port C an Pin 7:

      /* activating peripheral port C */
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC,ENABLE);

    /* setup Port 7 for Ports A as output with 2MHz clock: */
    GPIO_InitStructure.GPIO_Pin   = GPIO_Pin_7;
    GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_Out_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
    GPIO_Init(GPIOC, &GPIO_InitStructure);

    GPIOC->BSRR  = GPIO_Pin_7; /* LED On */

Wo ist nun das Problem:

Beim ersten Start nach dem Flashen klappt die CAN-Übertragung- Moment: 
das CAN-Empfang via Interrupt klappt schon nicht mehr, aber immerhin 
CAN-Polling.
Damit es am Oszilloskop ordentlich was zu sehen gibt, wird die Funktion 
CAN-Interrupt-Testfunktion endlos aufgerufen. Leider wird nichts über 
die ISR empfangen (kein Einsprung), aber die Pakete gehen raus (man 
sieht es auf dem DSO).

Wenn ich nun auf den Reset-Button gehe und das Programm neue starte, 
gibt es keine Pakete mehr zu sehen, ja sogar die Funktion CAN-Polling 
geht nicht.
Wenn ich spaßeshalber das Remapping der CAN-Pins weglasse und 
neuprogrammiere, zeigt die LED Erfolg für das Polling an. Ein 
Wiedereinführen des Remapping zaubert wieder die Pakete auf das DSO - 
bis zum nächsten Reset.
Wenn ich den Strom für 30s aus und dann wieder einschalte, geht es immer 
noch nicht: Der Tx-Pin zeigt konstant '1' Pegel.

Meine Vermutung: irgendwelche Settings stimmen nach dem Reset nicht und 
werden merkwürdigerweise im Programm nicht richtig gesetzt.
Kann mir jemand helfen?
Grüße
schnack

[Matthias K. (matthiask)]

STMF32F103 ist eim Medium-Device. Dein Startup sieht nach einem 
XL-Device aus. Könnte sein, dass die Interruptvektoren oder was anderes 
im Startup nicht passt.

Was hast Du für eine CAN Infrastruktur dran oder nur den Loopback?

Ansonsten laufen eigentlich bei mir die 2 Beispiele der FW-Lib 3.4.0. 
Dort wird aber von weiteren bereits erfolgten Routinen zur 
Initialisierung (EVA-Bords) ausgegangen. Kann bei Dir zB. keine 
Systeminits, wie Takt, PLL, ABP-Takte usw. finden, oder übersehen?

Nochwas. Bei den 103ern geht USB und CAN nicht gemeinsam. Diese 
Erkenntnis hatte ich auch zunächst im Datasheet überlesen.

[U. E. (Gast)]

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:

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

[Matthias K. (matthiask)]

>/*!< At this stage the microcontroller clock setting is already
> configured, this is done through SystemInit() function which is
> called from startup file (startup_stm32f10x_xx.s) before to branch to
> application main. To reconfigure the default setting of SystemInit()
> function, refer to system_stm32f10x.c file */

Aber wo rufst Du es auf?

Ruf am Anfang mal diese beiden Routinen auf:

//***********************************************************************************************
// System-Einstellungen
//***********************************************************************************************
void SetupSystem (void) {

  RCC_DeInit ();                        // RCC System Reset(for debug purpose)

  // Enable HSE (Umschaltung auf externen Quarz)
  RCC_HSEConfig (RCC_HSE_ON);

  // HSE-Umschaltung abwarten
  while (RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET);

  // System-Taktung
  RCC_HCLKConfig   (RCC_SYSCLK_Div1);   // HCLK   = SYSCLK
  RCC_PCLK2Config  (RCC_HCLK_Div1);     // PCLK2 (APB2) = HCLK
  RCC_PCLK1Config  (RCC_HCLK_Div2);     // PCLK1 (APB1) = HCLK/2

  // FLASH-Speicher Zugriffstechnik
  FLASH_SetLatency(FLASH_Latency_2);                        // Flash - 2 wait states
  FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);     // Pipeline freigeben
  
  // PLL Konfiguration
  // PLLCLK = 8MHz * 9 = 72 MHz
  RCC_PLLConfig (RCC_PLLSource_HSE_Div1, RCC_PLLMul_9);     // Externer Quarz, Faktor 9
  RCC_PLLCmd (ENABLE);                                      // Enable PLL

  // PLL-Konfiguration abwarten
  while (RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET);

  // PLL als System-Takt auswählen
  RCC_SYSCLKConfig (RCC_SYSCLKSource_PLLCLK);

  // PLL-Umschaltung abwarten
  while (RCC_GetSYSCLKSource() != 0x08);
}

//***********************************************************************************************
// Nested Vectored Interrupt Controller initialisieren
//***********************************************************************************************
void NVIC_Configuration(void) {

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

}

[U. E. (Gast)]

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

[U. E. (Gast)]

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:

    .section  .text.Reset_Handler
  .weak  Reset_Handler
  .type  Reset_Handler, %function
Reset_Handler:  

/* Copy the data segment initializers from flash to SRAM */  
  movs  r1, #0
  b  LoopCopyDataInit

CopyDataInit:
  ldr  r3, =_sidata
  ldr  r3, [r3, r1]
  str  r3, [r0, r1]
  adds  r1, r1, #4
    
LoopCopyDataInit:
  ldr  r0, =_sdata
  ldr  r3, =_edata
  adds  r2, r0, r1
  cmp  r2, r3
  bcc  CopyDataInit
  ldr  r2, =_sbss
  b  LoopFillZerobss
/* Zero fill the bss segment. */  
FillZerobss:
  movs  r3, #0
  str  r3, [r2], #4
    
LoopFillZerobss:
  ldr  r3, = _ebss
  cmp  r2, r3
  bcc  FillZerobss
/* Call the clock system intitialization function.*/
  bl  SystemInit   
/* Call the application's entry point.*/
  bl  main
  bx  lr    
.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

[U. E. (Gast)]

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...

[Matthias K. (matthiask)]

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

Das macht nur eine Herstellung einer Default-Einstellung. Reicht nicht 
aus.

[U. E. (Gast)]

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

(...)
  /* Configure the System clock frequency, HCLK, PCLK2 and PCLK1 prescalers */
  /* Configure the Flash Latency cycles and enable prefetch buffer */
  SetSysClock();
 (...)

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.

static void SetSysClockTo72(void)
{
  __IO uint32_t StartUpCounter = 0, HSEStatus = 0;
  
  /* SYSCLK, HCLK, PCLK2 and PCLK1 configuration ---------------------------*/    
  /* Enable HSE */    
  RCC->CR |= ((uint32_t)RCC_CR_HSEON);
 
  /* Wait till HSE is ready and if Time out is reached exit */
  do
  {
    HSEStatus = RCC->CR & RCC_CR_HSERDY;
    StartUpCounter++;  
  } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));

  if ((RCC->CR & RCC_CR_HSERDY) != RESET)
  {
    HSEStatus = (uint32_t)0x01;
  }
  else
  {
    HSEStatus = (uint32_t)0x00;
  }  

  if (HSEStatus == (uint32_t)0x01)
  {
    /* Enable Prefetch Buffer */
    FLASH->ACR |= FLASH_ACR_PRFTBE;

    /* Flash 2 wait state */
    FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;    

 
    /* HCLK = SYSCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;
      
    /* PCLK2 = HCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE2_DIV1;
    
    /* PCLK1 = HCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE1_DIV2;

#ifdef STM32F10X_CL
    /* Configure PLLs ------------------------------------------------------*/
    /* PLL2 configuration: PLL2CLK = (HSE / 5) * 8 = 40 MHz */
    /* PREDIV1 configuration: PREDIV1CLK = PLL2 / 5 = 8 MHz */
        
    RCC->CFGR2 &= (uint32_t)~(RCC_CFGR2_PREDIV2 | RCC_CFGR2_PLL2MUL |
                              RCC_CFGR2_PREDIV1 | RCC_CFGR2_PREDIV1SRC);
    RCC->CFGR2 |= (uint32_t)(RCC_CFGR2_PREDIV2_DIV5 | RCC_CFGR2_PLL2MUL8 |
                             RCC_CFGR2_PREDIV1SRC_PLL2 | RCC_CFGR2_PREDIV1_DIV5);
  
    /* Enable PLL2 */
    RCC->CR |= RCC_CR_PLL2ON;
    /* Wait till PLL2 is ready */
    while((RCC->CR & RCC_CR_PLL2RDY) == 0)
    {
    }
    
   
    /* PLL configuration: PLLCLK = PREDIV1 * 9 = 72 MHz */ 
    RCC->CFGR &= (uint32_t)~(RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLSRC | RCC_CFGR_PLLMULL);
    RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLXTPRE_PREDIV1 | RCC_CFGR_PLLSRC_PREDIV1 | 
                            RCC_CFGR_PLLMULL9); 
#else    
    /*  PLL configuration: PLLCLK = HSE * 9 = 72 MHz */
    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE |
                                        RCC_CFGR_PLLMULL));
    RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL9);
#endif /* STM32F10X_CL */

    /* Enable PLL */
    RCC->CR |= RCC_CR_PLLON;

    /* Wait till PLL is ready */
    while((RCC->CR & RCC_CR_PLLRDY) == 0)
    {
    }
    
    /* Select PLL as system clock source */
    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));
    RCC->CFGR |= (uint32_t)RCC_CFGR_SW_PLL;    

    /* Wait till PLL is used as system clock source */
    while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS) != (uint32_t)0x08)
    {
    }
  }
  else
  { /* If HSE fails to start-up, the application will have wrong clock 
         configuration. User can add here some code to deal with this error */
  }
}
#endif

[Matthias K. (matthiask)]

Habe ich auch keine wirkliche Idee mehr. Bist Du sicher, dass das 
Startup .s zu win-arm passt? In Bsp. sehen die dort anderes aus. Mit 
Keil laufen auf jedem Fall die Startups der STM FW-Lib. Mit dem 
AtollicTrue Studio gehen die nicht, basiert auch auf Win-Arm.

Hast Du ein Blinky schon mal einwandfrei zum laufen gebracht?

Oder lade Dir mal zum testen die Keil MDK EVA-Version runter.
http://www.keil.com/arm/mdk.asp

[U. E. (Gast)]

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:

  TestRx = CAN_Polling();

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

while (1) {
  TestRx = CAN_Interrupt();


  if (TestRx == SUCCESS)
        success2();


  miniDelayLoop(); // winziger Delay
}

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:

 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.

void NVIC_Configuration(void)
{
  NVIC_InitTypeDef NVIC_InitStructure;

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

  /* Enable CAN1 RX0 interrupt IRQ channel */
#ifndef STM32F10X_CL
  NVIC_InitStructure.NVIC_IRQChannel = USB_LP_CAN1_RX0_IRQn;
#else
 NVIC_InitStructure.NVIC_IRQChannel = CAN1_RX0_IRQn;
#endif /* STM32F10X_CL*/
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&NVIC_InitStructure);
}

[Matthias K. (matthiask)]

Interruptproblem: Kommt immer wieder auf das Startup/Interruptvektoren 
zurück.

Stimmt die CAN-Bitrate? Oszi überprüft? Eventuell kann man daraus 
Rückschluß ziehen, ob die Systemfrequenz laut SystemInit überhaupt 
stimmt.

Ggf. hier mal gegenprüfen.
Beitrag "STM32 CAN Baudrate Berechnung (Can Bit Timing)"

[U. E. (Gast)]

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

 /* CAN FIFO0 message pending interrupt enable */ 
  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:

 CAN_InitStructure.CAN_SJW=CAN_SJW_1tq;
  CAN_InitStructure.CAN_BS1=CAN_BS1_8tq;
  CAN_InitStructure.CAN_BS2=CAN_BS2_7tq;
  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

[Matthias K. (matthiask)]

>CAN_ITConfig(CAN1, CAN_IT_FMP0, ENABLE);

Ist korrekt, der Fehler liegt nicht daran.

Die Bitraten in der FW-Lib sind für 8MHz fPCLK (APB1), stimmen also nur 
bedingt. Meist wird aber mit APB1 = 36MHz gearbeitet.

[Upsi (Gast)]

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.

[U. E. (Gast)]

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

[U. E. (Gast)]

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

[Matthias K. (matthiask)]

Was für ein Linkerscript (.ld) benutzt Du?

[U. E. (Gast)]

-> Attachment
Grüße
schnack

[Matthias K. (matthiask)]

Hier eines für WinARM, Atollic, ist aber für den 128k-Flash-Typ (md). 
Adressen für hd noch anpassen. Vielleicht hilfreich?

[U. E. (Gast)]

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:

Program received signal SIGTRAP, Trace/breakpoint trap.
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