Die STM32 Mikrocontroller Familie bittet die Möglichkeit einen CRC (Cyclic redundancy check) über bestimmte Speicherbereiche zu berechnen. Jedoch war es mit den default Einstellungen nicht ohne Weiteres möglich, das selbe Ergebnis zu erzielen.

Ausgangspunkt war folgender:

Der CRC-32 für das Programm im Flashspeicher des Mikrocontrollers sollte mit dem CRC-32 über das Binärfile verglichen werden können.
Da die STM32 Chips einen Hardware CRC bereitstellen, sollte dieser auch genutzt werden.

Aktivierung des CRC im Cube MX

Die default Einstellungen im Cube MX, einem Tool zum Konfigurieren von STM32 Chips schaut wie folgt aus:

Im Quellcode wird dann folgender Hardware Init Code erzeugt:

/**
  * @brief CRC Initialization Function
  * @param None
  * @retval None
  */
static void MX_CRC_Init(void)
{

  /* USER CODE BEGIN CRC_Init 0 */

  /* USER CODE END CRC_Init 0 */

  /* USER CODE BEGIN CRC_Init 1 */

  /* USER CODE END CRC_Init 1 */
  hcrc.Instance = CRC;
  hcrc.Init.DefaultPolynomialUse = DEFAULT_POLYNOMIAL_ENABLE;
  hcrc.Init.DefaultInitValueUse = DEFAULT_INIT_VALUE_ENABLE;
  hcrc.Init.InputDataInversionMode = CRC_INPUTDATA_INVERSION_NONE;
  hcrc.Init.OutputDataInversionMode = CRC_OUTPUTDATA_INVERSION_DISABLE;
  hcrc.InputDataFormat = CRC_INPUTDATA_FORMAT_BYTES;
  if (HAL_CRC_Init(&hcrc) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN CRC_Init 2 */

  /* USER CODE END CRC_Init 2 */
}

Im Usercode lässt sich dann folgende HAL Funktion ausführen:

uint32_t HAL_CRC_Calculate(CRC_HandleTypeDef *hcrc, uint32_t pBuffer[], uint32_t BufferLength)

Dieser Funktion wird das HAL CRC Handle übergaben, ein Pointer auf den Beginn des Speicherbereichs und einer Länge des Bereiches.

Leider führten die default Einstellungen nicht zum gewünschten Ergebnis, wenn man die gleichen Daten mit einem Standard CRC-32 verglich. Beispielsweise, wenn man das Ergebnis mit diesem Online Tool verglich: https://emn178.github.io/online-tools/crc32_checksum.html

Nach einer längeren Suche im Internet wurde ich wie so oft auf stackoverflow.com fündig. In folgendem Beitrag wurde ein Lösungsweg vorgestellt: https://stackoverflow.com/questions/39646441/how-to-set-stm32-to-generate-standard-crc32

Richtige Einstellung Cube MX

Im Cude MX müssen die Einstellungen von "Input Data Inversion Mode" auf "Byte" und "Output Data Inversion Mode" auf "Enable" gesetzt werden.

Danach schaut der erzeugte Init Code folgendermaßen aus:

/**
  * @brief CRC Initialization Function
  * @param None
  * @retval None
  */
static void MX_CRC_Init(void)
{

  /* USER CODE BEGIN CRC_Init 0 */

  /* USER CODE END CRC_Init 0 */

  /* USER CODE BEGIN CRC_Init 1 */

  /* USER CODE END CRC_Init 1 */
  hcrc.Instance = CRC;
  hcrc.Init.DefaultPolynomialUse = DEFAULT_POLYNOMIAL_ENABLE;
  hcrc.Init.DefaultInitValueUse = DEFAULT_INIT_VALUE_ENABLE;
  hcrc.Init.InputDataInversionMode = CRC_INPUTDATA_INVERSION_BYTE;
  hcrc.Init.OutputDataInversionMode = CRC_OUTPUTDATA_INVERSION_ENABLE;
  hcrc.InputDataFormat = CRC_INPUTDATA_FORMAT_BYTES;
  if (HAL_CRC_Init(&hcrc) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN CRC_Init 2 */

  /* USER CODE END CRC_Init 2 */
}

Soweit so gut, ein kleiner Hack wird trotzdem noch benötigt.

Das Ergebnis muss noch einmal verXORt werden. Ich habe mir dazu einfach eine Funktion geschrieben, die über den gewünschten Bereich rechnet:

extern CRC_HandleTypeDef hcrc;

#define ROM_START    (( uint32_t*) 0x08000000)
#define ROM_SIZE      ( uint32_t)  0x20000

uint32_t GetCRC(void) {
   return ~HAL_CRC_Calculate(&hcrc, ROM_START, ROM_SIZE);
}

Mit dem XOR Operanden ~ erhält man schließlich das richtige Ergebnis.

Da beim Kompilieren des Binaries keine fixe Größe erzeugt wird, habe ich im Makefile eine Zeile Code eingefügt, die mein Binary fix auf 128kB vergrößert und den Rest mit 0en befüllt. Das geht unter Linux mit dem Befehl "truncate" sehr einfach.

$(BUILD_DIR)/%.bin: $(BUILD_DIR)/%.elf | $(BUILD_DIR)
    $(BIN) $< $@
    truncate $@ --size 131072

Man muss bei dieser Methode jedenfalls gut aufpassen, dass der erzeugte Programmcode nicht größer wird, als die eingestellte Größe!
Ansonsten wird das Programm unabsichtlich abgeschnitten. Ich habe einfach mal das doppelte an Platz reserviert.

Nun ergeben die CRC-32 über das gebaute Binary file und die Berechnung innerhalb des Mikrocontrollers die gleiche CRC-32.

Ein sehr interessantes und zugleich praktisches Projekt hat Henning Bekel umgesetzt. Xlink erlaubt einem Benutzer, Daten von einem Host-System auf einen C64 oder einen C128 zu senden bzw. Daten von dort auszulesen. Gleichzeitig lässt sich das Remote-System auch fernsteuern.

Unterstützt wird folgende Hardware:

1. ein eigens dafür entwickelter USB Adapter 
2. ein einfaches paralleles Kabel

Um den Datentransfer zu ermöglichen muss auf dem Remote-System entweder ein gepatchter Kernal laufen oder temporär ein Server gestartet werden.

Auf der Host-System Seite kann man Befehle entweder über die command-line eingeben oder man erstellt seine eigenen Anwendungen via xlink Bibliothek.

Die Projektseite ist sehr, sehr gut dokumentiert und man findet auch viele Anregungen, wie man xlink praktisch einsetzen kann. Henning hat seinen Quellcode auf Github https://github.com/hbekel/xlink zur Verfügung gestellt.

Eigentlich ist es schon eine Unart, was man für ein gutes Aquarium bezahlen muss. Und sobald man sich dann eines zugelegt hat, geht der Spaß erst so richtig los. Da gibt es spezielle Filter, Reflektoren für die Beleuchtung und diverse Sensoren, die den Zustand des Wassers des Aquariums erfassen. Möchte man sich eine professionelle Überwachung für sein Becken zulegen, so ist man schnell einige hundert Euros los. Daher habe ich mich entschlossen, selber einen Aquarium Computer zu basteln. Dieser soll all meine Zwecke erfüllen und nicht zuviel kosten.

Über den Verlauf werdet ihr natürlich informiert werden. Den Quellcode werde ich auf GitHub veröffentlichen.