PlatformIO - STM32F103RB HelloWorld geht nicht

[Holger K. (holgerkraehe)]

Hallo zusammen

Habe heute mein Board mit einem STM32F103RBT6 ausgegraben.
Fix den ST-Link angeschlossen und mal geschaut, wie weit die 
Kompatiblität mit Arduino bei STM32 inzwischen ist.

Habe kurzerhand die ArduinoIDE verwendet und dort Stm32duino als board 
hinzugefügt und getestet. Funktionierte auf anhieb...

Doch ich würde auch gerne Debuggen können. Also hab ich mit das 
PlatformIO paket angeschaut und installiert. Leider funktioniert das 
einfachste LED-Blink Beispiel nicht.

Der Code funktioniert so 1:1 wenn er mit der ArduinoIDE compiliert wird.
Nicht jedoch mit PlatformIO.

Ein Debuggen hilft leider nicht, da ein Breakpoint bei "setup()" nie 
aufgerufen wird.

Der Prozessor scheint irgendwo zu hängen...

Hat jemand eine Idee?

Danke

[Jörg W. (dl8dtl) (Moderator)]

Holger K. schrieb:
> Ein Debuggen hilft leider nicht, da ein Breakpoint bei "setup()" nie
> aufgerufen wird.

Dann musst du den Debugger daran hindern, überhaupt bis dahin zu rennen. 
Habe PlatformIO jetzt schon lange nicht mehr in den Fingern gehabt (und 
auch nur je als Buildsystem genutzt, nicht als IDE/Debugger), aber da 
wird's schon irgendwo ein Häkchen geben.

Und dann halt schubweise durch die Initialisierung hüpfen, bis du 
eingekreist hast, an welcher Stelle er crasht.

[Johannes S. (Gast)]

oder ist da was mit dem Bootloader anders?

[Holger K. (holgerkraehe)]

Jörg W. schrieb:
> Holger K. schrieb:
>> Ein Debuggen hilft leider nicht, da ein Breakpoint bei "setup()" nie
>> aufgerufen wird.
>
> Dann musst du den Debugger daran hindern, überhaupt bis dahin zu rennen.
> Habe PlatformIO jetzt schon lange nicht mehr in den Fingern gehabt (und
> auch nur je als Buildsystem genutzt, nicht als IDE/Debugger), aber da
> wird's schon irgendwo ein Häkchen geben.
>
> Und dann halt schubweise durch die Initialisierung hüpfen, bis du
> eingekreist hast, an welcher Stelle er crasht.

Danke für deinen Input.
Das ist eine gute Idee

Habe das hier gefunden:

https://docs.platformio.org/en/latest/projectconf/section_env_debug.html#debug-init-cmds

Habe entsprechend diese Zeilen hinzugefügt:

debug_init_cmds =
  target extended-remote $DEBUG_PORT
  $INIT_BREAK
  monitor reset halt
  $LOAD_CMDS
  monitor init
  monitor reset halt

Das Ergebnis ist das selbe wie ohne den obigen Code.
Siehe dazu Bild 4. Es wird anscheinend ein temporärer Breakpoint 
gesetzt, aber ich kann den Prozessor nicht anhalten (siehe Steuerbuttons 
oben, da wäre theoretisch der halt button, der macht aber nichts).

Johannes S. schrieb:
> oder ist da was mit dem Bootloader anders?

Glaube ich eher nicht, da ich hier direkt über den ST-Link zugreife. 
Ebenso bei der ArduinoIDE. Auch dort habe ich das Programm direkt 
heruntergeladen.

[Holger K. (holgerkraehe)]

Ich habe inzwischen eine Vermutung...

Nach langem zögern, habe ich mir nun noch die Stm32CubeIDE 
heruntergeladen.

Dort habe ich ein einfaches Programm erstellt, welches nur USART1 und 2 
sowie den Tim1 als Systick verwendet.

Bereits beim Initialisieren des HAL (HAL_Init(); ) bekomme ich jedoch 
einen BusFault error.

Auch beim Durchsteppen geschieht das selbige.
Es scheint so, als gäbe es ein Problem mit dem Interrupt.

Ein ändern der SysTickSource von Tim1 zu SysTick hilft nicht.
Nur das auskommentieren von HAL_Init() und SystemClock_Config(); hilft, 
dass der Controller nicht in einen HardFault geht.

Wäre es möglich, dass der F103 aus dem Jahre 2008 evtl. ein HW-Problem 
hat?
Dies würde dann das fehlerhafte Debuggen erklären.

[c-hater (Gast)]

Holger K. schrieb:

> Ich habe inzwischen eine Vermutung...
>
> Nach langem zögern, habe ich mir nun noch die Stm32CubeIDE
> heruntergeladen.

Also ich hätte statt dessen lieber mal das Datenblatt des Device und der 
Familie runtergeladen. Und gelesen... Und verstanden...

Nach all meiner Erfahrung ist sowas letzlich sehr viel hilfreicher bei 
der Aufklärung misteriöser Crashes...

Allerdings mache ich das normalerweise sowieso eher umgekehrt: Erst wird 
die Doku gelesen, dann wird programmiert. Aber was weiss ich schon...

[Holger K. (holgerkraehe)]

Danke für deine Antwort.
Bin grundsätzlich auch deiner Meinung.

Ich arbeite seit mehr als 10 Jahren mit den STM32F1xx. Jedoch nicht auf 
täglicher Basis... So habe ich nun seit ca. 1.5 Jahren nichts mehr damit 
gemacht und nun wieder ein neues Projekt :)

Daher irritiert mich dieser BusFault nun doch etwas.

[Johannes S. (Gast)]

Holger K. schrieb:
> Hallo zusammen
> Habe heute mein Board mit einem STM32F103RBT6 ausgegraben.

Ein Nucleo oder ein custom Board? Takt richtig konfiguriert? Und im 
CubeMX den SWD aktiviert? Der ist da als default aus.

[Holger K. (holgerkraehe)]

Johannes S. schrieb:
> Ein Nucleo oder ein custom Board? Takt richtig konfiguriert? Und im
> CubeMX den SWD aktiviert? Der ist da als default aus.

Ja, hab ich.
Ist kein custom board.

Ist das hier:

https://www.futurlec.com/STM32_Development_Board.shtml

Habe nun ein altes Board mit STM32F103VET6 angeschlossen.
Siehe da, dieses lässt sich sofort debuggen...

Echt mühsam, wenn man mal wieder 8h in einen defekten Chip investiert 
hat.

[Johannes S. (Gast)]

Ich würde trotzdem nach dem clock sehen. Das Nucleo hat einen ext Clock, 
die Konfiguration würde mit einem Quarz nicht laufen. Das Evalboard mit 
den vielen Jumpern ist vielleicht auch anders konfiguriert?

[c-hater (Gast)]

Holger K. schrieb:

> Echt mühsam, wenn man mal wieder 8h in einen defekten Chip investiert
> hat.

Na, wenn es ein Nucleo-Board war und der Chip defekt ist, dann sollte 
man wohl rausfinden, wie das wohl passiert sein mag. Typisch werden 
diese Nucleo-Boards (man glaubt es kaum) doch tatsächlich mit 
funktionierenden Chips ausgeliefert. So jedenfalls meine Erfahrung, 
hatte noch nie ein defektes ab Anlieferung. Später allerdings 
gelegentlich schon...

Aber was weiss ich schon...

[Holger K. (holgerkraehe)]

Johannes S. schrieb:
> Ich würde trotzdem nach dem clock sehen. Das Nucleo hat einen ext
> Clock,
> die Konfiguration würde mit einem Quarz nicht laufen. Das Evalboard mit
> den vielen Jumpern ist vielleicht auch anders konfiguriert?

Nun, das Problem besteht nur, wenn der SysTick konfiguriert wird.
Werden keine Clock-Einstellungen vorgenommen, läuft das Debugging und 
die blinkende LED.

c-hater schrieb:
> Na, wenn es ein Nucleo-Board war und der Chip defekt ist, dann sollte
> man wohl rausfinden, wie das wohl passiert sein mag. Typisch werden
> diese Nucleo-Boards (man glaubt es kaum) doch tatsächlich mit
> funktionierenden Chips ausgeliefert.

Das Board ist mehr als 10 Jahre alt und hatte bereits schon so manches 
Projekt durchlebt...

[Johannes S. (Gast)]

Vor 10 Jahren gab es die noch nicht als Fakes, umso besser…

[c-hater (Gast)]

Holger K. schrieb:

> Das Board ist mehr als 10 Jahre alt und hatte bereits schon so manches
> Projekt durchlebt...

Das letzte wohl nicht...

[Holger K. (holgerkraehe)]

c-hater schrieb:
> Holger K. schrieb:
>
>> Das Board ist mehr als 10 Jahre alt und hatte bereits schon so manches
>> Projekt durchlebt...
>
> Das letzte wohl nicht...

sieht so aus xD

[Johannes S. (Gast)]

Weil es ja mit stm32duino lief:
Hast du das im CubeMX mit HSE und Quarz konfiguriert?

[Holger K. (holgerkraehe)]

Johannes S. schrieb:
> Hast du das im CubeMX mit HSE und Quarz konfiguriert?

Nein, bei der Konfiguration der Clocks, gibts einen HardFault.

void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

  /** Initializes the RCC Oscillators according to the specified parameters
  * in the RCC_OscInitTypeDef structure.
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  /** Initializes the CPU, AHB and APB buses clocks
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

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

Wird obiger Code ausgeführt, gibts nach einigen hundert Takten einen 
HardFault

[Stefan F. (Gast)]

Als ich CubeMX vor wenigen Jahren zum ersten mal verwendete versagte 
auch die Takt Konfiguration. Hier im Forum wurde mir geholfen, den 
konkreten Fehler in der HAL zu finden. In der nächsten Version war der 
Fehler behoben, dafür ging zwei mal was anderes nicht.

Ich habe das Gefühl, dass sie den F103 nur schlampig behandeln.

Keine Ahnung ob du in diesem Fall auf einen Bug in der HAL gestoßen 
bist. Aber erwäge, dass es so sein könnte.

[Jörg W. (dl8dtl) (Moderator)]

Holger K. schrieb:
> Wird obiger Code ausgeführt, gibts nach einigen hundert Takten einen
> HardFault

Das klingt nach einem Problem mit Flash wait states oder sowas.

Ich habe neulich ein (bare metal) STM32F103-Projekt damit hier gemacht:

void init_clock(void)
{
    // Conf clock : 64MHz using HSE 16MHz crystal w/ PLL X 4 (16MHz x 4 = 64MHz)
    FLASH->ACR      |= FLASH_ACR_LATENCY_2; // Two wait states, per datasheet
    RCC->CFGR       |= RCC_CFGR_PPRE1_2;    // prescale AHB1 = HCLK/2
    RCC->CR         |= RCC_CR_HSEON;        // enable HSE clock
    while( !(RCC->CR & RCC_CR_HSERDY) );    // wait for the HSEREADY flag

    RCC->CFGR       |= RCC_CFGR_PLLSRC;     // set PLL source to HSE
    RCC->CFGR       |= RCC_CFGR_PLLMULL4;   // multiply by 4
    RCC->CR         |= RCC_CR_PLLON;        // enable the PLL
    while( !(RCC->CR & RCC_CR_PLLRDY) );    // wait for the PLLRDY flag

    RCC->CFGR       |= RCC_CFGR_SW_PLL;     // set clock source to pll

    while( !(RCC->CFGR & RCC_CFGR_SWS_PLL) );    // wait for PLL to be CLK

    SystemCoreClockUpdate();                // calculate the SYSCLOCK value
}

Ich denke, die erste Zeile ist der Schlüssel hier.

[Johannes S. (Gast)]

> Wird obiger Code ausgeführt, gibts nach einigen hundert Takten einen
> HardFault

Aber nicht wegen der Flash Latency, da läuft der ja noch mit HSI, also 
internem RC Oszi.
Danach wird es spannend, wenn auf HSE mit PLL umgeschaltet wird.
An der gezeigten Stelle liegt es mit Sicherheit nicht.

[Stefan F. (Gast)]

Jörg W. schrieb:
> Das klingt nach einem Problem mit Flash wait states oder sowas.

Daran scheiterte es auch bei mir damals.

[temp (Gast)]

Wenn man einen Fehler in der Clock-Configuration oder den Flash 
Waitstates vermutet, ist wohl der einfachste Weg den Teil ganz aus dem 
Programm zu nehmen. Mit 8MHz lässt sich das Teil auch debuggen. Erst 
wenn da schon mal eine LED geblinkt hat kann man Stück für Stück weiter 
machen. Kann doch nicht so schwer sein.

[Holger K. (holgerkraehe)]

Danke für eure Antworten.
So weit komme ich garnicht.

Habe euch mal ein Video angehängt.
Da seht ihr, was da genau geht und was nicht.

[Johannes S. (Gast)]

sparsamer wäre die .ioc Datei vom CubeMX.

[Holger K. (holgerkraehe)]

Hier noch die ioc

[W.S. (Gast)]

Holger K. schrieb:
> Leider funktioniert das
> einfachste LED-Blink Beispiel nicht.

Und deine Erklärung dazu heißt: Der Chip ist defekt. Nun das mag sein, 
aber ich denke da eher, daß es alles auf einer Programm-Hakelei aud dem 
PC zusammen mit all dem basiert, was bereits der C-Hater angerissen hat.

Ich hätte da 2 Ratschläge für dich:
1. Versuche einmal, deine Firmware nur mit der eigentlichen Toolchain 
(bei dir vermutlich GCC) zu erstellen, ohne irgendwelche Cube's, IDE's 
und Fremd-Libs.
2. Suche hier einmal in der Historie dieses Forums nach einem 
Minimal-Projekt, was ich mal für die STM32F103C8T6 gepostet habe. Dort 
ist auch das fertig erzeugte Hexfile mit drin (per Keil erzeugt) und das 
funktioniert garantiert. Damit könntest du testen, ob dein µC 
tatsächlich kaputt ist oder ob es (wie ich eher vermute) seine Ursache 
in den diversen Programmen etc. auf deinem PC hat.

W.S.

[hard worker (Gast)]

Ich spendiere mal meine (eine) funktionsfähige IOC Datei.
Muss noch auf die verwendete IDE eingestellt werden, Pfad
des Firmware Package auch ...

Auffällig ist bei der IOC vom TO dass in der Clock-Konfiguration
HSI gewählt ist, im RCC Bereich jedoch "Crystal/Ceramic Resonator"

Kann momentan nicht beurteilen ob das relevant ist ...

[Johannes S. (Gast)]

Holger K. schrieb:
> Hier noch die ioc

sieht ok aus. Kann ich erst später testen, müsste ja auch auf einem 
Bluepill laufen.
Clock ist nur HSI, was an HSE hängt ist ja nicht aktiv.

[Johannes S. (Gast)]

Holger K. schrieb:
> Hier noch die ioc

habe es jetzt auf einem BluePill geladen, und es crasht auch mit 
gleichem Fehlerbild, nach einer Zeit kommt eine Interrupt Fehlermeldung. 
Ohne HAL_Init(), also ohne TIM1 init, läuft es.

Dann habe ich ein neues Projekt gemacht, aber mit F103C8 statt F103RB 
gemacht weil das BluePill ja den 48 Pinner drauf hat. Und damit läuft 
das Programm, auch die TIM1 ISR wird aufgerufen.
Also immer noch merkwürdig, der C8 hat ja trotzdem 128k Flash und das 
Programm steht ja am Anfang des Flash, also kein signifikanter 
Unterschied.

edit:
ok, jetzt kam der Fehler auch in dem neu erstellten Projekt. Es dauert 
eine Zeit und die kam erst nach ein paar mal Pause/Go/Step. Aber die 
Meldung 'Interrupt failed.' ist etwas in der Debugger Kommunikation, 
also eher irgendwas im Zusammenspiel mit dem GDB. Auch in dem mbus 
Projekt wird die ISR aufegrufen und zahlt den HAL tick hoch.

[Holger K. (holgerkraehe)]

Wow. VIelen Dank für deine Bemühungen.
Bin immer wieder beeindruckt über die Community hier!

Ok, also scheint da ein spezifisches Problem mit dem Zusammenspiel des 
F103RB und dem ST-Link zu sein?

Ich hätte auch noch einen J-Link. Evtl. funktionierts da besser.
Aber finde ich schon etwas merkwürdig das ganze... Voralle, dass ich 
nach 1.5 Jahren gerade in so einen "Bug" reinlaufen...

Mit dem Bluepill läuft die Applikation inzwischen seit ca. 3h ohne 
Probleme.

Für die, die es interessiert was es wird:

Es handelt sich um ein Programm, welches automatisch den MBUS (nicht 
Modbus!) scannt und das erste gefundene Gerät ausliest und die Daten 
auch gleich parst...

Scanning address: 1<\r><\n>
received: E5<\r><\n>
mbus: start long frame<\r><\n>
00: 68 1b 1b 68 08 01 72 33 01 00 14 e6 1e 3c 07 f7 <\r><\n>
10: 00 00 00 0c 78 33 01 00 14 0c 13 28 07 00 00 1b <\r><\n>
20: 16 <\r><\n>
Stage 1...<\r><\n>
Stage 2...<\r><\n>
ID: lX<\n>
MFG: GWF<\n>
Medium: Water<\n>
AccessNr: 247<\n>
Status: 00<\n>
Signature: 2000064A0B<\n>
[<\n>
  {<\n>
    id: 0,<\n>
    function: Instantaneous value,<\n>
    sotrage nr: 0,<\n>
    unit: Fabrication number,<\n>
    value: 14000133,<\n>
  },<\n>
  {<\n>
    id: 1,<\n>
    function: Instantaneous value,<\n>
    sotrage nr: 0,<\n>
    unit: Volume (m m^3),<\n>
    value: 728,<\n>
  },<\n>
]

[Johannes S. (Gast)]

Ich habe ein BMP als Debugadapter dran, vielleicht macht der das. Einen 
Hardfault bekomme ich jedenfalls nicht und auch die LED an PC13 blinkt 
fröhlich wenn ich das in dein Projekt einbaue.
Kompliziert war nur das Update der Firmware Packages, das 1.8.4 ging bei 
mir nur manuell. CubeMX ist auch nicht meine Lieblingsumgebung, nutze 
ich nur gelegentlich als Codegenerator. Aber im Gegensatz zu anderen 
hier halte ich das mittlerweile für sehr zuverlässig, das wird auch 
kommerziell bei meinen Kollegen und Fremdfirmen eingesetzt.

edit:
Damit ist die Chance groß das der F103RB doch einen Schuss hat.
Und für das Debuggen reicht auch das SWD, belegt weniger Pins. JTAG hat 
bei den Cortex-M keinen Vorteil.