WD-Reset und Reset Pin erzeugen nicht das selbe wie Power off

[langstrumpf (Gast)]

Guten Abend,
ich habe ein für mich unerklärbares Phänomen.
Ich habe einen AT90Can128 auf dem ich einen CanopenStack laufen habe.
Nun wenn ich ein Reset Node empfange und mittels Endlosschleife den WD 
zubeißen lassen will dann Startet der MC nicht mehr.Das selbe wenn ich 
den Reset Pin auf Gnd ziehe startet der Mc auch nicht mehr. Wenn ich die 
Versorgung Toggle dann funktioniert alles wieder bestens.
Ich habe aber absolut keinen Plan wie ich hinter den Fehler steigen 
kann.
Der Debugger funktioniert nicht in diesem Zustand.
Was habt ihr für Ideen?

Danke für die Hilfe

[c-hater (Gast)]

langstrumpf schrieb:

> Ich habe aber absolut keinen Plan wie ich hinter den Fehler steigen
> kann.

Dann mach' dir einen.

Der fängt damit an, dass du dir über die Unterschiede zwischen einem 
powercycle und einem reset klar wirst. Denn nach den Gesetzen der Logik 
muss irgendwie aus diesen Unterschieden letzlich das Problem 
resultieren...

[Einer K. (Gast)]

langstrumpf schrieb:
> Nun wenn ich ein Reset Node empfange und mittels Endlosschleife den WD
> zubeißen lassen will dann Startet der MC nicht mehr.Das selbe wenn ich
> den Reset Pin auf Gnd ziehe startet der Mc auch nicht mehr. Wenn ich die
> Versorgung Toggle dann funktioniert alles wieder bestens.

Mein Glaskugel sagt:
Du hast vergessen, als allererstes in deinem Programm den WDT 
abzuschalten.
Denn der wird NICHT automatisch beim normalen Reset abgeschaltet.

[langstrumpf (Gast)]

c-hater schrieb:
> Der fängt damit an, dass du dir über die Unterschiede zwischen einem
> powercycle und einem reset klar wirst. Denn nach den Gesetzen der Logik
> muss irgendwie aus diesen Unterschieden letzlich das Problem
> resultieren...

Danke für die Hilfe.
Ich war bis Heute der Meinung das Reset und powercycle das selbe 
bewirkt.
Wo können die Unterschiede sein?
Wie kann ich sowas debuggen?

Lg

[Stefan F. (Gast)]

langstrumpf schrieb:
> Wo können die Unterschiede sein?

Hat Arduino Fanboy geschrieben.

Wenn da noch andere aktive Komponenten in deiner Schaltung sind, kann es 
auch an denen liegen. Oder auch am Programm, dass bei Start vielleicht 
auf eine bestimmte Signalkombination wartet.

> Wie kann ich sowas debuggen?

Hängt vom Code und der Schaltung ab.

[langstrumpf (Gast)]

Arduino Fanboy D. schrieb:
> Mein Glaskugel sagt:
> Du hast vergessen, als allererstes in deinem Programm den WDT
> abzuschalten.
> Denn der wird NICHT automatisch beim normalen Reset abgeschaltet.

Guten Abend.
Wie meinst du das? Bleibt der WD aktiv nach zubeißen?
Muss ich also den WD al erstes ausschalten vor der Initialisierung der 
Hardware?
Danke für die Hilfe

[Einer K. (Gast)]

langstrumpf schrieb:
> Wie meinst du das? Bleibt der WD aktiv nach zubeißen?
> Muss ich also den WD al erstes ausschalten vor der Initialisierung der
> Hardware?

Natürlich!
Der Vorteiler des WDT wird gelöscht, auf kleinsten Wert.
Und du kommst mit aktiven WDT aus dem Reset.

Und ja, der bleibt aktiv.

Ja, das tut er.

[Stefan F. (Gast)]

langstrumpf schrieb:
> Bleibt der WD aktiv nach zubeißen?

Ja, das steht so im Datenblatt.

> Muss ich also den WD al erstes ausschalten vor der
>  Initialisierung der Hardware?

Ja und auch das steht im Datenblatt.

Warum benutzt due Funktionseinheiten, bevor du ihre Dokumentation 
gelesen hast?

> Wie kann ich sowas debuggen?

Hast du überhaupt einen Debugger? Kannst du damit umgehen? Wenn nicht, 
besorge einen und über an einem funktionierenden Objekt.

[c-hater (Gast)]

langstrumpf schrieb:

> Ich war bis Heute der Meinung das Reset und powercycle das selbe
> bewirkt.

Nö. Wie du ganz praktisch ja sehen kannst...

> Wie kann ich sowas debuggen?

Durch DB-Lesen und Denken.

Aber der Fanboy hat dir immerhin schon einen möglichen Tip gegeben. Es 
gibt aber noch mehr Unterschiede zwischen den beiden Situationen.

[langstrumpf (Gast)]

Arduino Fanboy D. schrieb:
> langstrumpf schrieb:
>> Wie meinst du das? Bleibt der WD aktiv nach zubeißen?
>> Muss ich also den WD al erstes ausschalten vor der Initialisierung der
>> Hardware?
>
> Natürlich!
> Der Vorteiler des WDT wird gelöscht, auf kleinsten Wert.
> Und du kommst mit aktiven WDT aus dem Reset.
>
> Und ja, der bleibt aktiv.
>
> Ja, das tut er.

Danke für die Hilfe!
Habe das Datenblatt was den WD angeht nicht gelesen.
Hatte nur den Artikel 
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_Watchdog 
gelesen.
Ist aber keine Entschuldigung.
Danke für die Hilfe

[Stefan F. (Gast)]

langstrumpf schrieb:
> Hatte nur den Artikel
> https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_Watchdog
> gelesen.

Und da steht klipp und klar:

"Bei neueren AVR-Typen bleibt der Watchdog auch nach einem Reset durch 
den Watchdog aktiviert. Wenn ein Programm nach dem Neustart bis zur 
erstmaligen Rückstellung des Watchdogs länger braucht, als die im 
Watchdog eingestellte Zeit, sollte man den Watchdog explizit möglichst 
früh deaktivieren. Ansonsten resetet der Watchdog den Controller 
immerfort von Neuem. Die frühe Deaktivierung sollte durch eine Funktion 
erfolgen, die noch vor allen anderen Operationen (insbesondere vor dem 
mglw. länger andauernden internen Initialisierungen vor dem Sprung zu 
main()) ausgeführt wird. "

Noch Fragen?

Immer schön bis zum Ende lesen! Das gilt ganz besonders für 
Datenblätter, denn oben kommt die Werbung, dann die schöne heile Welt 
und erst zum Schluss die hässliche Wahrheit.

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Noch Fragen?
>
> Immer schön bis zum Ende lesen! Das gilt ganz besonders für
> Datenblätter, denn oben kommt die Werbung, dann die schöne heile Welt
> und erst zum Schluss die hässliche Wahrheit.

Oh Gott erwischt:-D

Diese Analyse der Datenblätter muss ich mir merken!
Vielen Dank!!!

[Peter D. (peda)]

Gerne setzt man den Watschdog so früh wie möglich (z.B. in .init1) auf 
2s, das sollte für den Init-Kram reichen, bis man in die Mainlooop 
kommt.
2s ist auch eine schöne Zeit, um zu bemerken, daß der Watchdog 
zugeschlagen hat. Bei nur 15ms legt man sich oft die Karten, warum das 
Programm verrückte Sachen macht.
Man kann auch den Resetgrund auslesen und anzeigen, welche Quelle den 
Reset ausgelöst hat. Insbesondere, wenn kein Flag gesetzt ist, d.h. das 
Programm durch zerstörte Pointer über 0x0000 gelaufen ist, sollte man 
das anzeigen.
Es sollen schon Leute wochenlang solche Fehler gesucht haben.

Will man den Watchdog benutzen, sollte man ihn immer per Fusebit 
enablen. Ein schlafender Watchdog (disabled) bietet keine zusätzliche 
Sicherheit.

[langstrumpf (Gast)]

Ich muss leider noch mal Eure Hilfe in Anspruch nehem.
Die Funktion wdt_disable(); Funktioniert bei mir und meinem At90 Can128 
nicht.
Ich im Datenblatt steht

/* Write logical one to WDCE and WDE */
  WDTCR = (1<<WDCE) | (1<<WDE);
  /* Turn off WDT */
  WDTCR = 0x00;

Aber auch diese Funktion lässt das Programm nicht starten wenn der WD 
einmal zugebissen hat.
Was mache ich falsch? Was Überlese ich?
Die Fuse des WD ist aus.

[Stefan F. (Gast)]

Hast du davo irgendeine Initialisierung die lange dauert? Vielleicht 
auch in einer init-Sektion anstall in main()?

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Hast du davo irgendeine Initialisierung die lange dauert? Vielleicht
> auch in einer init-Sektion anstall in main()?

Hallo und Danke für die Hilfe.
Nein eigendlich mache ich das als erstes.

Habe mal zwei Bilder angehängt

[Einer K. (Gast)]

langstrumpf schrieb:
> Nein eigendlich mache ich das als erstes.

Also nicht als erstes!

Lesestoff: AVR .init section

Dort!


Auch ist das Timing wichtig.
Das kann schon mal ins Auge gehen, je nach Optimierungsstufe.
evtl ist das Makro wdt_disable() besser geeignet, als das händisch zu 
tun.

[HildeK (Gast)]

langstrumpf schrieb:
> Habe mal zwei Bilder angehängt

Ich habe in altem Code dieses hier gefunden:

WDTCR |= (1<<WDCE) | (1<<WDE);  // timed Sequence
WDTCR &= ~(1<<WDE);        // oder auch WDTCR = 0;

[Stefan F. (Gast)]

Meinst du nicht, dass es langsam mal Zeit, wird, den ganzen Quelltext zu 
zeigen, anstatt immer nur um den Stein der Weisen zu diskutieren und 
unzureichende Fotos zu machen?

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Meinst du nicht, dass es langsam mal Zeit, wird, den ganzen Quelltext zu
> zeigen, anstatt immer nur um den Stein der Weisen zu diskutieren und
> unzureichende Fotos zu machen?

Kann ich nicht da der Can Stack Kommerziell ist und ich diesen nicht 
veröffentlichen darf.

uint8_t mischer_state=0;
uint16_t time_Umwaelzen=0,time_Move_Mischer=0,dummy;
uint8_t sollmin=35,sollmax=38,_regler=0,_regler_max=0;
uint16_t umaeltz_zeit=480,regelintervall_zeit=180;
uint16_t closetime=3500,opentime=3000,closetime_fast=7000,opentime_fast=6000;
uint8_t i2c_input,output=0;
uint8_t paul=200;
volatile uint8_t backup_mcusr;

/* local defined variables*/
void code_init0(void) __attribute__ ((naked, used, section (".init3")));

/* !!! never call this function !!! */
void code_init0 (void)
{
  WDTCR = (1<<WDCE) | (1<<WDE);
  /* Turn off WDT */
  WDTCR = 0x00;
  backup_mcusr = MCUSR;
}



int main(void)
{
  /* Write logical one to WDCE and WDE */
  
    //wdt_disable();
  PORTA = 0xff;
  DDRB = 0xff;
  DDRC =0xff;
  DDRE |= (1<<Out_Runled)|(1<<Out_Sitz_senken)|(1<<DiagEnable_Steckdose_X5);
  //PORTE |=(1<<Status_Sitz_heben)|(1<<Status_Sitz_senken)|(1<<End_Sitz_unten)|(1<<D_PLUS);
  PORTG |=(1<<INPUT_10)|(1<<INPUT_11)|(1<<INPUT_12);
  PORTF |=(1<<INPUT_1);

ISt das so richtig?

Danke für die Hilfe

[Stefan F. (Gast)]

langstrumpf schrieb:
> ISt das so richtig?

Das ergibt sich aus dem Assembler Listing. Warum benutzt du immer noch 
nicht das Makro aus der avr-libc?

Bei deinem C Code weisst du nie, was der Compiler daraus macht, 
insbesondere und ob er das geforderte Timing einhält. Das Makro sieht 
nicht zum Spaß ganz anders aus: 
https://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html

[W.S. (Gast)]

langstrumpf schrieb:
> Ich war bis Heute der Meinung das Reset und powercycle das selbe
> bewirkt.
> Wo können die Unterschiede sein?
> Wie kann ich sowas debuggen?

1. Es ist eben nicht dasselbe. Das hättest du im Manual nachlesen 
können.
2. Die Unterschiede bestehen darin, daß der generelle Zustand des Chips 
nach verschiedenene Arten des Resets eben unteschiedlich ist.
3. garnicht.

Bei einigen Chips (z.B. manchen Kinetis) besteht der einzige Weg, 
überhaupt bis zu main() zu kommen darin, den WD als allererstes 
auszuschalten.

Mein Reden seit ewig ist deshalb, immer beim Anlauf des µC davon 
auszugehen, daß man alles und jedes selbst aufsetzen soll - ohne davon 
auszugehen, daß irgend ein Register einen Resetwert enthält.

W.S.

[Stefan F. (Gast)]

W.S. schrieb:
> immer beim Anlauf des µC davon
> auszugehen, daß man alles und jedes selbst aufsetzen soll - ohne davon
> auszugehen, daß irgend ein Register einen Resetwert enthält.

Anstatt von irgend etwas auszugehen, orientiere ich mich am Datenblatt 
bzw. Referenzhandbuch. Darin sind die Zustände nach dem Reset (bzw. den 
unterschiedlichen Reset-Varianten falls vorhanden) unmissverständlich 
beschrieben.

[W.S. (Gast)]

Stefan ⛄ F. schrieb:
> Anstatt von irgend etwas auszugehen

Da sprichst du mir zwar aus der Seele, aber die Realität sieht genau 
anders herum aus. Da wird das Manual als viel zu lästig angesehen, 
irgendwelche Vorkennnisse werden ebenfalls als überflüssig (und zu 
schwer zu erlernen) erachtet und man will sofort!!!!! mit seinem XYZ 
zum Mond fliegen, ohne jemals das Laufen (geschweige denn das Fliegen) 
erlernt zu haben.

Was darf man da noch erwarten?

W.S.

[Stefan F. (Gast)]

Wenn alle andere Idioten sind, sollte man mal darüber nachdenken, wer 
hier der Geisterfahrer ist.

Ehrlich Mann, halte dich doch mal mit solchen Worten zurück! Du kennst 
die Leute nicht. Hast du nur zwei Schubladen (Ich und die doofen), oder 
welches Bild willst du nach außen abgeben?

[langstrumpf (Gast)]

Hallo

/* local defined variables*/
void code_init0(void) __attribute__ ((naked, used, section (".init0")));

/* !!! never call this function !!! */
void code_init0 (void)
{
  wdt_disable();
}



int main(void)
{
  /* Write logical one to WDCE and WDE */
  
    //wdt_disable();
  PORTA = 0xff;
  DDRB = 0xff;
  DDRC =0xff;
  DDRE |= (1<<Out_Runled)|(1<<Out_Sitz_senken)|(1<<DiagEnable_Steckdose_X5);
  //PORTE |=(1<<Status_Sitz_heben)|(1<<Status_Sitz_senken)|(1<<End_Sitz_unten)|(1<<D_PLUS);
  PORTG |=(1<<INPUT_10)|(1<<INPUT_11)|(1<<INPUT_12);
  PORTF |=(1<<INPUT_1);
  // Timer0 config
  OCR0A = (uint8_t

Ist es so korrekt wie ich es mit der init section mache ?

Warum Funktioniert es nicht so wie es im Datenblatt steht?


Das Ergebnis ist das selbe.

Danke für die Hilfe

[Stefan F. (Gast)]

langstrumpf schrieb:
> Ist es so korrekt wie ich es mit der init section mache ?

Du hast es immer noch nicht so gemacht, wie in der Doku der avr-libc 
beschrieben. Ist das denn so schwer, die paar Zeilen code zu kopieren?

So gehört das!:

uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void get_mcusr(void) \
  __attribute__((naked)) \
  __attribute__((section(".init3")));
void get_mcusr(void)
{
  mcusr_mirror = MCUSR;
  MCUSR = 0;
  wdt_disable();
}

Oder so, wenn du die Reset-Quelle weiterhin nicht auswerten willst (aber 
genau das wolltest du doch):

void was_auch_immer(void) \
  __attribute__((naked)) \
  __attribute__((section(".init3")));
void was_auch_immer(void)
{
  MCUSR = 0;
  wdt_disable();
}

langstrumpf schrieb:
> Warum Funktioniert es nicht so wie es im Datenblatt steht?

Das ergibt sich aus dem Assembler-Listung, das du immer noch nicht
gezeigt hast. Du sollst vergleichen, was der C-Compiler aus dem
Quelltext gemacht hat, mit dem was im Datenblatt steht.

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Du hast es immer noch nicht so gemacht, wie in der Doku der avr-libc
> beschrieben. Ist das denn so schwer, die paar Zeilen code zu kopieren?

Ja leider weiß ich nicht wie ich den Code in meinen Code einbauen muss.
Bitte erkläre es mir.

uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void get_mcusr(void) \
__attribute__((naked)) \
__attribute__((section(".init3")));


int main(void)
{
  
  void get_mcusr(void)
  {
    mcusr_mirror = MCUSR;
    MCUSR = 0;
    wdt_disable();
  }
  
    //wdt_disable();
  PORTA = 0xff;
  DDRB = 0xff;

Ist die Position des Macros an der richtigen stelle

Ich hatte Dir das ASM File im Beitrag 
Beitrag "Re: WD-Reset und Reset Pin erzeugen nicht das selbe wie Power off"
angehängt und ich war der Überzeugung das es so wie im Datenblatt 
aussieht.



Danke für deine Hilfe und Geduld

[Stefan F. (Gast)]

Einfach rein kopieren, nicht einbauen. Funktionen in der init Sektion 
werden automatisch vor main() ausgeführt.

> Ist die Position des Macros an der richtigen stelle.

nein

Du sollst das so machen:

#include <stdint.h>
#include <avr/wdt.h>

uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void get_mcusr(void) \
  __attribute__((naked)) \
  __attribute__((section(".init3")));

void get_mcusr(void)
{
  mcusr_mirror = MCUSR;
  MCUSR = 0;
  wdt_disable();
}

int main(void)
{
   ....
}

[Stefan F. (Gast)]

langstrumpf schrieb:
> Ich hatte Dir das ASM File im Beitrag
> Beitrag "Re: WD-Reset und Reset Pin erzeugen nicht das selbe wie Power
> off" angehängt und ich war der Überzeugung das es so wie im Datenblatt
> aussieht.

Erstens entspricht das nicht dem aktuelle Stand deines Codes. Zweitens 
sieht es ganz anders aus, als im Datenblatt beschrieben. Ich zitiere 
auch das mal für dich:

WDT_off:
    ; Write logical one to WDCE and WDE
    ldi   r16,   (1<<WDCE)|(1<<WDE)
    sts   WDTCR,   r16

    ; Turn off WDT
    ldi   r16,   (0<<WDE)
    sts   WDTCR,   r16

    ret

void WDT_off(void){
    /* Write logical one to WDCE and WDE */
    WDTCR = (1<<WDCE) | (1<<WDE);

    /* Turn off WDT */
    WDTCR = 0x00;
}

In deinem C Quelltext (und dem daraus resultierenden Assembler Listing) 
steht aber:

WDTCR=x00;

Siehst du nicht, dass da eine komplette Zeile fehlt?

Außerdem gibt es einen Unterschied zwischen den Sektionen init0 und 
init3. Siehe 
https://www.nongnu.org/avr-libc/user-manual/mem_sections.html

Init 0, 1 und 2, da ist der Stackpointer noch nicht initialisiert. Du 
darfst zudem nur die Sektionen nutzen, die als "User definable." 
gekennzeichnet sind.

Das hat schon seinen Grund, dass die Beispiele init3 benutzen.

[Stefan F. (Gast)]

Mal eine ganz andere Frage: Warum benutzt du den Watchdog?

Normalerweise laufen Mikrocontroller jahrelang fehlerfrei ohne Watchdog. 
Du machst Dir mit dem Ding das Leben nur unnötig schwer, weil er (wie du 
siehst) eine Dinge verkompliziert und zudem gravierende Programmfehler 
kaschiert, die man lieber korrigieren sollte.

Du willst doch auch nicht deinen PC jeden Tag rebooten müssen (weil die 
Softwarehersteller schlampig arbeiten), wie zu Windows 95 Zeiten.

[langstrumpf (Gast)]

Hier ist irgendwie der Wurm drin.
Im Anhang das Asm.
Ich habe es so gemacht wie du es geschrieben hast aber das Ergebnis ist 
immer noch das selbe.

Stefan ⛄ F. schrieb:
> Mal eine ganz andere Frage: Warum benutzt du den Watchdog?
>
> Normalerweise laufen Mikrocontroller jahrelang fehlerfrei ohne Watchdog.
> Du machst Dir mit dem Ding das Leben nur unnötig schwer, weil er (wie du
> siehst) eine Dinge verkompliziert und zudem gravierende Programmfehler
> kaschiert, die man lieber korrigieren sollte.

Der code funktioniert ja auch gut.
Es ist nur so das der Canmaster in der Lage sein will einen Reset der 
Slaves auszuführen.
Dazu habe ich den WD gebraucht. Und deshalb ärgere ich mich mit 
selbigen.

Danke für deine Hilfe

[Stefan F. (Gast)]

langstrumpf schrieb:
> Im Anhang das Asm.

Ich sehe keinen Anhang. Den C-Quelltext solltest du auch zeigen, wenn du 
über konkreteres als heiße Luft diskutieren möchtest.

[Stefan F. (Gast)]

langstrumpf schrieb:
> Es ist nur so das der Canmaster in der Lage sein will einen Reset der
> Slaves auszuführen. Dazu habe ich den WD gebraucht.

Klingt für mich nach einem schweren Designfehler. Der Watchdog ist für 
etwas anderes vorgesehen.

[langstrumpf (Gast)]

Sorry

Hier die Dateien

[Stefan F. (Gast)]

Bitte nicht schon wieder Screenshots! Die zeigen doch wieder nur einen 
kleinen Ausschnitt!

Sieht gut aus. Funktioniert es denn jetzt?

Wenn nicht, bist du ganz sicher, dass dein Problem überhaupt vom 
Watchdog kommt? Wenn du unsicher bist, dann aktiviere ihn mal zur Probe 
nicht.

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Bitte nicht schon wieder Screenshots!

Also Hier der Code

uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void get_mcusr(void) \
  __attribute__((naked)) \
  __attribute__((section(".init3")));

void get_mcusr(void)
{
  mcusr_mirror = MCUSR;
  MCUSR = 0;
  wdt_disable();
}


int main(void)
{
  
  
  PORTA = 0xff;
  DDRB = 0xff;
  DDRC =0xff;
  DDRE |= (1<<Out_Runled)|(1<<Out_Sitz_senken)|(1<<DiagEnable_Steckdose_X5);
  //PORTE |=(1<<Status_Sitz_heben)|(1<<Status_Sitz_senken)|(1<<End_Sitz_unten)|(1<<D_PLUS);
  PORTG |=(1<<INPUT_10)|(1<<INPUT_11)|(1<<INPUT_12);
  PORTF |=(1<<INPUT_1);
  // Timer0 config

[langstrumpf (Gast)]

Es funktioniert nicht.
Wenn ich die Endlosschleife für mein Softreset entferne dann 
funktioniert der Sprung in die Funktion des Softreset und das Programm 
läuft weiter.
Wie sonst kann man bei Avr einen Soft Reset erzeugen?

Lg

[langstrumpf (Gast)]

if ((execute==CO_TRUE)&&(newState==CO_NMT_STATE_RESET_NODE))
  {
    while(1)
    {
      if (get_edge(newState == CO_NMT_STATE_RESET_NODE)==RISE)
      {
        printf("reset in 2s\r\n");
      }
    }
  }

Hier wird im der NMT Auswertung der Reset erzeugt

[Stefan F. (Gast)]

langstrumpf schrieb:
> Wie sonst kann man bei Avr einen Soft Reset erzeugen?

Jetzt kommen wir zur eigentliche Frage. Heiliger Bimbam.

Der einfachste Weg ist: Verbinde den RESET Eingang mit einem I/O Pin und 
schalte diesen auf LOW.

Der elegante Weg geht über den Watchdog, aber das klappt bei Dir nicht. 
Also musst du jetzt heraus finden, warum es nicht klappt. Mit einem 
Debugger wird das vermutlich sehr viel schneller klappen, als mit 
diskutieren.

[(prx) A. K. (prx)]

Stefan ⛄ F. schrieb:
>> Es ist nur so das der Canmaster in der Lage sein will einen Reset der
>> Slaves auszuführen. Dazu habe ich den WD gebraucht.
>
> Klingt für mich nach einem schweren Designfehler. Der Watchdog ist für
> etwas anderes vorgesehen.

Er ist zwar nicht eigens dafür vorgesehen. Aber es kann mitunter recht 
nützlich sein, wenn sich ein µC selbst zurücksetzen kann. Da ein AVR 
dafür keinen eigenen Befehl hat, spricht wenig dagegen, dafür den WDT zu 
verwenden.

[Jens G. (jensg)]

mit einer solchen Funktion habe ich ein Reset ausgelöst.

void reboot() {
  MCUSR = 0;
  wdt_disable();
  wdt_enable(WDTO_15MS);
  while (1) {}
}

Sorry, ich habe es in der Umgebung von Arduino so gemacht.

[Stefan F. (Gast)]

Jens G. schrieb:
> Sorry, ich habe es in der Umgebung von Arduino so gemacht.

Da kommt die nächste Salamischeibe. Das hättest du ganz am Anfang 
schreiben sollen! Arduino benutzt die Init Sektionen und die main() 
Funktion nämlich auf ihre spezielle Art. Da sind die konkreten Infos 
allerding nicht so leicht zu finden. Wie dem auch sei, bei Arduino ist 
es nicht vorgesehen, dass du als Anwendungsprogrammierer die init 
Sektionen benutzt.

Mein Tipp, um das Ganze abzukürzen: Verzichte darauf, den Watchdog zu 
deaktivieren.Lasse ihn immer laufen, aber mit einem wesentlich größeren 
Zeitfenster, z.B. 200ms. Dann hast du reichlich Zeit, ihn in deinem 
Programm regelmäßig zu resetten, so dass er neben deinem Anwendungsfall 
auch seiner Hauptaufgabe nachkommen kann (unbeabsichtigte Hänger zu 
erkennen).

[Jens G. (jensg)]

Stefan ⛄ F. schrieb:
> Jens G. schrieb:
>> Sorry, ich habe es in der Umgebung von Arduino so gemacht.
> Dann hast du reichlich Zeit, ihn in deinem
> Programm regelmäßig zu resetten, so dass er neben deinem Anwendungsfall
> auch seiner Hauptaufgabe nachkommen kann (unbeabsichtigte Hänger zu
> erkennen).
Ich bin ein wenig ein "Dummy" auf diesem Gebiet - verwende den Watchdog 
eigentlich gar nicht. "Wie man ein Watchdog in Arduino regelmäßig 
resettet" ist mir völlig unbekannt. Das Stück Software, das ich 
vorgeschlagen habe. Macht das was soll -- den AVR rebooten - also ein 
Reset auslösen.

[Stefan F. (Gast)]

Jens G. schrieb:
> Wie man ein Watchdog in Arduino regelmäßig
> resettet" ist mir völlig unbekannt

Dann lass die Finger vom Watchdog und benutze einen I/O Pin zum 
resetten.

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Jens G. schrieb:
>> Sorry, ich habe es in der Umgebung von Arduino so gemacht.
>
> Da kommt die nächste Salamischeibe. Das hättest du ganz am Anfang
> schreiben sollen! Arduino benutzt die Init Sektionen und die main()
> Funktion nämlich auf ihre spezielle Art. Da sind die konkreten Infos
> allerding nicht so leicht zu finden. Wie dem auch sei, bei Arduino ist
> es nicht vorgesehen, dass du als Anwendungsprogrammierer die init
> Sektionen benutzt.
>
> Mein Tipp, um das Ganze abzukürzen: Verzichte darauf, den Watchdog zu
> deaktivieren.Lasse ihn immer laufen, aber mit einem wesentlich größeren
> Zeitfenster, z.B. 200ms. Dann hast du reichlich Zeit, ihn in deinem
> Programm regelmäßig zu resetten, so dass er neben deinem Anwendungsfall
> auch seiner Hauptaufgabe nachkommen kann (unbeabsichtigte Hänger zu
> erkennen).

Ich verwende nicht Arduino.
Ich Verwende Gcc.
Ich habe in meinem Layout keinen Pin zum Reseten vorgesehn.

Stefan ⛄ F. schrieb:
> Mit einem
> Debugger wird das vermutlich sehr viel schneller klappen, als mit
> diskutieren.

Ich erkenne da nur das der Wd ein ist aber nicht wiso er sich nicht 
ausschalten lässt.
Was kann ich also mit dem Debugger konkret schauen was hilft?

Lg

[Jens G. (jensg)]

Stefan ⛄ F. schrieb:
> Jens G. schrieb:
>> Wie man ein Watchdog in Arduino regelmäßig
>> resettet" ist mir völlig unbekannt
>
> Dann lass die Finger vom Watchdog und benutze einen I/O Pin zum
> resetten.
Ich hatte leider kein Pin mehr frei und hab es dann auf diese Weise 
gelöst.

[Jens G. (jensg)]

langstrumpf schrieb:
> Ich verwende nicht Arduino.
> Ich Verwende Gcc.
> Ich habe in meinem Layout keinen Pin zum Reseten vorgesehn.
Es sollte auch ohne Arduino gehen.
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_Watchdog

[Stefan F. (Gast)]

Jens G. schrieb:
> Sorry, ich habe es in der Umgebung von Arduino so gemacht.

langstrumpf schrieb:
> Ich verwende nicht Arduino.

Wie ist das zu verstehen?

> Ich Verwende Gcc.

Das tut Arduino auch.

> Ich habe in meinem Layout keinen Pin zum Reseten vorgesehn.

Dann ändere das halt, oder lerne, deinen Watchdog zu debuggen. Meine 
Frage bezüglich des Debuggers hast du nicht beantwortet.

langstrumpf schrieb:
> Was kann ich also mit dem Debugger konkret schauen was hilft?

Du kannst nachschauen, ob der Code zum Ausschalten überhaupt ausgeführt 
wird und ob der WDT danach wirklich aus ist. Und wenn nicht, dann wirst 
du beim Durchsteppen schon sehen, woran es scheitert.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> Wie dem auch sei, bei Arduino ist
> es nicht vorgesehen, dass du als Anwendungsprogrammierer die init
> Sektionen benutzt.
Was ist das denn für eine unsinnige Behauptung?

Stefan ⛄ F. schrieb:
> Arduino benutzt die Init Sektionen und die ...
> ... nämlich auf ihre spezielle Art.
Auch das ist falsch!

Die init Sections werden gar nirgendwo angefasst.
Im gesamten Arduino Core nicht.
Es wird die AVR-GCC Toolchain genutzt, und auch das dabei mit gelieferte 
Initverfahren.


Was soll das, solchen Blödsinn in die Welt zu setzen?
Bezahlt dich einer dafür?

[Stefan F. (Gast)]

Arduino Fanboy D. schrieb:
> Bezahlt dich einer dafür?

Ja, ich werden von der Calliope GmbH dafür bezahlt, dich auf die Palme 
zu bringen. Ziel ist es, dich dazu zu bringen, Arduino zu verfluchen, 
damit du alle Arduino Jünger bekehrst und die Firma keine Konkurrenz 
mehr hat.

Aber um auf das technische Thema zurück zu kommen: Du hast sicher 
erkannt, was der TO falsch macht und kannst ihm zügig helfen...

mach mal.

[foobar (Gast)]

Ein Hinweis, falls du den Arduino-Bootloader benutzt:

Die China-Arduinos haben häufig noch einen alten Bootloader, der den WDT 
nicht zurücksetzt.  Während er nun kurz wartet, ob evtl programmiert 
werden soll, schlägt der WDT wieder zu.  Der Effekt ist der von dir 
beschriebene.  Zu dem WDT-disable der Anwendung kommt er erst gar nicht.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> Ja, ich werden von der Calliope GmbH dafür bezahlt ......
Da habe ich dich also bei einer dumm dreisten Arduino Bashing Lüge 
erwischt?
Oder hast du wirklich so wenig Ahnung von dem Zeugs, worüber du dauend 
herziehst?


Rückwärtsgang einlegen und Fehler eingestehen ist nicht drin?
Und damit auch keine Korrektur deines Verhaltens, für die Zukunft.
Richtig?



Stefan ⛄ F. schrieb:
> Aber um auf das technische Thema zurück zu kommen: Du hast sicher
> erkannt, was der TO falsch macht und kannst ihm zügig helfen...

Tja...
Habe gesagt, was ich weiß, und kann nicht testen, da der µC nicht vor 
mir liegt.

Kannste dir ein Beispiel dann nehmen.
Ich merke (hoffentlich meist) wenn ich von irgendwas KA habe und halte 
dann die Schnauze.

Wäre vielleicht auch mal was für dich.

foobar schrieb:
> Die China-Arduinos haben häufig noch einen alten Bootloader, der den WDT
> nicht zurücksetzt.
Durchaus möglich!
Wobei ich mir aber recht sicher bin, dass es keinen  AT90Can128 Arduino 
gibt.

[langstrumpf (Gast)]

Ich habe nichts von einem Arduino gesagt:(

[Einer K. (Gast)]

langstrumpf schrieb:
> Ich habe nichts von einem Arduino gesagt:(
Habe ich auch nichts von gehört....

Ist einfach nur eine Nebelkerze gewesen.
Und die Basher kommen dann sofort aus allen Ritzen.
Ist hier halt oft so.



Aber ...

Hast du denn einen Bootloader drauf?
Denn da kann der Hase im Pfeffer liegen.

[Stefan F. (Gast)]

langstrumpf schrieb:
> Ich habe nichts von einem Arduino gesagt

Bist du nicht = Jens G?

Ich bin verwirrt.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> Ich bin verwirrt.

In dem Punkt scheinst du recht zu haben.

[langstrumpf (Gast)]

langstrumpf bin ich

[FabiWa (Gast)]

Stefan ⛄ F. schrieb:
> Der einfachste Weg ist: Verbinde den RESET Eingang mit einem I/O Pin und
> schalte diesen auf LOW.

Ich habe mal gelernt, dass man das nicht tun sollte, da ein korrekter 
Reset dann nicht garantiert werden kann. Das Problem ist wohl, dass der 
RESET-Eingang dann unter Umständen nicht lang genug LOW ist.

Stattdessen sollte ein Reset-Generator verwendet werden, z.B. ein 
MAX701.

[langstrumpf (Gast)]

Guten Morgen,
neuer Tag neues Glück;)
Können wir nochmal versuchen mein Problem zu lösen?

Also nochmal ein paar Fakten.
-At90Can128
-Keinen Arduino Bootloader oder etwas anderes von Arduino.
-Ich brauche den Watchdog für einen Softreset.
-Der Softreset funktioniert!
-Das Problem ist das nach dem auslösen des WD ich nicht in der lage bin 
den WD auszuschalten.
-Laut Beitrag "Re: WD-Reset und Reset Pin erzeugen nicht das selbe wie Power off" sieht das 
Assemblerfile gut aus.
-Also was kann ich nun tun das der Watchdog sich ausschalten lässt?
-Was kann ich noch Debuggen?

Danke für die Hilfe schönen gesunden Sonntag

[langstrumpf (Gast)]

Weitere erkenntnis.
Wenn ich die Optimierung aus schalte dann funktioniert das Ausschalten 
des WD.
Wenn ich Jedoch die Optimierung ganz normal auf Os schalte dann ist das 
Verhalten eine Endlosschleife die versucht den WD auszuschalten.

Im Anhang die zwei Bilder der ASM wobei "ich" keine Unterschiede sehe.

[Stefan F. (Gast)]

FabiWa schrieb:
> Ich habe mal gelernt, dass man das nicht tun sollte, da ein korrekter
> Reset dann nicht garantiert werden kann. Das Problem ist wohl, dass der
> RESET-Eingang dann unter Umständen nicht lang genug LOW ist.

Ist mir noch  icht passiert, aber ja, klingt nachvollziehbar. Wobei ein 
kleiner Kondensator am Reset Pin (der ohnehin meist vorhanden ist) den 
Impuls ausreichend verlängern wird.

[Stefan F. (Gast)]

langstrumpf schrieb:
> Was kann ich noch Debuggen?

Wie gesagt, prüfe ob der Code zum Ausschalten des Watchdogs überhaupt 
ausgeführt wird.

langstrumpf schrieb:
> Weitere erkenntnis.

Schon wieder Screenshots?!?! Bitte tue uns den Gefallen und benutze die 
Zwischenablage um Text zu posten.

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Wie gesagt, prüfe ob der Code zum Ausschalten des Watchdogs überhaupt
> ausgeführt wird.

Ja der Code wird ausgeführt. Ich kann durchsteppen mit dem Debugger

[Stefan F. (Gast)]

langstrumpf schrieb:
> Ja der Code wird ausgeführt. Ich kann durchsteppen mit dem Debugger

Gezielte Suche bringt dich also nicht weiter. Das ist schade. Zeit für 
Plan B: Die Trial and Error Phase. Die beginnt mit der Annahme, dass die 
Fehlerursache irgendwo ganz woanders sein könnte.

Schreibe zur Gegenprobe mal ein minimales Programm, was in der Init 
Sektion zuerst eine LED einschaltet, dann den Watchdog deaktiviert, dann 
eine zweite LED einschaltet, dann in main() eine dritte LED einschaltet 
und dann den Reset auslöst. Der Watchdog soll dabei auf maximale Zeit 
(mindestens 200ms) konfiguriert sein, damit man was sehen kann. Dann 
schauen wir mal, welche LEDs wann angehen.

Außerdem hast du dann einen Quelltext, den du komplett vorzeigen kannst, 
dann hört die Raterei endlich auf.

Sollte das Problem mit so einem Minimalprogramm nicht nachvollziehbar 
sein, liegt die Problemursache sehr wahrscheinlich ganz woanders. Das 
kannst du weiter einkreisen, indem du Stückweise immer mehr von deinem 
großen Programm auskommentierst, bis der Fehler verschwindet.

[(prx) A. K. (prx)]

Ist gesichert, dass der Watchdog auch wirklich die Ursache ist?

[Peter D. (peda)]

langstrumpf schrieb:
> Wenn ich Jedoch die Optimierung ganz normal auf Os schalte dann ist das
> Verhalten eine Endlosschleife die versucht den WD auszuschalten.

Laß das asm Gefrickel, nimm wdt_disable() aus wdt.h.
Laß auch das mit der Init-Section, d.h. packe es an den Anfang des Main.

[Jens G. (jensg)]

hier gibt es noch Informationen in deutsch:
https://www-user.tu-chemnitz.de/~heha/viewchm.php/hs/ATmegaX8.chm/11.htm

Wie auch immer, das Stück Software "reboot()" tut das was es sagt. Hat 
nichts damit zu tun ob man Arduino nutzt oder auch nicht. Ardino 
verwendet auch Routinen vom GCC.

[Stefan F. (Gast)]

Jens G. schrieb:
> das Stück Software "reboot()" tut das was es sagt

Da liegt ja auch nicht das Problem, sondern beim Abschalten des Watchdog 
timers.

[OpenStack (Gast)]

langstrumpf schrieb:
> Kann ich nicht da der Can Stack Kommerziell ist und ich diesen nicht
> veröffentlichen darf.

Doch, das darft du!

Du bist im uC-Net und fragst uns Experten. Quasi Kollegen. Du kannst ja 
später die Daten wieder löschen lassen. Ist so übrigens üblich 
vorzugehen.

[Einer K. (Gast)]

langstrumpf schrieb:
> -Keinen Arduino Bootloader oder etwas anderes von Arduino.

Die Frage war:
OB du einen Bootloader verwendest!
Und nicht, welche Geschmacksrichtung er hat.

[langstrumpf (Gast)]

Ich habe wie vorgeschlagen ein Minimalistisches Programm geschrieben.
Und Wie erwartet funktioniert es auch so wie es soll.

Wenn ich eine kleine State Maschine aus der Main auskommentiere dann 
funktioniert es auch in meinem Kompletten Programm.

Was im Himmels willen kann ein Switch Case Block  wo ein Paar Bits 
geschunkelt werden auf das WD ausschalten bewirken??

Peter D. schrieb:
> aß das asm Gefrickel, nimm wdt_disable() aus wdt.h.
> Laß auch das mit der Init-Section, d.h. packe es an den Anfang des Main.

Auch dein Vorschlag funktioniert wenn ich die oben genannte State 
Maschine aus kommentiere.

Versuche jetzt diese State Maschine weiter zu kürzen damit ich sie 
einstellen kann.

[Stefan F. (Gast)]

langstrumpf schrieb:
> Was im Himmels willen kann ein Switch Case Block  wo ein Paar Bits
> geschunkelt werden auf das WD ausschalten bewirken??

Es könnte durchaus sein, dass die ganze Problematik mit dem Ausschalten 
des Watchdogs gar nichts zu tun hat.

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Es könnte durchaus sein, dass die ganze Problematik mit dem Ausschalten
> des Watchdogs gar nichts zu tun hat.

Wie meinst du das?

[Stefan F. (Gast)]

langstrumpf schrieb:
> Stefan ⛄ F. schrieb:
>> Es könnte durchaus sein, dass die ganze Problematik mit dem Ausschalten
>> des Watchdogs gar nichts zu tun hat.
>
> Wie meinst du das?

Vielleicht hast du eine Race Condition. Irgend eine externe Bedingung, 
die dein Programmablauf beim Start verlangt, liegt vielleicht nicht 
rechtzeitig vor. Oder du initialisiert irgend etewas (z.B. ein Display) 
zu früh.

Ich hatte mal einen Laptop, der sich bei jedem Warmstart aufhängte, aber 
Kaltstarts gingen zu 100%.

Ohne deinen Schaltplan und Quelltext gesehen zu haben, kann man da nur 
alle möglichen Szenarien in eine wilde Vermutungs-Suppe werfen.

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> Vielleicht hast du eine Race Condition. Irgend eine externe Bedingung,
> die dein Programmablauf beim Start verlangt, liegt vielleicht nicht
> rechtzeitig vor. Oder du initialisiert irgend etewas (z.B. ein Display)
> zu früh.
>
> Ich hatte mal einen Laptop, der sich bei jedem Warmstart aufhängte, aber
> Kaltstarts gingen zu 100%.
>
> Ohne deinen Schaltplan und Quelltext gesehen zu haben, kann man da nur
> alle möglichen Szenarien in eine wilde Vermutungs-Suppe werfen.

Jeder externe Reset (Resettaster) Jeder Power On geht gut! 100fach 
getestet.
Der Code der den Watchdog ausschaltet wird immer erreicht.
Das Ergebnis ist aber ein anderes wenn dieser Switch Case Block in der 
Mein Mit ausgeführt wird.

Irgend einen Einfluss müssen diese Zeilen haben.
Den selben Einfluss wie wenn ich die Optimierung ausschalte.
Was kann das sein?
Hat jemand Lust per Anydesk oder Teamviewer mit mit mir zu Debuggen?

[Stefan F. (Gast)]

langstrumpf schrieb:
> Irgend einen Einfluss müssen diese Zeilen haben.

"Diese Zeilen" habe immer noch nicht sehen können, deswegen kann ich 
deine Frage immer noch nicht beantworten. Ich habe keine Lust mehr, das 
ist Zeitverschwendung ohne Aussicht auf Erfolg.

[langstrumpf (Gast)]

Stefan ⛄ F. schrieb:
> langstrumpf schrieb:
>> Irgend einen Einfluss müssen diese Zeilen haben.
>
> "Diese Zeilen" habe immer noch nicht sehen können, deswegen kann ich
> deine Frage immer noch nicht beantworten. Ich habe keine Lust mehr, das
> ist Zeitverschwendung ohne Aussicht auf Erfolg.

    switch(program_state)
    {
      default:
        if (enable_h)
        {
          output |= (1<<SITZ);
          time_prepare=umaeltz_zeit;
          program_state=INTERVALL;
          output &= ~(1<<OUT_FW);
          output &= ~(1<<OUT_RW);
        }
        else if (enable_high_h)
        {
          output |= (1<<SITZ);
          output &= ~(1<<OUT_FW);
          output |= (1<<OUT_RW);
        }
        else
        {
          output &= ~(1<<SITZ);
          output &= ~(1<<OUT_FW);
          output &= ~(1<<OUT_RW);
          time_prepare=0;
        }
        break;
      case CONTROLL:
        if (pos_Tab[POSITION] < sollmin)
        {
          temperatur_diff=sollmin-pos_Tab[POSITION];
          time_move=(temperatur_diff*700);
          if(time_move<1000) time_move=1000;
          if(time_move>10000) time_move=10000;
          output &= ~(1<<OUT_FW);
          output |= (1<<OUT_RW);
          program_state=MOTION;
        }
        else if (pos_Tab[POSITION] > sollmax)
        {
          temperatur_diff=pos_Tab[POSITION]-sollmax;
          time_move=(temperatur_diff*700);
          if(time_move<1000) time_move=1000;
          if(time_move>10000) time_move=10000;
          output &= ~(1<<OUT_RW);
          output |= (1<<OUT_FW);
          program_state=MOTION;
        }
        else 
        {
          program_state=INTERVALL;
          time_prepare=regelintervall_zeit;
        }
        break;
      case INTERVALL:
        if(time_prepare==0)
        {
          program_state=CONTROLL;
        }
        break;
      case MOTION:
        if(time_move==0)
        {
          output &= ~(1<<OUT_RW);
          output &= ~(1<<OUT_FW);
          time_prepare=regelintervall_zeit;
          program_state=INTERVALL;
        }
        break;
    }

Diese unscheinbaren Zeilen erzeugen das Problem

[langstrumpf (Gast)]

Danke für die Geduld!

[Stefan F. (Gast)]

langstrumpf schrieb:
> Diese unscheinbaren Zeilen erzeugen das Problem

Reduziere es auf noch weniger, bis du die schuldige Zeile gefunden hast.

[Maggi (Gast)]

langstrumpf schrieb:

> default:
>         if (enable_h)
>         {
>           output |= (1<<SITZ);
>           time_prepare=umaeltz_zeit;
>           program_state=INTERVALL;
>           output &= ~(1<<OUT_FW);
>           output &= ~(1<<OUT_RW);
>         }
>         else if (enable_high_h)
>         {
>           output |= (1<<SITZ);
>           output &= ~(1<<OUT_FW);
>           output |= (1<<OUT_RW);
>         }
>         else
>         {
>           output &= ~(1<<SITZ);
>           output &= ~(1<<OUT_FW);
>           output &= ~(1<<OUT_RW);
>           time_prepare=0;
>         }
>         break;

Wie werden denn program_state, enable_h und enable_high_h initialisiert 
bzw. manipuliert? In einem Interrupt?

Denn wenn else-if oder else zutreffen, wird program_state nicht 
verändert. In den beiden Fällen könnte es also sein, dass Dein 
Controller in einer Schleife hängen bleibt.

Es sei denn, "enable_high" wird irgendwann wahr.

[langstrumpf (Gast)]

Es ergibt keinen Sinn.

case CONTROLL:
        if (pos_Tab[POSITION] < sollmin)
        {
          temperatur_diff=sollmin-pos_Tab[POSITION];
          time_move=(temperatur_diff*700);
          if(time_move<1000) time_move=1000;
          if(time_move>10000) time_move=10000;
          PORTB &= ~(1<<1);
          PORTB |= (1<<0);
          program_state=MOTION;
        }
        else if (pos_Tab[POSITION] > sollmax)
        {
          //temperatur_diff=pos_Tab[POSITION]-sollmax;
          //time_move=(temperatur_diff*700);
          //if(time_move<1000) time_move=1000;
          //if(time_move>10000) time_move=10000;
          PORTB &= ~(1<<0);
          PORTB |= (1<<1);
          program_state=MOTION;
        }
        else 
        {
          program_state=INTERVALL;
          time_prepare=regelintervall_zeit;
        }
        break;

wenn diese Zeilen weg kommentiert sind dann geht es mit den Zeilen Geht 
es nicht.
Wie selben Zeilen wie etwas oberhalb.:(((

[OpenStack (Gast)]

langstrumpf schrieb:
> Es ergibt keinen Sinn.
> case CONTROLL:
>         if (pos_Tab[POSITION] < sollmin)

> Wie selben Zeilen wie etwas oberhalb.:(((

Dann lade doch mal den kompletten sourcecode hoch. Du kannst ihn später 
ja wieder löschen

[Peter D. (peda)]

int main(void)
{
  MCUSR = 0;
  wdt_disable();
  // usw.
}

Und Ruhe is.

[langstrumpf (Gast)]

OpenStack schrieb:
> Dann lade doch mal den kompletten sourcecode hoch. Du kannst ihn später
> ja wieder löschen

Nein. Das kann ich nicht.
Ich lasse Dich per AnyDesk oder Teamviewer an den Sorce Code.

[langstrumpf (Gast)]

Peter D. schrieb:
> int main(void)
> {
>   MCUSR = 0;
>   wdt_disable();
>   // usw.
> }
> Und Ruhe is.

Im Normalen Fall wäre das so aber bei mir spinnen ein paar Zeilen in der 
Mein die absolut nichts mit dem Rest zu tun haben.
Banale Bit Schupserei in der main machen das deaktivieren des WD 
unmöglich.

[OpenStack (Gast)]

langstrumpf schrieb:
> OpenStack schrieb:
> Dann lade doch mal den kompletten sourcecode hoch. Du kannst ihn später
> ja wieder löschen
>
> Nein. Das kann ich nicht.
> Ich lasse Dich per AnyDesk oder Teamviewer an den Sorce Code.

Viel Erfolg bei der Suche

[Bauform B. (bauformb)]

FabiWa schrieb:
> Stefan ⛄ F. schrieb:
>> Der einfachste Weg ist: Verbinde den RESET Eingang mit einem I/O Pin und
>> schalte diesen auf LOW.
>
> Ich habe mal gelernt, dass man das nicht tun sollte, da ein korrekter
> Reset dann nicht garantiert werden kann. Das Problem ist wohl, dass der
> RESET-Eingang dann unter Umständen nicht lang genug LOW ist.

Wobei "lang genug" sehr lang sein kann, wenn der uC mit sehr niedrigem 
Takt läuft:

Peter D. schrieb:
> Das dürfte mächtig in die Hose gehen.
> Das CPU-Reset wird erst mit der nächsten Taktflanke erzeugt, die Ports
> gehen aber asynchron in Tristate.

Man will keine Ports mit synchronem Reset, das passt schon. Ob es 
überhaupt eine CPU gibt, die komplett asynchron zurück gesetzt werden 
kann ist die Frage. Und wahrscheinlich ist es nirgends spezifiziert. Und 
selbst wenn, wäre es durch unterschiedliche Gatterlaufzeiten 
undefiniert. Also funktioniert der Trick nicht.

[Peter D. (peda)]

langstrumpf schrieb:
> Banale Bit Schupserei in der main machen das deaktivieren des WD
> unmöglich.

Dann hast Du ein grundsätzlicheas Problem in der Programmablaufplanung.
Der Watchdog darf das Programm nicht beeinflussen. In der Regel 
entwickelt man ein Programm mit Watchdog disabled. Und erst, wenn alles 
einwandfrei läuft, wird der Watchdog hinzugefügt.

[langstrumpf (Gast)]

Guten Morgen,
ich habe gestern Nacht ein neues Prokekt mit Atmel Studio erzeugt.
Alle Quellcodes rein kopiert und nur wie Peter D.  empfohlen hat
MCUSR = 0;
wdt_disable()
an den Anfang der main geklatscht.
Und oh Wunder alles geht so wie es gehen soll.
Hat hier jemand eine Erklärung was im anderen Projekt schief gegangen 
sein kann?
Danke allen die mir mit konstruktiven Ideen geholfen haben.

[langstrumpf (Gast)]

Keiner eine Erklärung zu meinem letzten Beitrag?

[Einer K. (Gast)]

Nöö....

[Stefan F. (Gast)]

Zeige und die beiden kompletten Projekte, dann können wir sie 
vergleichen.