STM32 Nucleo Board LED schaltet nicht ein

[Peter H. (peter_hilleb)]

Hallo, brauche mal wieder eure Hilfe.

Ich habe mir ein ST Nucleo F103RB Board gekauft und habe damit 
(erfolglos) experimentiert.

Ich verwende folgenden Code (aus einem Tutorial von Youtube von 
UltraFx):

#include "stm32f10x.h"

int main(void)
{
  RCC->APB2ENR |= 0x04;

  GPIOA->CRL = 0x200000;

  uint32_t check = 0;

  while(1)
  {
    GPIOA->BSRR = 0x20;

    for(check = 0; check < 20000000; check++) {
      ;
    }

    //GPIOA->BRR = 0x20;

    //for(check = 0; check < 20000000; check++);
  }
}

Nun blinkt die LED nicht (auch wenn ich den auskommentierten Teil wieder 
einkommentiere), und so geht sie auch nicht an, wenn man ganz genau 
hinsieht, dann leuchtet sie mit vielleicht 1% Helligkeit.

Mit LED meine ich immer die onboard grüne "User- LED".

Was mache ich denn falsch?

Danke für jede Hilfe.

[Ingo L. (corrtexx)]

Peter H. schrieb:
> Was mache ich denn falsch?
Das du "magic numbers" nutzt. Nutze die defines, statt irgendwelcher 
Zahlen, die können schneller falsch sein als man denkt.

[Peter H. (peter_hilleb)]

Ja hast du vollkommen recht, würde man natürlich machen.

Nun ist es aber so, dass ich den Code kopiert habe, und derjenige der 
das Tutorial gemacht hat das selbe Board wie ich benützt.

Da die LED bei ihm blinkt gehe ich davon aus, dass die Zahlen stimmen, 
ich habe eigentlich die for Schleife im Verdacht...

[Ingo L. (corrtexx)]

Peter H. schrieb:
> Da die LED bei ihm blinkt gehe ich davon aus, dass die Zahlen stimmen,
> ich habe eigentlich die for Schleife im Verdacht...
Warum? Zumindest sollte die LED an sein, wenn du das Blinken 
auskommentiert hast.

[pegel (Gast)]

Jetzt muss ich doch mal fragen.
Immer wieder tauchen schon beim Blinky diese "geht nicht" Fragen auf.
Was habt ihr eigentlich mit den Dingern vor? Wie soll es weiter gehen?
Die andere Hardware im µC ist ein wenig umfangreicher als ein 
Pin-Wackler.
Wollt ihr wirklich jedes Bit zusammen fragen?

Ich denke, wer etwas ernsthaftes mit den µC anstellen will, sollte die 
angebotene Hilfestellung in Form von HAL in Anspruch nehmen.

Wer wirklich jedes Bit verstehen will, kann auch später von dort aus 
seine Forschungen starten.

[Markus F. (mfro)]

Peter H. schrieb:
> for(check = 0; check < 20000000; check++) {
>       ;
>     }

Willkommen in der Welt der C-Optimierung.

Nachdem check nicht volatile ist, wird ein schlauer Compiler 
feststellen, dass die Schleife zu nichts gut ist und sie einfach 
wegoptimieren.

Im Resultat glimmt deine LED, weil sie mit "Vollgas" getoggelt wird.

[Mike R. (thesealion)]

In dem obigen Beispiel wird die LED nicht einmal getoggelt, egal ob die 
Schleife noch im Aufgabe-File ist oder nicht.

Hier wird der Ausgang einfach nur auf High gesetzt.

[Peter H. (peter_hilleb)]

#include "stm32f10x.h"

int main(void)
{
  RCC->APB2ENR |= 0x04;

  GPIOA->CRL = 0x200000;

  uint32_t check = 0;

  GPIOA->BSRR = 0x20;

  while(1)
  {
    
  }
}

Ich habe den Code wie oben abgeändert.

Nun hätte ich mir erwartet, dass die LED an bleibt.

Wenn ich mit dem Debugger schrittweise gehe, dann geht die LED an, lasse 
ich das Programm laufen glimmt sie.

Also muss ich da irgendwo einen gewaltigen Denkfehler haben...

[Peter H. (peter_hilleb)]

#include "stm32f10x.h"

int main(void)
{
  RCC->APB2ENR |= 0x04;

  GPIOA->CRL = 0x200000;

  uint32_t check = 0;

  while(1)
  {
    GPIOA->BSRR = 0x20;
  }
}

Kann mich vielleicht doch jemand aufklären was ich hier falsch mache?

Steppe ich mit dem Debugger über die Zeile
GPIOA->BSRR = 0x20;
geht die LED an,

lasse ich das Programm laufen glimmt sie....

[Nico W. (nico_w)]

Ist denn dein Takt schon richtig konfiguriert wenn der da so schnell auf 
die Pins losgeht? Ich würde da einfach Mal zwischen jeden Schritt ein 
paar Pausen einbauen und gucken ob es dann geht.


Oder vielleicht Steps du Mal nicht komplett durch und machst einen 
breakpoint erst in der Schleife und guckst dir dann Mal die Register an.

[Bernd K. (prof7bit)]

Peter H. schrieb:
> Nun ist es aber so, dass ich den Code kopiert habe, und derjenige der
> das Tutorial gemacht hat das selbe Board wie ich benützt.
>
> Da die LED bei ihm blinkt gehe ich davon aus, dass die Zahlen stimmen,

Dann ist das Turial scheiße. So eine chaotische Schlamperei gewöhnt man 
Neulingen gar nicht erst an.

[Bernd K. (prof7bit)]

Peter H. schrieb:
> lasse ich das Programm laufen glimmt sie....

Und wo befindet es sich wenn Du wieder auf Pause klickst?

[Daniel V. (voda)]

Warum verwendest Du nicht die SPL von ST?
Auch UltraFX verwendet die SPL und schwenkt später die HAL um.

Gruß
Daniel

[Stefan F. (Gast)]

> Warum verwendest Du nicht die SPL von ST?

Vielleicht, weil STM selbst darauf hinweist, dass man sie nicht mehr 
verwenden soll? Die ist seit ein paar Jahren deprecated!

Aber die richtige Antwort hatte er ja schon geschrieben:

> Ich verwende folgenden Code (aus einem Tutorial von
> Youtube von UltraFx)

> Nun ist es aber so, dass ich den Code kopiert habe

> Dann ist das Turial scheiße.
Ja.

[Peter H. (peter_hilleb)]

#include "stm32f10x.h"

int main(void)
{
  RCC->APB2ENR |= 0x04;

  GPIOA->CRL = 0x200000;

  uint32_t check = 0;

  GPIOA->BSRR = 0x20;

  while(1)
  {

    check++;
    if(check > 10) {
      check = 0;
    }
  }
}

Habe den Code nochmal geändert, damit die while Schleife was zu tun hat.
Steppe ich durch (also auch x mal über das inkrementieren von check) 
bleibt die LED an.

Lasse ich das Programm laufen glimmt sie.

Wenn ich wieder auf Pause gehe, ist das Programm immer irgendwo in der 
nähe des Inkrementierers.

Ich bin ratlos ;-)

[Bernd K. (prof7bit)]

Peter H. schrieb:
> Lasse ich das Programm laufen glimmt sie.
>
> Wenn ich wieder auf Pause gehe, ist das Programm immer irgendwo in der
> nähe des Inkrementierers.

Und dann leuchtet sie wieder?

Setz mal nen Breakpoint an den Anfang der main(), evtl. wird er durch 
irgendwas resettet, dann müsste er wieder oben in der main vorbeikommen? 
Watchdog vielleicht?

Falsche (zu hohe) Takteinstellungen können ebenfalls zu crash und/oder 
Reset oder sonstigem aberwitzigen Verhalten führen, hatte ich selbst 
auch mal (F401RE), da wollte er dann bei nem Sprung am Ende der Loop 
stattdessen an eine vollkommen absurde nicht-existierende Adresse 
springen, hat ne Weile gedauert bis ich ihn im Debugger genau an der 
Stelle erwischt habe wo das machen wollte.