KNX @ Arduino Pro Mini: WDT Problem

[tuxedo]

Hey ihr da draußen,

wir sind vermutlich gestern auf ein kleines Problem gestoßen: Unser "über den Bus programmierbarer KNX Stack" startet am ende der Parametrisierung den Arduino neu um die geänderten Einstellungen sauber anzuwenden.

Dies wird über den Watchdog-Timer gemacht:

    #include <avr/wdt.h>
.....
    wdt_enable( WDTO_1S );
    while(1) {}

Der Leonardo oder Micro kommt damit prima zurecht. Der Pro Mini landet damit in einer Endlos-Bootschleife.

Mag das jemand mit seinen Pro Mini's mal gegentesten?

Soweit ich das recherchiert habe liegt das Problem im Bootloader (https://andreasrohner.at/posts/Elect...he-bootloader/). Ein wechsel auf den optiboot Bootloader soll das Problem angeblich lösen (Test steht noch aus...).

Je nach Arduino (Original, Clone, ...) scheint es unterschiedliche Bootloader zu geben die per Default auf die Boards geschrieben wurden. Wäre interessant zu erfahren wie sich eure Pro Minis mit dem oben gezeigten Code-Snippet verhalten, und was für ein Pro Mini es genau ist (Lieferquelle?!).

Es gibt zwar noch andere Reset-Varianten, aber es herrscht im Netz die einhellige Meinung, dass ein Reboot per WDT die einzig empfehlenswerte Lösung ist. Und wir würden aber nur ungern für alle ProMini's einen anderen Bootloader voraussetzen wollen.

Also, mal fleißig testen, dann sehen wir wie "tragisch" das ganze ist. Notfalls müssen wir die Reset-Strategie etwas überarbeiten.

[Eugenius]

Hi,

ich kann gerne testen. Ich habe noch 3,3V Pro Minis (angeblich von Sparkfun), gekauft hier:
http://www.banggood.com/3Pcs-3_3V-8M...-p-980290.html


Reichen da die 3 Zeilen zum Test oder muss da noch was her? z.B. LED am PIN13 auf HIGH?
Ich kann noch Original MEGA und clone Uno testen.

[tuxedo]

Ich schau mal dass ich einen fertigen Beispiel-Sketch zum reproduzieren bastel.

[tuxedo]

Das hier müsste den Fehler reproduzieren:

#include <avr/wdt.h>

// onboard LED
#define LED 13

int i = 0;

void setup() {
  pinMode(LED, OUTPUT);
  Serial.begin(9600);  
  Serial.println("BOOT!");
}

void loop() {
  
  digitalWrite(LED, HIGH);
  Serial.println("High");
  
  delay(500);
  
  digitalWrite(LED, LOW);
  Serial.println("Low");

  delay(500);
  i++;

  if (i==5) {
    wdt_enable(WDTO_1S);
    while(1){
      // do nothing but eating cpu cycles --> cause arduino to reboot after 1sec
    }
  }
  
}

Wenn man die seriellen Monitor während der Ausführung offen hat, müsste man folgendes sehen:

BOOT!
High
Low
High
Low
High
Low
High
Low
High
Low

Die LED auf dem Board bzw. PIN13 leuchtet passend zur Low/High Ausgabe.

Und dann bin ich mir nicht sicher. Entweder es folgt gar nix mehr, oder in einer Endlosschleife "BOOT!".

Der "Fehlerfrei-Fall" würde so aussehen:

BOOT!
High
Low
High
Low
High
Low
High
Low
High
Low
BOOT!
High
Low
High
Low
High
Low
High
Low
High
Low
BOOT!
High
Low
High
Low
High
Low
High
Low
High
Low
......

Den Sketch hab ich selbst noch nicht getestet, hab ihn nur kurz zur Demonstration zusammengezimmert.

[tuxedo]

Ach ja, gerne darfst du, wenn du den Fehler reproduzieren kannst, auch mal den anderen Bootloader testen, der im Link aus dem ersten Post genannt wird...

[tuxedo]

So, eben mit einem Nano getestet:

Bei mir meldet er:

BOOT!
High
BOOT!
High
BOOT!
High
BOOT!
High



Also auch endlosschleife. Er schafft es noch bis zur Ersten Ausgabe, und dann schlägt der eigentlich noch nicht aktive Watchdog zu. Sieht man auch schön an der LED. Erst blinkt sie im 1/2 sek takt, dann nach einer kurzen Zeit geht sie in schnelles aufblitzen über.

Ich probier das mal mit dem anderen Bootloader.

[tuxedo]

Scheint so auf Anhieb auch keine Hilfe zu sein... Der Test-Sketch funktioniert mit dem Leonardo oder Micro prima. Der Nano, der eigentlich identisch zum ProMini ist, weigert sich mit obigen Verhalten.

Das Witzige ist ja, dass er noch "BOOT!" ausgeben kann, aber ein vor die ausgabe gestelltes wdt_disable() irgendwie ignoriert und trotzdem den watchdog benutzt.

[Eugenius]

Ich kann leider den Fehler mit meinen Pro minis (5V clone und 3,3V Sparkfun) reproduzieren
Ich bekomme das in der Konsole:
BOOT!
High
Low
High
Low
High
Low
High
Low
High
Low

Danach keine Verbindung mehr... LED blinkt sehr schnell, als ob Pro mini ich immer wieder neu startet
Nicht mal RESET-Button hilft. Man muss schon vom Strom nehmen um neu zu starten...

MEGA2560 und Uno (Clone)gehen. D.h. ich bekomme mehrmals "BOOT! High Low High Low..."


Optiboot muss ich noch testen... Ich kann gerade nicht flashen

[junibart]

Hallo,
hab es mit einem ProMini (3,3V, 8MHz, angeblich Sparkfun, aber ziemlich billig bei ebay geschossen) versucht. Es tritt genau das erwartete Fehlverhalten auf: Erst ruhiges, dann sehr schnelles Blinken.
Leider hilft auch Optiboot nicht weiter- der Bootloader lässt sich bei mir zwar nach der Anleitung aus dem ersten Beitrag mit meinem USBAsp installieren, das Hochladen des Test-Sketches läuft dann aber in einen Timeout. Da werde ich aber nochmal auf Fehlersuche gehen.

Grüße,
Gunnar

[Eugenius]

Leider hilft auch Optiboot nicht weiter- der Bootloader lässt sich bei mir zwar nach der Anleitung aus dem ersten Beitrag mit meinem USBAsp installieren, das Hochladen des Test-Sketches läuft dann aber in einen Timeout.

Selbes Problem habe ich auch...liegt wohl am Optiboot. Da muss man ne andere Version probieren

[Eugenius]

Optiboot schein nicht die richtige Lösung zu sein...
Ich habe wohl mehrmals meine minis zerschoßen. Egal mit welchen Einstellungen ich Optiboot flashe... nur 3 Mal blinken und das war's.
Ich habe sogar versucht auf die 5V Version Optiboot von Uno (was mit Arduino IDE ausgeliefert wird) zu flaschen... Danach kann man keine Sketsches mehr hochladen.


Und dann hat es doch geklappt (Nach dem ich eigene Einträge in boards.txt gemacht habe)

So, Ergebnis: 3,3V Pro Mini mit Optiboot und Sketch von tuxedo läuft wie geschmiert

[Eugenius]

Das in die c:\Program Files (x86)\Arduino\hardware\arduino\avr\boards.txt Datei einfügen.

##############################################################
## Optiboot on 32pin (SMT) CPUs (Nano, Pro Micro, etc.)
##############################################################

optiboot32.name=Optiboot on 32-pin cpus (3.3V Pro Mini)
optiboot32.upload.tool=arduino:avrdude
optiboot32.upload.protocol=arduino
optiboot32.bootloader.tool=arduino:avrdude
optiboot32.bootloader.low_fuses=0xF7
optiboot32.bootloader.unlock_bits=0x2F
optiboot32.bootloader.lock_bits=0x0F
optiboot32.build.f_cpu=8000000L
optiboot32.bootloader.low_fuses=0xE2
optiboot32.upload.speed=57600
optiboot32.build.board=AVR_UNO
optiboot32.build.core=arduino:arduino
optiboot32.build.variant=arduino:eightanaloginputs
optiboot32.upload.maximum_size=32256
optiboot32.upload.maximum_data_size=2048
optiboot32.bootloader.high_fuses=0xDE
optiboot32.bootloader.extended_fuses=0x05
optiboot32.bootloader.file=optiboot/optiboot_atmega328.hex
optiboot32.build.mcu=atmega328p

Das ist übrigens Standard-Optiboot-Bootloader aus Arduino IDE für UNO.

Kann das bitte noch jemand testen? (Ich habe UNO als Flasher missbraucht)

[Masifi]

Super Eugenius wenn das jetzt so klappt :-)

Was hast du denn genau verändert ?!

[tuxedo]

Er hat den gezeigten Abschnitt in besagte Datei eingefügt.
WIE das aber nun das Problem löst, hat sich mir noch nicht erschlossen.

@Eugenius
Wie bist du auf diese Lösung gekommen? Netzfund? Stand da noch mehr an Hintergrundwissen dabei?

[Eugenius]

Ich habe zuerst Optiboot vom github genommen. Da hatte ich nur Probleme: IDE Abstürze, Bootloops usw.
Dann habe ich boards-1.6.txt vom optiboot github genommen und daraus mir die Einträge zusammen kopiert, dabei aber alle menüs gelöscht.
So entstand der o.g. Code. In dem Code steht aber, dass mini dann mit internen 8Mhz arbeitet. Und nur im nahinein habe ich festgestellt, dass es Uno-Bootloader mit halber Geschwindigkeit ist.
Dass Min pro=Uno ist klar, da selber uC. Steht auch auf der im ersten Beitrag verlinkten Seite.