ATmega32U2 geht manchmal "einfach so" in USB-Bootloader Modus

[ebtschi (Gast)]

Hallo,

mein ATmega32U2 tut die meiste Zeit das was er soll, allerdings geht er 
manchmal gleich nach dem Start "einfach so" in den USB-Bootloader Modus 
anstatt die Anwendung auszuführen.

Der ATmega wird von einem MSP430 auf dem selben Board resettet. Beim 
Reset ist PD7 high (wird vorher auf high gesetzt + kurze Wartezeit). Der 
USB-Bootloader startet immer genau wie er soll wenn beim Reset PD7 low 
ist.

PDI, PDO, SCK hängen in der Luft (passt doch so, oder?).

Hat jemand Ideen woran das liegen könnte? In der Anwendung wird USB 
gleich am Anfang deaktiviert.

Danke im Voraus!

[Nils S. (kruemeltee)]

Pullup am Reset?

[ebtschi (Gast)]

Wow, 1 Minute Reaktionszeit! :D

Der Reset-Pin wird vom MSP430 immer auf high gehalten (ausser am Anfang, 
wo der MSP den Atmega 1x "kontrolliert" resettet).

[Wolfgang H. (Gast)]

Hi, ebtschi,

> Hat jemand Ideen woran das liegen könnte?

Wo immer ich mir meinen Kopf ähnlich zerbrochen habe, war denn doch noch 
irgendwo ein Interrupt, der nicht hätte sein dürfen.

Ciao
Wolfgang Horn

[ebtschi (Gast)]

Wolfgang Horn schrieb:
> Wo immer ich mir meinen Kopf ähnlich zerbrochen habe, war denn doch noch
> irgendwo ein Interrupt, der nicht hätte sein dürfen.

Der einzige Interrupt der verwendet wird ist UART RX und TX. Der 
ISR-Code ist relativ kompakt und simpel, und ruft keine anderen 
Funktionen auf etc.

[Nils S. (kruemeltee)]

>Der Reset-Pin wird vom MSP430 immer auf high gehalten (ausser am Anfang,
>wo der MSP den Atmega 1x "kontrolliert" resettet).

Bist du dir da sicher? Machst du zusammen den Reset?

Auch wenn du das 100%ig verneinen kannst, ein 4k7...10k  Pullup schadet 
nicht und kostet so gut wie nichts ;).

Wenn der MSP430 Reset macht und dabei den 32u2 in den Bootloadermode 
schickt...

Du könntest zum Überprüfen auch ein Rechteck vom 32u2 Ausgeben lassen, 
wenn das am MSP430 nicht ankommt -> Reset.

[ebtschi (Gast)]

Danke für die Tipps.

Nils S. schrieb:
> Du könntest zum Überprüfen auch ein Rechteck vom 32u2 Ausgeben lassen,
> wenn das am MSP430 nicht ankommt -> Reset.

Ich habe jetzt genau das versucht. Irgendwie bleibt das Teil immer noch 
im Flash-Mode, und wird erst dann wieder "normal" wenn man die 
Versorgung komplett weggenommen hat.

Das kann doch eigentlich nicht sein, oder?

[ebtschi (Gast)]

Es scheint als ob ein über UART angeschlossenes Gerät auch im 
abgeschalteten Zustand über UART Energie liefert.

Ich habe es jetzt so aufgebaut, und es scheint zu tun:

RX -----[  1k  ]-----+------- Stecker/Buchse -------+-----[  1k 
]------- TX
                     |                              |
                   -----                          -----
                1n -----                       1n -----
                     |                              |
                    GND                            GND

UART-Pegel ist 3.3V. Übertragung läuft mit 4800 Baud, 8o1.

Kann es durch die beiden zusätzlichen 1k Widerstände (vllt in 
Kombination mit den Kondensatoren) zu irgendwelchen Problemen kommen?

[ebtschi (Gast)]

Irgendwelche Ideen? :)

[Ewald K. (ebtschi)]

Update:

Manchmal (vllt 1x von 100) geht der ATMega direkt nach dem Start in den 
Bootloader-Modus. Der Modus wird normalerweise gestartet wenn PD7 
während einem Reset auf low ist (was auch funktioniert).

Um externe Fehlerquellen auf ein Minimum zu reduzieren habe ich PD7 erst 
komplett abgetrennt, und später auf +3.3V gelegt. Beides hat nichts 
gebracht.

Der ATMega hängt hinter einem TUSB2046b Hub. Die D+/D- Leitungen teilt 
er sich mit einem FT232. Es ist immer nur einer der beiden Chips aktiv, 
der andere ist im Reset.

Gibt es irgendwelche "alternativen" Möglichkeiten, den ATMega32U2 in den 
Bootloader-Modus zu befördern? Kann es sein dass ich versehentlich eine 
dieser Möglichkeiten auslöse?

[Wolfgang H. (Gast)]

Hi, Ewald,

Das GICR, General Interrupt Control Register bestimmt mit IVSEL 
(Interrupt Vector Select), welche Tabelle Interruptvektoren gilt.
Ein Atmega mit Anwendungsprogramm und Bootloader startet grundsätzlich 
im Bootloadermodus. Immer. Ohne Ausnahme.

Das wundert mich an Deiner Beschreibung.
Denn der Bootloader testet eine Bedingung, ob er dann mit dem 
Anwendungsprogramm fortfährt oder dessen neue Variante brennt.

Wenn Dein Prozessor im Bootloader fehlerhaft stecken bleibt, dann ist 
der Fehler im Bootloader zu finden einschließlich Ansteuerung der 
Bedingung.

Ciao
Wolfgang Horn

[Ewald K. (ebtschi)]

Hallo Wolfgang,

Wolfgang Horn schrieb:
> Denn der Bootloader testet eine Bedingung, ob er dann mit dem
> Anwendungsprogramm fortfährt oder dessen neue Variante brennt.

So war's gemeint. Der Bootloader startet das Anwendungsprogramm nicht.
Es wird der Standard-Bootloader von Atmel verwendet. Ich nehme stark an 
dass ich den irgendwie falsch ansteuere.

[Wolfgang H. (Gast)]

Hi, Ewald, hi, Kollegen,

gibt's mittlerweile eine Debug-Möglichkeit für Bootloader?

Ich habe meinen mal als Anwendungsprogramm umgeschrieben, die 
Brennsequenz auskommentiert - und das brachte ein wenig.

Ciao
Wolfgang Horn