Offset des User Codes für einen Bootloader beim ARM Cortex M4 Infenion XMC4500

[Bubba L. (pic24h)]

Hallo Miteinander,

ich habe eine allgemeine Frage beim verschieben (Offset) vom User Code 
bei einem ARM Cortex M4.

Ich hab einen Bootloader und dazu eine Windows Applikation erstellt, die 
mit dem Bootloader kommuniziert und die zu ladende Hex File überträgt.

Das Übertragen und speichern scheint zu funktionieren, da der Speicher 
nachdem übertragen der Hex File, ausgelesen wurde und sich an der 
definierten Adresse dann Daten zu finden sind.

Was nicht funktioniert ist das Springen zum User Code.
Der Bootloader befindet sich am Anfang des Flash Speichers und der User 
Code am Anfang vom nächsten Sektor.

Im Linker Script des User Codes wurde wurde ein Offset erstellt.

MEMORY
{
  FLASH_1_cached(RX) : ORIGIN = 0x08004000, LENGTH = 0x100000-0x4000
  FLASH_1_uncached(RX) : ORIGIN = 0x0C004000, LENGTH = 0x100000-0x4000
  PSRAM_1(!RX) : ORIGIN = 0x10000000, LENGTH = 0x10000
  DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x10000
  DSRAM_2_comm(!RX) : ORIGIN = 0x30000000, LENGTH = 0x8000
}

In der Map File befindet sich der Reset Handler an der Offset Adresse.

Der Sprung vom Bootloader zum User Code funktioniert leider irgendwie 
nicht.


void RunFlash(void)
{
   __asm(
       "ldr r0, =0x0C004000\n"
         "ldr r1, =0xE000ED08\n"  //VTOR register
     "str r0,[r1]\n"
       "ldr sp, [r0], #4\n"
         "ldr r15, [R0]"
    );
}


Bin recht neu in der ARM Welt unterwegs.

Hat vielleicht jemand einen Tipp für mich?

[Lothar (Gast)]

Bubba L. schrieb:
> Der Bootloader befindet sich am Anfang des Flash Speichers und der User
> Code am Anfang vom nächsten Sektor

Zur Info: die meisten ARM ausser XMC z.B. LPC, STM32 haben einen ROM 
(oder Flash Security Page) Bootloader. Das ROM wird als High Memory 
eingeblendet. Der User Code beginnt also unabhängig davon, ob ein 
Bootloader existiert oder nicht, bei 0 und beinhaltet die Vektortabelle. 
Somit müssen nicht verschiedene HEX gelinkt werden.

Zum Starten des User Code aus einem Bootloader, der selbst nach der 
Vektortabelle beginnt, wird am einfachsten ein Software-Reset ausgelöst 
mit NVIC_SystemReset()

[boot @ 0000 0000 h (Gast)]

Da schau ich mal ins Manual:
On system reset, the vector table is fixed at address 0x00000000. 
Privileged software
can write to the VTOR to relocate the vect
or table start address to a different memory
location, in the range 0x00000400 to 0x3FFF
FC00

[Jim M. (turboj)]

Bubba L. schrieb:
> Hat vielleicht jemand einen Tipp für mich?

Debugger ranhängen und uns mitteilen wo genau er aussteigt.

Was gerne vergessen wird ist das T-Bit bei Vectoradressen, dann würde 
"LDR PC, [R0]" in einem Hardfault enden.

[Bubba L. (pic24h)]

Lothar schrieb:
> Bubba L. schrieb:
>> Der Bootloader befindet sich am Anfang des Flash Speichers und der User
>> Code am Anfang vom nächsten Sektor
>
> Zur Info: die meisten ARM ausser XMC z.B. LPC, STM32 haben einen ROM
> (oder Flash Security Page) Bootloader. Das ROM wird als High Memory
> eingeblendet. Der User Code beginnt also unabhängig davon, ob ein
> Bootloader existiert oder nicht, bei 0 und beinhaltet die Vektortabelle.
> Somit müssen nicht verschiedene HEX gelinkt werden.
>
> Zum Starten des User Code aus einem Bootloader, der selbst nach der
> Vektortabelle beginnt, wird am einfachsten ein Software-Reset ausgelöst
> mit NVIC_SystemReset()

Nach der Vektortabelle beginnt zuerst der Bootloader. Er wartet 3 
Sekunden auf ein Befehl die UART Schnittstelle. Wenn kein Befehl 
erhalten wird, dann soll er zum User Code an der Adresse (0x0C004000) 
springen.

boot @ 0000 0000 h schrieb:
> Da schau ich mal ins Manual:
> On system reset, the vector table is fixed at address 0x00000000.
> Privileged software
> can write to the VTOR to relocate the vect
> or table start address to a different memory
> location, in the range 0x00000400 to 0x3FFF
> FC00

Das habe ich auch gelesen, aber weiß nicht wie ich den privileged modus 
starte oder ob dieser automatisch bei einem bestimmten Befehl kurz 
aktiviert wird? Ich habe den Offset mit diesen beiden Befehlen versucht.

PPB->VTOR = 0x0C004000;
SCB->VTOR = 0x0C004000;

Jim M. schrieb:
> Bubba L. schrieb:
>> Hat vielleicht jemand einen Tipp für mich?
>
> Debugger ranhängen und uns mitteilen wo genau er aussteigt.
>
> Was gerne vergessen wird ist das T-Bit bei Vectoradressen, dann würde
> "LDR PC, [R0]" in einem Hardfault enden.

Er steigt an der Adresse 0x080042B0 aus mit der Meldung

" No source available for "0x80042b0"  ".

0x08004000 ist identisch zu 0x0C00400. Beim auslesen des Flash sind an 
den Adressen aufwärts die Daten identisch.

Was ist ein T-Bit? Wiki hat mich nicht schlauer gemacht 
(https://de.wikipedia.org/wiki/Sticky_Bit).

Den Sprung befehl habe ich aus dem Bootloader Beispiel von Infenion 
entnommen.

[Bubba L. (pic24h)]

Hier ein Screenshot der beiden Adressen vom Flash

[Bubba L. (pic24h)]

Hier ein ein Screenshot vom Disassembly während dem Debuggen.
Hier scheint es so als ob an der Adresse 0x0C004000 keine Befehle 
vorhanden sind?

Er gelangt aber trotzden bis zur Adresse 0x080042B0 bevor die Meldung
"No source available for "0x80042b0" ausgegeben wird.

[Jim M. (turboj)]

Bubba L. schrieb:
> Er steigt an der Adresse 0x080042B0 aus mit der Meldung
>
> " No source available for "0x80042b0"  ".

Das ist dann wohl ein Fault, denn im anderen Posting sieht man dass das 
die Default Handler Addresse ist. Und zwar die von der Applikation.
Ich definiere mir immer einen eigenen Handler dafür, dann sieht man 
Fehler besser.

Für die Source müsstest Du jetzt die Symbole der Applikation nachladen, 
der
Default Handler ist aber oft in einem Assembler File deklariert.


Bubba L. schrieb:
> Was ist ein T-Bit?
Das unterste Bit der Addresse, bei Dir überall korrekt gesetzt. Schaltet 
bei ARM zwischen ARM- und Thumb Instruktionen um.

Was Du überprüfen solltest sind die Linker Flags der Applikation. Wenn 
die flachsen Libs verlinkt wurden wäre das eine Ursache für einen Fault, 
man mus auch dem Linker den CPU Typ mitgeben.

[Bubba L. (pic24h)]

Jim M. schrieb:
> Das ist dann wohl ein Fault, denn im anderen Posting sieht man dass das
> die Default Handler Addresse ist. Und zwar die von der Applikation.
> Ich definiere mir immer einen eigenen Handler dafür, dann sieht man
> Fehler besser.

Blöde Frage...wie definiert man den am Besten? Hast du da ein Beispiel?

in der startup.S Datei ist folgendes bereits drin

/* ======================================================================== */
/* ========== START OF EXCEPTION HANDLER DEFINITION ======================== */

/* Default exception Handlers - Users may override this default functionality by
   defining handlers of the same name in their C code */

  .align  1
    .thumb_func
    .weak Default_Handler
    .type Default_Handler, %function
Default_Handler:
    b .
    .size Default_Handler, . - Default_Handler

     Insert_ExceptionHandler NMI_Handler
     Insert_ExceptionHandler HardFault_Handler
     Insert_ExceptionHandler MemManage_Handler
     Insert_ExceptionHandler BusFault_Handler
     Insert_ExceptionHandler UsageFault_Handler
     Insert_ExceptionHandler SVC_Handler
     Insert_ExceptionHandler DebugMon_Handler
     Insert_ExceptionHandler PendSV_Handler
     Insert_ExceptionHandler SysTick_Handler

     Insert_ExceptionHandler SCU_0_IRQHandler
     Insert_ExceptionHandler ERU0_0_IRQHandler
     Insert_ExceptionHandler ERU0_1_IRQHandler
     Insert_ExceptionHandler ERU0_2_IRQHandler
     Insert_ExceptionHandler ERU0_3_IRQHandler
     Insert_ExceptionHandler ERU1_0_IRQHandler
     Insert_ExceptionHandler ERU1_1_IRQHandler
     Insert_ExceptionHandler ERU1_2_IRQHandler
     Insert_ExceptionHandler ERU1_3_IRQHandler
     Insert_ExceptionHandler PMU0_0_IRQHandler
     Insert_ExceptionHandler VADC0_C0_0_IRQHandler
     Insert_ExceptionHandler VADC0_C0_1_IRQHandler
     Insert_ExceptionHandler VADC0_C0_2_IRQHandler
     Insert_ExceptionHandler VADC0_C0_3_IRQHandler
     Insert_ExceptionHandler VADC0_G0_0_IRQHandler
     Insert_ExceptionHandler VADC0_G0_1_IRQHandler
     Insert_ExceptionHandler VADC0_G0_2_IRQHandler
     Insert_ExceptionHandler VADC0_G0_3_IRQHandler
     Insert_ExceptionHandler VADC0_G1_0_IRQHandler
     Insert_ExceptionHandler VADC0_G1_1_IRQHandler
     Insert_ExceptionHandler VADC0_G1_2_IRQHandler
     Insert_ExceptionHandler VADC0_G1_3_IRQHandler
     Insert_ExceptionHandler VADC0_G2_0_IRQHandler
     Insert_ExceptionHandler VADC0_G2_1_IRQHandler
     Insert_ExceptionHandler VADC0_G2_2_IRQHandler
     Insert_ExceptionHandler VADC0_G2_3_IRQHandler
     Insert_ExceptionHandler VADC0_G3_0_IRQHandler
     Insert_ExceptionHandler VADC0_G3_1_IRQHandler
     Insert_ExceptionHandler VADC0_G3_2_IRQHandler
     Insert_ExceptionHandler VADC0_G3_3_IRQHandler
     Insert_ExceptionHandler DSD0_0_IRQHandler
     Insert_ExceptionHandler DSD0_1_IRQHandler
     Insert_ExceptionHandler DSD0_2_IRQHandler
     Insert_ExceptionHandler DSD0_3_IRQHandler
     Insert_ExceptionHandler DSD0_4_IRQHandler
     Insert_ExceptionHandler DSD0_5_IRQHandler
     Insert_ExceptionHandler DSD0_6_IRQHandler
     Insert_ExceptionHandler DSD0_7_IRQHandler
     Insert_ExceptionHandler DAC0_0_IRQHandler
     Insert_ExceptionHandler DAC0_1_IRQHandler
     Insert_ExceptionHandler CCU40_0_IRQHandler
     Insert_ExceptionHandler CCU40_1_IRQHandler
     Insert_ExceptionHandler CCU40_2_IRQHandler
     Insert_ExceptionHandler CCU40_3_IRQHandler
     Insert_ExceptionHandler CCU41_0_IRQHandler
     Insert_ExceptionHandler CCU41_1_IRQHandler
     Insert_ExceptionHandler CCU41_2_IRQHandler
     Insert_ExceptionHandler CCU41_3_IRQHandler
     Insert_ExceptionHandler CCU42_0_IRQHandler
     Insert_ExceptionHandler CCU42_1_IRQHandler
     Insert_ExceptionHandler CCU42_2_IRQHandler
     Insert_ExceptionHandler CCU42_3_IRQHandler
     Insert_ExceptionHandler CCU43_0_IRQHandler
     Insert_ExceptionHandler CCU43_1_IRQHandler
     Insert_ExceptionHandler CCU43_2_IRQHandler
     Insert_ExceptionHandler CCU43_3_IRQHandler
     Insert_ExceptionHandler CCU80_0_IRQHandler
     Insert_ExceptionHandler CCU80_1_IRQHandler
     Insert_ExceptionHandler CCU80_2_IRQHandler
     Insert_ExceptionHandler CCU80_3_IRQHandler
     Insert_ExceptionHandler CCU81_0_IRQHandler
     Insert_ExceptionHandler CCU81_1_IRQHandler
     Insert_ExceptionHandler CCU81_2_IRQHandler
     Insert_ExceptionHandler CCU81_3_IRQHandler
     Insert_ExceptionHandler POSIF0_0_IRQHandler
     Insert_ExceptionHandler POSIF0_1_IRQHandler
     Insert_ExceptionHandler POSIF1_0_IRQHandler
     Insert_ExceptionHandler POSIF1_1_IRQHandler
     Insert_ExceptionHandler CAN0_0_IRQHandler
     Insert_ExceptionHandler CAN0_1_IRQHandler
     Insert_ExceptionHandler CAN0_2_IRQHandler
     Insert_ExceptionHandler CAN0_3_IRQHandler
     Insert_ExceptionHandler CAN0_4_IRQHandler
     Insert_ExceptionHandler CAN0_5_IRQHandler
     Insert_ExceptionHandler CAN0_6_IRQHandler
     Insert_ExceptionHandler CAN0_7_IRQHandler
     Insert_ExceptionHandler USIC0_0_IRQHandler
     Insert_ExceptionHandler USIC0_1_IRQHandler
     Insert_ExceptionHandler USIC0_2_IRQHandler
     Insert_ExceptionHandler USIC0_3_IRQHandler
     Insert_ExceptionHandler USIC0_4_IRQHandler
     Insert_ExceptionHandler USIC0_5_IRQHandler
     Insert_ExceptionHandler USIC1_0_IRQHandler
     Insert_ExceptionHandler USIC1_1_IRQHandler
     Insert_ExceptionHandler USIC1_2_IRQHandler
     Insert_ExceptionHandler USIC1_3_IRQHandler
     Insert_ExceptionHandler USIC1_4_IRQHandler
     Insert_ExceptionHandler USIC1_5_IRQHandler
     Insert_ExceptionHandler USIC2_0_IRQHandler
     Insert_ExceptionHandler USIC2_1_IRQHandler
     Insert_ExceptionHandler USIC2_2_IRQHandler
     Insert_ExceptionHandler USIC2_3_IRQHandler
     Insert_ExceptionHandler USIC2_4_IRQHandler
     Insert_ExceptionHandler USIC2_5_IRQHandler
     Insert_ExceptionHandler LEDTS0_0_IRQHandler
     Insert_ExceptionHandler FCE0_0_IRQHandler
     Insert_ExceptionHandler GPDMA0_0_IRQHandler
     Insert_ExceptionHandler SDMMC0_0_IRQHandler
     Insert_ExceptionHandler USB0_0_IRQHandler
     Insert_ExceptionHandler ETH0_0_IRQHandler
     Insert_ExceptionHandler GPDMA1_0_IRQHandler
     
/* ============= END OF INTERRUPT HANDLER DEFINITION ====================== */

Jim M. schrieb:
> Für die Source müsstest Du jetzt die Symbole der Applikation nachladen,
> der
> Default Handler ist aber oft in einem Assembler File deklariert.

Nachladen? Wie genau? Die müssten doch bereits im Flash liegen, oder?

Jim M. schrieb:
> Was Du überprüfen solltest sind die Linker Flags der Applikation. Wenn
> die flachsen Libs verlinkt wurden wäre das eine Ursache für einen Fault,
> man mus auch dem Linker den CPU Typ mitgeben.

Das müsste doch im linker script stehen oder? Finde da nichts :(

[Markus S (Gast)]

Hallo,

vom Prinzip ist dein Linkerscript schon richtig.
Bei mir liegt der Bootloader in den ersten 64K. Und die Applikation ab 
0x8080000.

Wenn ich aus dem Bootloader die Applikation starten möchte, dann biege 
ich den internen Bootloader auf den "Alternative Boot mode" um (Siehe 
Kapitel: 26 "Startup modes" im Reference Manual)

Hier ein Beispiel wie ich es mache:
Zuvor noch den Sektor für "flash_abm0" im Linkerscript definieren usw.
Wenn du eine andere Startadresse benutzt, dann entsprechend die CRC32 
neu berechnen.


static const ABM_Header_t __attribute__((section(".flash_abm0"))) 
ABM0_Header=
{
    // 0x5AC3E10F (RM : Kap 26.2.5)
    .MagicKey = MAGIC_KEY,
    // Adresse ab der die Applikation liegt
    .StartAddress = 0x08080000,
    .Length = 0xFFFFFFFF,
    .ApplicationCRC32 = 0xFFFFFFFF,
    .HeaderCRC32 =  0xCBF94C7D
};


void StartApplication(void)
{
  SCU_RESET->RSTCLR = 1<<SCU_RESET_RSTCLR_RSCLR_Pos;

  WR_REG( SCU_GENERAL->STCON,
      SCU_GENERAL_STCON_SWCON_Msk,
      SCU_GENERAL_STCON_SWCON_Pos,
      SW_CONFIG_ABM0);

  PPB->AIRCR =  (1 << PPB_AIRCR_SYSRESETREQ_Pos)
          | (0x5FA<<PPB_AIRCR_VECTKEY_Pos)
          | (0x1 << PPB_AIRCR_PRIGROUP_Pos);
}


Gruss Markus

[Bubba L. (pic24h)]

Markus S schrieb:
> Wenn ich aus dem Bootloader die Applikation starten möchte, dann biege
> ich den internen Bootloader auf den "Alternative Boot mode" um (Siehe
> Kapitel: 26 "Startup modes" im Reference Manual)

Ich habe auch mit dem Gedanken gespielt, es mit dem ABM Modus zu 
versuchen, aber habe es doch nicht probiert :(

Markus S schrieb:
> Hier ein Beispiel wie ich es mache:
> Zuvor noch den Sektor für "flash_abm0" im Linkerscript definieren usw.

Der Sektor für "flash_abm0" ist laut Reference Manual die letzten 32 
Bytes des PSRAMS. also von 0xFFFFFFF00 bis zum Ende. Ich werde es dann 
so definieren.

MEMORY
{
  FLASH_1_cached(RX) : ORIGIN = 0x08004000, LENGTH = 0x100000-0x4000
  FLASH_1_uncached(RX) : ORIGIN = 0x0C004000, LENGTH = 0x100000-0x4000
  PSRAM_1(!RX) : ORIGIN = 0x10000000, LENGTH = 0xFF00
  PSRAM_ABM (!RX) : ORIGIN = 0x1000FF00, LENGTH = 0x100
  DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x10000
  DSRAM_2_comm(!RX) : ORIGIN = 0x30000000, LENGTH = 0x8000
}

Du hast den ABM aber im flash wie ich sehe??

Markus S schrieb:
> Wenn du eine andere Startadresse benutzt, dann entsprechend die CRC32
> neu berechnen.

Zur CRC Berechnung werde ich mal den Code ausm Infenion Forum 
verwenden... 
[http://www.infineonforums.com/threads/2114-Crc32?p=6561&viewfull=1#post6561]

Ein System Reset hast du ja nicht gebraucht,oder?

Danke für die Tipps. Werde es morgen früh mal testen.

[Bubba L. (pic24h)]

Hallo zusammen,

bin erst heute wieder dazu gekommen an dem Bootloader weiter zu 
arbeiten.

Aktueller Status:

Ich habe mir jetzt den ABM Header erstellt.
Eine Frage zu den CRC Prüfsummen. Diese müssen ja auf den "leeren" 
Speicherbereich angewendet werden, also wenn noch keine Applikation über 
den Bootloader geladen wurde?

Der Header wird einmal an die Adresse 0x0C00FFE0 geflasht und gut is.
Jedoch wenn ich den internen Bootloader auf den Alternate Boot Mode 
umbiege, dann läuft was schief und der Mikrocontroller reagiert nicht, 
auch nicht auf einen system reset. Nach einem PORST ist dann wieder 
alles normal bis der interne Bootloader wieder auf den ABM Mode gebogen 
wird.

Ich nehme an dass der diagnostics monitor mode gestartet (RM: Kap 
26.2.6) wird weil der Stromverbauch sinkt, nachdem auf ABM gestellt 
wurde und ein system reset erfolgt. Der Header ist vermutlich corrputed.


Für die Berechnung habe ich folgende Funktionen (aus einem ABM 
Beispielcode von Infenion) verwendet

uword crc_gen (uword *data, uword size)
{
uword crc = 0xFFFFFFFF;
for(uword i=0; i<size; ++i) {
uword word = *(data+i);
uword feedback =
((crc & (1 << 31)) ? 1 : 0) ^
((crc & (1 << 30)) ? 1 : 0) ^
((crc & (1 << 29)) ? 1 : 0) ^
((crc & (1 << 27)) ? 1 : 0) ^
((crc & (1 << 26)) ? 1 : 0) ^
((crc & (1 << 24)) ? 1 : 0) ^
((crc & (1 << 23)) ? 1 : 0) ^
((crc & (1 << 21)) ? 1 : 0) ^
((crc & (1 << 20)) ? 1 : 0) ^
((crc & (1 << 19)) ? 1 : 0) ^
((crc & (1 << 15)) ? 1 : 0) ^
((crc & (1 << 9)) ? 1 : 0) ^
((crc & (1 << 8)) ? 1 : 0) ^
((crc & (1 << 5)) ? 1 : 0);

crc = ((word ^ ((crc & 0x7fffffff) << 1)) & 0xfffffffe) | (feedback ^ ((word & 1) ? 1 : 0));
}

return crc;

}


uword Calculate_WordSize (uword start, uword end)
{
uword size;

size = (end-start);
size = size >> 2;

return size;
}

Die Size der Applikation wurde mit folgenden Parametern berechnet.

size = Calculate_WordSize (0x0C080000, 0x0C010000)
crc_gen(0x0C080000,size);

und ABM Header habe ich berechnet mit

size = Calculate_WordSize (0x0C00FFE0, 0x0C00FFF8)
crc_gen(0x0C00FFE0,size);

Mein Fehler liegt womöglich daran dass ich bei Berechnen der crc nicht 
einen pointer auf die Daten übergeben habe. Im Beispiel wurde die start 
adresse wie folgt berechnet

start = (uword *)abm0[2];

Werde es morgen nochmal probieren.

@Markus S

Nach der Funktion StartApplication() muss ein SystemReset erfolgen, 
oder?

void StartApplication(void)
{
  SCU_RESET->RSTCLR = 1<<SCU_RESET_RSTCLR_RSCLR_Pos;

  WR_REG( SCU_GENERAL->STCON,
      SCU_GENERAL_STCON_SWCON_Msk,
      SCU_GENERAL_STCON_SWCON_Pos,
      SW_CONFIG_ABM0);

  PPB->AIRCR =  (1 << PPB_AIRCR_SYSRESETREQ_Pos)
          | (0x5FA<<PPB_AIRCR_VECTKEY_Pos)
          | (0x1 << PPB_AIRCR_PRIGROUP_Pos);
}

[Bubba L. (pic24h)]

Habe es hinbekommen. Danke für eure Hilfe.

[W.S. (Gast)]

Ein Nachtrag:

Lothar schrieb:
> Zur Info: die meisten ARM ausser XMC z.B. LPC, STM32 haben einen ROM
> (oder Flash Security Page) Bootloader. Das ROM wird als High Memory
> eingeblendet. Der User Code beginnt also unabhängig davon, ob ein
> Bootloader existiert oder nicht, bei 0 und beinhaltet die Vektortabelle.
> Somit müssen nicht verschiedene HEX gelinkt werden.

Tja. Diese XMC sind eben genau deshalb auf meiner privaten schwarzen 
Liste. Bei den M4 Varianten könnte man ja (vermutlichst) die 
Vektortabelle umverlegen, aber bei den M0 und M0+ geht das nicht, also 
ist man auf deren von DAVE generierten Krempel angewiesen - und das ist 
mir so unangenehm wie ne Kette am Nasenring und damit bei Infineon 
angeschmiedet.

W.S.

[Bernd K. (prof7bit)]

W.S. schrieb:
> aber bei den M0 und M0+ geht das nicht

Bei allen Cortexen ab (inclusive) M0+ aufwärts kann man die 
Vektortabelle verlegen. Das ist ein Feature von ARM, nicht des 
Herstellers. Nur bei M0 bin ich mir nicht sicher ob das da auch geht.

[Leo (Gast)]

Hallo,

das mit der CRC Berechnung für den ABM funktioniert bei mir ebenfalls 
nicht.
Welche CRC Funktion müsste ich dazu verwenden? Welche Übergabeparamter 
muss ich der CRC Funktion geben?