Programm startet erst nach Reset??

Hi,

hab gerade ein kleines Problem mit meinem Arduino UNO SMD.
Ich hab einen kleinen Frequenzgenerator mit Nokia 5110 Display und AD9850 aufgebaut. Dazu hängt noch ein Drehencoder für die Bedienung dran. Am PIN5 kann ich dann noch eine Frequenz messen.

Wenn ich Software flashe, oder die COM-Schnittstelle aufmache, dann startet der Arduino immer mit seinem Programm.
Aber wenn ich das Board über USB anstecke, dann ist es reine Glücksache, ob er losläuft oder nicht. Erst nach einem Reset fängt er definitv an zu starten.
Erst dacht ich, daß die Spannungsversorgung über USB einbricht. Dagegen spricht: Windows sagt, daß am USB-port nur 100mA abgenommen werden. (Ja, ich weiss das ist ein Schätzeisen, aber besser als nichts). Egal, ob ich das LCD oder den AD9850 abstecke, das Phänomen bleibt.
Ich hab auch schon mal eine Zeit in der Setup eingatragen, um da zeitlich etwas zu entzerren. hilft nix. Wahrscheinlich fängt er gar nicht an zu starten.

Hat da jemand eine Idee????

Ich häng mal kurz das wichtigste aus meinem Code dran:

#include <EF_AD9850.h>
#include <FreqCounter.h>
#include <LCD5110_Basic.h>

// ---------------------- LCD STUFF ---------------------------
//LCD5110 myGLCD (SCK, MOSI, DC, RST, CS)
LCD5110 myGLCD(14,15,16,18,17);

// ---------------------- ENCODER STUFF ---------------------------
// usually the rotary encoders three pins have the ground pin in the middle
enum PinAssignments {
  encoderPinA = 2,   // rigth
  encoderPinB = 3,   // left
  clearButton = 4    // Druckknopf
  };

volatile unsigned long encoderPos = 0;  // a counter for the dial
unsigned long lastReportedPos = 1;   // change management
static boolean rotating=false;      // debounce management
unsigned long faktor = 1;

// interrupt service routine vars
boolean A_set = false;              
boolean B_set = false;


// ---------------------- ADS9850 STUFF ---------------------------
// BitData - D11, CLK - D9, FQUP - D10, REST - D12

EF_AD9850 AD9850(9, 10, 12, 11);

//---------------------------- SETUP ------------------------------
void setup()
{
 delay (3000);
  Serial.begin(57600);                    // connect to the serial port
  Serial.println ("Programmstart");

  myGLCD.InitLCD();
  
  pinMode(encoderPinA, INPUT); 
  pinMode(encoderPinB, INPUT); 
  pinMode(clearButton, INPUT);
 // turn on pullup resistors
  digitalWrite(encoderPinA, HIGH);
  digitalWrite(encoderPinB, HIGH);
  digitalWrite(clearButton, HIGH);

// encoder pin on interrupt 0 (pin 2)
  attachInterrupt(0, doEncoderA, CHANGE);
// encoder pin on interrupt 1 (pin 3)
  attachInterrupt(1, doEncoderB, CHANGE);

//  Serial.println("Frequency Counter");
  AD9850.init();
  AD9850.reset();
  AD9850.wr_serial(0x0, 10000); // 10KHz 
  FreqCounter::f_comp= 547;           // Set compensation to 571
  FreqCounter::start(1000);           // Start counting with gatetime of 1000ms
}
//---------------------------- LOOP ---------------------------------
void loop(){
....

Nachtrag:

Das Verhalten tritt auch dann auf, wenn ich das Board anstelle USB mit einer Spannung aus einem Netzteil am Klinkenstecker betreibe. VOn 5 Mal startet er 1-2 mal. :frowning:

Hast Du einen zusätzlichen Elektrolytkondensator auf die Versorgungsspannung geschaltet?
Grüße Uwe

uwefed:
Hast Du einen zusätzlichen Elektrolytkondensator auf die Versorgungsspannung geschaltet?
Grüße Uwe

Nein, sollte ich?
Ich versorge entweder direkt über das USB-Kabel, oder aus einem Steckernetzteil.

hk007:
hab gerade ein kleines Problem mit meinem Arduino UNO SMD.
...
Hat da jemand eine Idee????

Das UNO SMD Board kam im Original mit einem Bootloader-Bug zur Auslieferung, wie es auch bestätigt ist, wobei der Bug wohl nicht bei allen Boards und nicht in allen Fällen den Fehler zeigt. Seriennummern der betroffenen UNO SMD Boards ist 317000 and 317999:

Laut Hersteller hilft es, einen neuen und fehlerfreien Bootloader auf das Board zu brennen.

jurs:
Das UNO SMD Board kam im Original mit einem Bootloader-Bug zur Auslieferung, wie es auch bestätigt ist, wobei der Bug wohl nicht bei allen Boards und nicht in allen Fällen den Fehler zeigt. Seriennummern der betroffenen UNO SMD Boards ist 317000 and 317999:
Issues with the new Arduino UNO Smd edition | Arduino Blog

Laut Hersteller hilft es, einen neuen und fehlerfreien Bootloader auf das Board zu brennen.

Gute Idee, aber lt. Aufkleber auf der Schachtel hat meiner 005580xx. Das kanns nicht sein.

hk007:
Gute Idee, aber lt. Aufkleber auf der Schachtel hat meiner 005580xx. Das kanns nicht sein.

Bist Du Dir eigentlich sicher, dass Du den Code auf einem "Arduino UNO SMD" laufen hast, wie im Ausgangsposting angegeben?

Bei dem geposteten Code mit der Zeile:

LCD5110 myGLCD(14,15,16,18,17);
kommen mir wegen der auf einem UNO-Board verwendeten Pin-Nummern arge Bedenken.

jurs:
Bei dem geposteten Code mit der Zeile:

LCD5110 myGLCD(14,15,16,18,17);
kommen mir wegen der auf einem UNO-Board verwendeten Pin-Nummern arge Bedenken.

Das ist A0 - A4. Also die Analogeingänge.

hk007:
Das ist A0 - A4. Also die Analogeingänge.

Ah, fortschrittliche Programmiertechniken mit undokumentierten Features!

Es scheint jedenfalls ansteckend zu sein. Ich habe selbst mal probeweise mit zwei Funktionen getestet, die Dein LCD5110-Objekt verwendet, und zwar mit digitalPinToBitMask() und digitalPinToPort(), und nun habe ich auch ein Board mit Reset-Problem (UNO-Board, China-Klon).

Das Reset-Problem ist bei mir zwar anders gelagert, bei meinem Board äußert es sich so:

  • Programmstart nach Programmupload ==> immer OK
  • Programmstart nach Power-On ==> immer OK
  • Programmstart nach Offnen des seriellen Monitors ==> fast immer OK
  • Programmstart nach Drücken des Reset-Knopfes ==> oft nicht OK

Wenn das Reset-Problem auftritt, flasht nur die Pin-13 LED dreimal kurz hintereinander, mit Abständen von ca. einer Sekunde zwischen den drei Flashs in einer Endlosschleife, das Programm startet nicht. Offenbar wird der Bootloader nicht mehr verlassen. Und dann hilft auch kein Reset-Knopf mehr weiter: Ich muß entweder das Board kurz vom Strom nehmen und wieder anstecken oder das Programm neu hochladen, dann startet es wieder.

Dieses Reset-Problem hat mein Board meines Erachtens erst bekommen, nachdem ich mit den beiden Funktionen digitalPinToBitMask() und digitalPinToPort(CS) an den Analogports herumgespielt habe.

Ich muss mal sehen, ob ich noch irgendwo einen losen Atmega328 herumliegen habe, dann werde ich den mal austauschen und sehen, ob tatsächlich der Controller so verändert wurde, dass er das Problem nun hat, oder ob es am China-Board liegt und von mir bisher nicht entdeckt wurde, weil ich gar nicht so viel von Hand resettet habe. Mit DIP 28-pol Fassung auf dem Board kann ich meinen Controller ja wenigstens wechseln.

Ah, fortschrittliche Programmiertechniken mit undokumentierten Features!

Hatte halt keine anderen Pins mehr frei.

Ich fürchte auch. daß er im Bootloader hängen bleibt.
Aber das mit der blinkenden LED13 ist bei mir definitiv nicht.
Ich hab jetz mal den aktuellen Bootloader der IDE 1.01 drauf gebrannt. Aber das hat auch nicht gehofen.

Meine Vermutung ist eher ein Spannungsproblem o.ä. beim Einschalten.
Wenn ich beim Einschalten die Reset-Taste drücke und dann nach kurzer Zeit (<1sec) los lasse, dann fährt das Board jedesmal hoch.

hk007:
Ich fürchte auch. daß er im Bootloader hängen bleibt.
Aber das mit der blinkenden LED13 ist bei mir definitiv nicht.

Blinkt Dein Bootloader überhaupt nicht?
Meiner vom Uno China-Klon macht immer die drei Flashs direkt beim Start des Bootloaders.
Reset-Knopf loslassen ==> sofort drei Flashs an der Pin13-LED.

Daher kann ich mein Resetproblem auch eindeutig als eine Endlosschleife des Bootloaders identifizieren:
Drei Flashs an der Pin13-LED - 2 Sekunden Pause - Drei Flashs an der Pin13-LED usw. usw.

Nach den zwei Sekunden, wo eigentlich das Programm starten sollte, startet einfach wieder der Bootloader. Auch durch ein längeres Drücken des Reset-Knopfes kann ich den Controller nicht aus der Bootloader-Endlosschleife holen: Einmal Bootloader-Endlosschleife, immer Bootloader-Endlosschleife. So lange, bis ich den Controller vom Strom nehme oder ein Programm neu hochlade.

hk007:
Ich hab jetz mal den aktuellen Bootloader der IDE 1.01 drauf gebrannt. Aber das hat auch nicht gehofen.

Ich habe in das Board einen neuen "Atmega328 with Arduino-Bootloader" frisch vom China-Versender eingesetzt.
Das hat geholfen.

Bei mir ist also direkt der Controller betroffen.
Irgendwas hat ihn verändert.
Keine Ahnung, wie das passieren konnte.

Ich habe auch keinen Programmer, kann also nicht sagen, ob man den Controller durch einen "Reset to Factory Defaults" oder sowas mit anschließendem Bootloader-Brennen wieder in einen einwandfreien Zustand versetzen kann.

Auf jeden Fall habe ich nun einen Controller, der sich beim Reset fehlerhaft verhält und es liegt definitiv am Controller und nicht am Board.

Und die Ursache sind meine Spielereien von gestern mit dem Versuch, Analogpins als Digitalpins zu mißbrauchen. Ob es nun die Funktionen digitalPinToBitMask() und digitalPinToPort() waren, oder doch eher die normalen Funktionen pinMode(), digitalWrite() oder digitalRead(), keine Ahnung, aber irgendwas davon hat in der von mir ausgespielten Kombination den Controller dauerhaft verändert oder beschädigt.

Ich werde den fehlerhaft arbeitenden Controller mal aufbewaren. Irgendwann schaffe ich mir bestimmt einen Programmer an und dann kann ich ja mal testen, ob man dem Controller den Fehler wieder ausbrennen kann, oder ob er den jetzt dauerhaft hat.

Blinkt Dein Bootloader überhaupt nicht?

Nein, gar keine Reaktion.

Auf jeden Fall habe ich nun einen Controller, der sich beim Reset fehlerhaft verhält und es liegt definitiv am Controller und nicht am Board.

Und die Ursache sind meine Spielereien von gestern mit dem Versuch, Analogpins als Digitalpins zu mißbrauchen. Ob es nun die Funktionen digitalPinToBitMask() und digitalPinToPort() waren, oder doch eher die normalen Funktionen pinMode(), digitalWrite() oder digitalRead(), keine Ahnung, aber irgendwas davon hat in der von mir ausgespielten Kombination den Controller dauerhaft verändert oder beschädigt.

Ich werde den fehlerhaft arbeitenden Controller mal aufbewaren. Irgendwann schaffe ich mir bestimmt einen Programmer an und dann kann ich ja mal testen, ob man dem Controller den Fehler wieder ausbrennen kann, oder ob er den jetzt dauerhaft hat.

Ich kann das eigentlich nicht glauben. OK.... du hast die Tests gemacht und da zweifel ich nicht an deinen Aussagen.


So und jetzt könnt ihr mich alle für verrückt halten:
Anderer USB-Port (zwangsweise auch anderes Kabel verwendet): -> Arduino fährt immer hoch.
Hmmm...

hk007:

Blinkt Dein Bootloader überhaupt nicht?

Nein, gar keine Reaktion.

Merkwürdig, die drei Blink-Flashs beim Start des Bootloaders macht hier sowohl der original mit dem Board gelieferte Controller als auch der "mit Bootloader" einzeln gelaufte Controller. Das müssen wohl nah verwandte Bootloader sein. Und Du hast einen anderen ohne Blinken.

hk007:
Ich kann das eigentlich nicht glauben. OK.... du hast die Tests gemacht und da zweifel ich nicht an deinen Aussagen.

Ich kann das eigentlich auch nicht glauben. Nach allem, was ich bisher gehört habe, kann man nur mit einem Programmer den Controller "verfusen" und Register dauerhaft setzen, und ansonsten wird spätestens beim stromfrei schalten alles zurückgesetzt und nicht dauerhaft gespeichert. Deshalb kann das eigentlich doch gar nicht angehen, dass am Controller irgendwas zurückbleibt, außer vielleicht "verbrannte" Ausgänge, aus denen man mit äußerer Beschaltung zu viel Strom gezogen hat, so dass der Port kaputt ist. Äußere Beschaltung hatte ich beim Experimentieren aber gar nicht dran.

hk007:
Anderer USB-Port (zwangsweise auch anderes Kabel verwendet): -> Arduino fährt immer hoch.
Hmmm...

Nach der Beschreibung hört es sich auch mehr danach an, als wenn der Windows USB-Treiber der eigentliche Verursacher ist. Dass also nicht der Controller verändert wurde, sondern irgendwas am Windows USB-Treiber, das auch nach einem Neubooten des PCs weiterhin aktiv ist.

Du hast das Treiberproblem dann umgangen, indem Du einen anderen USB-Port am PC verwendet hast. Ich habe das Treiberproblem dadurch umgangen, dass ich einen anderen Baustein mit einem möglicherwise anderen/verbesserten Bootloader reingesteckt habe.

Das müßte ich vielleicht auch nochmal probieren: Den Atmega328 mit dem problematischen Reset-Verhalten nochmal in das Board stecken, und dann das Resetverhalten

  • an einem anderen USB-Port
  • mit externer Stromversorgung
    testen. Das habe ich nämlich noch nicht gemacht.

Hi,

also das mit dem anderen USB-Port war auch nur ein Trugschluss. Das hat zwar am Anfang 10x geklappt, aber später gab es an auch an diesem Port wieder die selben Probleme.

Aber jetzt hab ich den Übeltäter definitiv: Es ist mein Eigenbau-Shield. :0 Hätt ich auch eher drauf kommen können. Die Peripherie hab ich zur Fehlersuche immer abgesteckt, aber an das Shield hab ich nie gedacht.
Wie anfangs geschrieben hab ich einen Encoder zur Eingabe des Frequenz-Sollwertes. Damit dieser sauber ausgelesen werden kann hab ich ihm eine Debounce-Schaltung spendiert. So wie in der unten stehenden Skizze, die ich im Playground gefunden habe. Hab allerdings andere Werte verwendet: jeweils 10k für die Widerstände + 3x10nF. Das Ganze an den Eingängen 2,3,4. Pin 2 und 3 für die Interrupts des Drehencoder, und 4 für den Tastknopf auf dem Encoder.
Sobald ich das Shield abnehme startet der Arduino. Ersichtlich durch das Geflackere der PIN13-LED. Mit dem Shield läuft er nur sehr selten an.
Da auf dem Shield nur die R/C-Kombination verbaut ist, kann es nur daran liegen.
Nach weiteren Test hab ich herausgefunden, dass nur die Verbindung zum PIN4 das Booten des Arduino stört. Was ist an dem so besonders? Hat die gleiche RC-Beschaltung wie PIN2+3????

Ich forsche weiter.....

debounce.JPG

Hi
8) 8) 8) 8) 8) 8) 8) 8)
So, jetzt gehts. 30 mal neu angesteckt und 30 mal hochgefahren.
8) 8) 8) 8) 8) 8) 8) 8)

Hab jetzt den PullUp der Debounce-Schaltung anPIN4 entfernt. Die Software verwendet ja sowieso den internen Pullup des µC.
Wobei jetzt nur noch die Frage offen bleibt, wieso der PullUp an PIN2 und PIN3 nicht stört....Grübel...

hk007:
Ich forsche weiter.....

Also ich habe auch nochmal den fehlerhaften Controller ins Uno-Board gesetzt:

  • anderer USB-Port am PC ==> Reset-Fehler besteht weiterhin
  • nur ans USB-Ladegerät gehängt ==> Reset-Fehler besteht weiterhin

Ich konnte andererseits feststellen, dass der Reset-Fehler abhängig vom laufenden Programm ist:

  • Sketch ist nur eine einfache Serial.print() und delay() Schleife ==> kein Reset-Fehler
  • Sketch setzt Pin13 auf Output und läßt die Pin13 LED blinken ==> Reset-Fehler!

Auf dem einen Controller resetten beide Sketche problemlos, auf dem anderen nur der eine.

Auf Wunsch kann ich die beiden kleinen Test-Sketche mal posten.