STM32F1 Cube HAL Systemtakt funktioniert nicht

[Stefan F. (Gast)]

Hallo,
ich glaube, CubeMX erzeugt fehlerhaften Code zur Konfiguration des 
Systemtaktes.

Eigentlich wollte ich die USB Library von Cube HAL auf einem 
STM32F103C8T6 Board aus China ausprobieren. Allerdings blinkt meine LED 
nicht und Windows kann die USB Device-ID nicht abfragen.

Um das Problem weiter einzugrenzen, habe ich den USB Kram mal raus 
gelassen. Die LED blinkt immer noch nicht. Folgendes habe ich gemacht:

1) Neues Projekt mit CubeMX erstellt.
Prozesor ausgewählt, Debugging via SWD eingestellt, HSE Oszillator 
aktiviert, PC13 als Ausgang für die LED eingestellt (Pinout.png).

2) Clock Configuration: 8Mhz HSE mit 6x PLL = 48Mhz 
(Clock-Configuration.png)

3) In die Hauptschleife habe ich folgendes eingefügt:

while (1)
{
     // LED On
    HAL_GPIO_WritePin(LED_GPIO_Port,LED_Pin,GPIO_PIN_SET);
    HAL_Delay(1000);

    // LED Off
    HAL_GPIO_WritePin(LED_GPIO_Port,LED_Pin,GPIO_PIN_RESET);
    HAL_Delay(1000);
}

Die LED bleibt jedoch dunkel.

Dann habe ich die Takt-Konfiguration geändert: HSI/2 mit 12x PLL = 48Mhz 
(Clock-Configuration-HSI-geht.png)

Jetzt blinkt die LED im 1 Sekunden Takt. Daher dachte ich zuerst, das 
Board (bzw. der Quarz) sei defekt. Aber mein Gegentest mit folgendem 
Programm (ohne HAL) läuft einwandfrei:

#include <stdint.h>
#include "stm32f1xx.h"

// This variable is used by some CMSIS functions
uint32_t SystemCoreClock=8000000;

// Milliseconds counter
volatile uint32_t systick_count=0;


void SysTick_Handler(void)
{
  systick_count++;
}


// Called by Assembler startup code
void SystemInit(void)
{
  // Enable HSE oscillator
  SET_BIT(RCC->CR, RCC_CR_HSEON);

  // Wait until HSE oscillator is ready
  while(!READ_BIT(RCC->CR, RCC_CR_HSERDY)) {}

  // 48Mhz using the 8Mhz HSE oscillator divided by 1 with 6x PLL, lowspeed I/O runs at 24Mhz
  WRITE_REG(RCC->CFGR, RCC_CFGR_PLLSRC + RCC_CFGR_PLLMULL6 + RCC_CFGR_PPRE1_DIV1);

  // Flash latency 1 wait state
  MODIFY_REG(FLASH->ACR, FLASH_ACR_LATENCY, FLASH_ACR_LATENCY_0);

  // Enable PLL
  SET_BIT(RCC->CR, RCC_CR_PLLON);

  // Wait until PLL is ready
  while(!READ_BIT(RCC->CR, RCC_CR_PLLRDY)) {}

  // Select PLL as clock source
  MODIFY_REG(RCC->CFGR, RCC_CFGR_SW, RCC_CFGR_SW_PLL);

  // Update variable
  SystemCoreClock=48000000;
}


int main(void)
{
  // Initialize system timer
  SysTick_Config(SystemCoreClock/1000);

  // Enable Port C
  SET_BIT(RCC->APB2ENR, RCC_APB2ENR_IOPCEN);

  // PC13 = Output
  MODIFY_REG(GPIOC->CRH, GPIO_CRH_CNF13 + GPIO_CRH_MODE13, GPIO_CRH_MODE13_0);

  while(1)
  {
    // LED On
    WRITE_REG(GPIOC->BSRR,GPIO_BSRR_BS13);

    // Delay 1 second
    uint32_t start=systick_count;
    while (systick_count-start<1000);

    // LED Off
    WRITE_REG(GPIOC->BSRR,GPIO_BSRR_BR13);

    // Delay 1 second
    start=systick_count;
    while (systick_count-start<1000);
  }
}

Es scheint also, als ob CubeMX einen fehlerhaften Initialisierungscode 
erzeugt. Allerdings ist es mir nicht gelungen, den Knackpunkt zu finden. 
Hierbei bitte ich nun um Hilfe. Kann jemand den folgenden von CubeMX 
erzeugten Code prüfen?

Dieser Code von CubeMX geht (HSI 8Mhz -> 48Mhz):

void SystemClock_Config(void)
{

  RCC_OscInitTypeDef RCC_OscInitStruct;
  RCC_ClkInitTypeDef RCC_ClkInitStruct;

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = 16;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI_DIV2;
  RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL12;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)
  {
    Error_Handler();
  }

    /**Configure the Systick interrupt time 
    */
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

    /**Configure the Systick 
    */
  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* SysTick_IRQn interrupt configuration */
  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
}

Dieser Code von CubeMX geht nicht (HSE 8Mhz -> 48Mhz):

void SystemClock_Config(void)
{

  RCC_OscInitTypeDef RCC_OscInitStruct;
  RCC_ClkInitTypeDef RCC_ClkInitStruct;

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL6;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)
  {
    Error_Handler();
  }

    /**Configure the Systick interrupt time 
    */
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

    /**Configure the Systick 
    */
  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* SysTick_IRQn interrupt configuration */
  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
}

[pegel (Gast)]

Das ist noch die 4.20.0 oder?
Da gab es einen Bug mit:

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;

Das RCC_OSCILLATORTYPE_HSI ist der Störenfried.

Deshalb gab es dann ein Update auf 4.20.1.

Hat sich aber auch schon wieder erledigt, jetzt ist 4.21.0 aktuell.

[Stefan F. (Gast)]

Wow, darauf wäre ich nie gekommen. Und ja du hast Recht, es ist die 
Version 4.20.0.

Da sehen wir wieder mal, wie super hilfreich diese Codegeneratoren sind 
:-(

Mein eigenen von hand zusammengeklöppelter Code geht, während ich durch 
den generierten Code nicht durchblicke. Scheiß Frameworks.

[STM Apprentice (Gast)]

Stefan U. schrieb:
> Mein eigenen von hand zusammengeklöppelter Code geht, während ich durch
> den generierten Code nicht durchblicke. Scheiß Frameworks.

Ich schwöre auf die "Mitte" zwische Bare Metal und "High Level":

SPL hat mich noch nie im Stich gelassen, es geht schnell genug
beim Schreiben und es wird wohl weiterhin für mich funktionieren.
Ich brauche ja nicht jede Woche eine neue Version der SPL so
wie man es gefühlt bei CubeMX bekommt.

[Stefan F. (Gast)]

Na toll, die Installation der Version 4.21 wird vom Windows Defender 
blockiert. Ich bekomme zunehmend der Eindruck, daß STM keine gute 
Software bereit stellt - alles nur eilig zusammengklöppelt.