STM32 Nucleo Board LED schaltet nicht ein

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.

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...

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.

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.

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.

1

#include "stm32f10x.h"

2

3

int main(void)

4

{

5

  RCC->APB2ENR |= 0x04;

6

7

  GPIOA->CRL = 0x200000;

8

9

  uint32_t check = 0;

10

11

  GPIOA->BSRR = 0x20;

12

13

  while(1)

14

  {

15

16

  }

17

}

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...

1

#include "stm32f10x.h"

2

3

int main(void)

4

{

5

  RCC->APB2ENR |= 0x04;

6

7

  GPIOA->CRL = 0x200000;

8

9

  uint32_t check = 0;

10

11

  while(1)

12

  {

13

    GPIOA->BSRR = 0x20;

14

  }

15

}

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....

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.

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.

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

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

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

Gruß
Daniel

1

#include "stm32f10x.h"

2

3

int main(void)

4

{

5

  RCC->APB2ENR |= 0x04;

6

7

  GPIOA->CRL = 0x200000;

8

9

  uint32_t check = 0;

10

11

  GPIOA->BSRR = 0x20;

12

13

  while(1)

14

  {

15

16

    check++;

17

    if(check > 10) {

18

      check = 0;

19

    }

20

  }

21

}

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 ;-)

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.