Komisches Verhalten Delay

pete Gast 02.04.2013 17:36 #3112718

Lesenswert?

•

Hallo Leute ich habe hier ein Problem, welches mich fast verzweifeln 
lässt.

Wenn ich folgenes Blink Beispiel auf den Chip flashe, funktioniert alles 
super. Wenn ich lediglich den Wert in der ersten Delay in 450 oder 
größer ändere wird der Code danach nicht mehr ausgeführt. Wenn ich mit 
dem Debugger Schaue und beim Rücksetzen des Pins einen Breakepoint 
setze, wird dieser auch erreicht. Ein Breakepoint beim Setzen wird nicht 
erreicht. Der Chip hängt aber nirgendwo sondern erricht nur immer wieder 
den ersten Breakepiont... Wie gesagt mit Delay(400) läuft alles wie 
geplant...

#include "stm32f4xx.h"
#include "stm32f4xx_rcc.h"
#include "misc.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_spi.h"
#include "stm32f4xx_tim.h"
#include "ADXL345.h"
/*Prototypen*/
void Systick_Handler(void);
void Delay(uint32_t cycles);
/* globale Variablen*/
uint32_t Ticks=0;
int main(void)
    SystemInit();
    SysTick_Config(SystemCoreClock/ 1000);
    GPIO_InitTypeDef GPIO_InitStruct;
   RCC_AHB1PeriphClockCmd(ADXL345_GPIO_Clock, ENABLE);
   GPIO_InitStruct.GPIO_Pin = GPIO_Pin_9;
   GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT;
   GPIO_InitStruct.GPIO_OType = GPIO_OType_PP;
   GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;
   GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_UP;
   GPIO_Init(ADXL345_SPI_Port, &GPIO_InitStruct);
   GPIO_WriteBit(ADXL345_SPI_Port, AXDL345_CS_Pin,SET);
    while(1)
      GPIO_WriteBit(ADXL345_SPI_Port, GPIO_Pin_9, RESET);
        Delay(400);
        GPIO_WriteBit(ADXL345_SPI_Port, GPIO_Pin_9, SET);
        Delay(400);
void SysTick_Handler(void){
  if (Ticks != 0)
    Ticks--;
void Delay(uint32_t cycles ){
  Ticks = cycles;
  while (Ticks>0);

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

troll Gast 02.04.2013 17:56 #3112747

Lesenswert?

•

▲
▼

volatile?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Pete Gast 02.04.2013 18:00 #3112750

Lesenswert?

•

▲
▼

troll schrieb:
> volatile?

Auch schon probiert... Selbes phänomen

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Sascha W. (sascha-w) 02.04.2013 18:09 #3112769

Lesenswert?

•

▲
▼

Hallo,

also ich kenne zwar den STM32 nicht, aber ich denke mal das ein uint32 
nicht mit einem Befehl vom RAM in (ein oder mehrere Reg.?) tranferiert 
werden kann?
Wenn dem so ist, dann sind

  Ticks = cycles;
  while (Ticks>0);

nicht atomar, also könnte dir hier die ISR SysTick_Handler() 
dazwischenfunken und einen Teil des uint32 noch beim Beschreiben ändern.

Sascha

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Pete Gast 02.04.2013 22:57 #3113055

Lesenswert?

•

▲
▼

Das wars auch nicht... Jetzt wirds immer komischer: ich habe mal ein 
anderes Board probiert und es läuft!!! Woran kann das liegen es sind 2 
identische Stm32 Discovery Boards......

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michi Gast 02.04.2013 23:20 #3113070

Lesenswert?

•

▲
▼

@Pete
Versuch mal mikroC ARM. Für dein LED-Geblinke reicht das LED-Demo 
Sample.
http://www.mikroe.com/mikroc/arm/

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Pete Gast 02.04.2013 23:52 #3113093

Lesenswert?

•

▲
▼

Danke für den Tip... Aber klingt das gerade nicht eher nachveinem 
hardwareproblem?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michi Gast 03.04.2013 00:18 #3113109

Lesenswert?

•

▲
▼

Pete schrieb:
> es sind 2
> identische Stm32 Discovery Boards......
Wenn das stimmt, was du schreibst, eher nicht. Kannst du sicherstellen, 
dass es immer das selbe Hex-File ist, welches du in beide Boards flasht? 
Du könntest ja auch beide Boards auslesen und ein Compare über die 
Hexfiles machen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dr. Sommer Gast 03.04.2013 01:02 #3113124

Lesenswert?

•

▲
▼

Sascha Weber schrieb:
> also ich kenne zwar den STM32 nicht, aber ich denke mal das ein uint32
> nicht mit einem Befehl vom RAM in (ein oder mehrere Reg.?) tranferiert
> werden kann?
Falsch; beim ARMv7 sind uint32-Zugriffe per Spezifikation immer atomar 
(und werden dank 32bit-Bus auch in einem Zyklus durchgeführt). Siehe S. 
101,102 im ARMv7M-Architecture Reference Manual.
Warum das nicht funktioniert weiß ich aber auch nicht ("Ticks" sollte 
natürlich volatile sein)... Vielleicht mal überprüfen ob der Controller 
aus ominösen Gründen ständig resettet? (Breakpoint auf Reset_Handler)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Pete Gast 04.04.2013 15:35 #3115318

Lesenswert?

•

▲
▼

Genau das!!! Kann das vom watchdog kommen?? Ist der hardwaremäßig 
implementiert? Sprich muss ich den expliziet wieder rücksetzen wenn ich 
den in nem anderen projekt mal benutzt habe?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Karl H. (kbuchegg) 04.04.2013 16:50 #3115480

Lesenswert?

•

▲
▼

Pete schrieb:
> Genau das!!! Kann das vom watchdog kommen?? Ist der hardwaremäßig
> implementiert?

Dein Prozessor-Datenblatt sollte darüber Auskunft geben.

Aber im Normalfall ist der hardwaremässig implementiert. Muss auch so 
sein, denn der Watchdog muss auch dann noch funktionieren, wenn sich 
dein Programm bzw. der Prozessor haushoch verfranst hat und nur noch vor 
sich hindümpelt.
Dann kommt die möglichst unabhängige Hardware-Einheit "Watchdog" und 
resettet den Prozessor in einen gültigen Zustand.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael Gast 04.04.2013 19:50 #3115710

Lesenswert?

•

▲
▼

#include "stm32f4xx.h"
#include "stm32f4xx_rcc.h"
#include "misc.h"
#include "stm32f4xx_gpio.h"
#include "stm32f4xx_spi.h"
#include "stm32f4xx_tim.h"
#include "ADXL345.h"


Da wären doch einige gute Kandidaten dabei. Z.B die RTCC !

Antwort Zitieren Bearbeiten Löschen Beitrag melden

me Gast 04.04.2013 20:15 #3115746

Lesenswert?

•

▲
▼

pete schrieb:
> Der Chip hängt aber nirgendwo sondern erricht nur immer wieder
> den ersten Breakepiont..

Und was sagt der Debugger über den Weg dort hin?
Ein Break Point vor der while-Schleife könnte verraten, ob er dazu über 
"Los" geht.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Peter P. (peter---p) 04.04.2013 22:23 #3115917

Lesenswert?

•

▲
▼

Es war/ist der Watchdog. Wenn ich diesen so verstelle dass der Prescaler 
der Reload größer sind, denn blinkt es..  Anscheinend gibt es aber keine 
Möglichkeit den IWDG ganz abzustellen, wenn er einmal aktiv ist... Das 
Board ist also "hin"

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Michael Gast 04.04.2013 22:29 #3115923

Lesenswert?

•

▲
▼

Peter Pan schrieb:
> Anscheinend gibt es aber keine Möglichkeit den IWDG ganz abzustellen
Du könntest aber dein Gesamt-Delay in handliche Brocken aufteilen und 
zwischendurch das arme Tier ein bisschen streicheln.
Besser wäre natürlich, wenn du die unsäglichen Delays ganz rausschmeißt 
und durch eine vernünftige Timersteuerung ersetzt. Spätestens wenn 
wesentlich mehr als eine LED blinken soll, brauchst du das sowieso.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

pete Gast 04.04.2013 22:54 #3115952

Lesenswert?

•

▲
▼

Michael schrieb:
> Peter Pan schrieb:
>> Anscheinend gibt es aber keine Möglichkeit den IWDG ganz abzustellen
> Du könntest aber dein Gesamt-Delay in handliche Brocken aufteilen und
> zwischendurch das arme Tier ein bisschen streicheln.
> Besser wäre natürlich, wenn du die unsäglichen Delays ganz rausschmeißt
> und durch eine vernünftige Timersteuerung ersetzt. Spätestens wenn
> wesentlich mehr als eine LED blinken soll, brauchst du das sowieso.

Das weiß ich... Das Blinkn ist nur ein Testprogramm um den Bootloader zu 
testen, den ich gerade schreibe... Ich wollte halt ein Program, bei dem 
ich nach dem flashen gleich sehe obs geht....

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dr. Sommer Gast 07.04.2013 01:44 #3118665

Lesenswert?

•

▲
▼

Peter Pan schrieb:
> Anscheinend gibt es aber keine
> Möglichkeit den IWDG ganz abzustellen, wenn er einmal aktiv ist...
Wieso das? Die Option Bytes kann man beliebig umprogrammieren (Seite 71 
im RM), wenn du nicht gerade die Lockbits gesetzt hast.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Komisches Verhalten Delay

Antwort schreiben