Komisches Verhalten Delay

[pete (Gast)]

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

[troll (Gast)]

volatile?

[Pete (Gast)]

troll schrieb:
> volatile?

Auch schon probiert... Selbes phänomen

[Sascha W. (sascha-w)]

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

[Pete (Gast)]

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

[Michi (Gast)]

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

[Pete (Gast)]

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

[Michi (Gast)]

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.

[Dr. Sommer (Gast)]

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)

[Pete (Gast)]

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?

[Karl H. (kbuchegg)]

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.

[Michael (Gast)]

#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 !

[me (Gast)]

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.

[Peter P. (peter---p)]

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"

[Michael (Gast)]

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.

[pete (Gast)]

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

[Dr. Sommer (Gast)]

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.