Flip - wie benutzen?

[H.Joachim S. (crazyhorse)]

ATMega32U4, entsprechende Software für Flip ist im Bootbereich geflasht.
Setze ich den reset-Vektor dahin, klappt das auch, ebenso via HWBE. Chip 
wird erkannt, lässt sich problemlos programmieren, in der 
Systemsteuerung steht er als Atmel USB Device drin.

Ich möchte das aber aus der Anwendung (usb cdc) heraus benutzen:

27.5.1   Regular Application Conditions
A jump or call from the application program. This may be
 initiated by a trigger such as a command received via
USART, SPI, or USB.

Erstmal die Holzhammermethode versucht:

case 'b': USBCON=0;      //disable USB
          delay_ms (100);
          #asm ("jmp 0x3800")  //bootladeradresse
          break;

Nicht schön, hätte aber eigentlich erstmal funktionieren müssen??
USB CDC verschwindet in der Systemsteuerung, und es erscheint unknown 
device
Wie ist die korrekte Vorgehensweise?

[H.Joachim S. (crazyhorse)]

Hm, noch keiner den flip-Bootlader aus der Applikation gestartet?

nach
// USB Controller initialization in device mode
// Note: This function also initializes the PLL
usb_init_device(&usb_config);
(was da genau passiert, weiss ich nicht, fertige lib, CodeVision)

funktioniert der Bootlader nicht korrekt.
Noch ein Holzhammer, mit watchdog-reset:

 if (MCUSR & (1<<WDRF))  // Watchdog Reset
   {
   MCUSR=0;
   #asm ("jmp 0x3800")
   }

das funktioniert, aber das kann ja nicht die Lösung sein. Ausserdem 
brauche ich den watchdog für seinen eigentlichen Zweck...

Bin etwas ratlos. Habe auch schon alle USB-Register auf reset-Werte 
gesetzt, ändert nichts. Werde noch mal nach der PLL schauen, vielleicht 
liegt da der Hund begraben.

Blöd, wenn man 2 blackboxes verheiraten soll...

[Kirsch (Gast)]

Was willst du jetzt genau?

Willst du in deiner Anwendung ein USB-CDC haben, ja dann musst du das 
auch selber Programmieren, gibt im Netz ein paar libs dafür.

Bootloader und deine Anwendung sind dann zwei eigenständige Programme 
auf dem AVR, der HWBE entscheidet welches davon gestartet hat. Wenn der 
Bootloader gestartet ist, meldet er sich als USB-Devise am PC, weil er 
dafür so programmiert wurde.

[H.Joachim S. (crazyhorse)]

Normalerweise läuft USB-CDC, funktioniert auch.
Bootlader für sich funktioniert auch, per HWBE.

Ich möchte aber im laufenden Betrieb per Kommando via CDC den Bootlader 
starten, um ein update durchführen zu können. Eine manuelle 
Bedienmöglichkeit gibt es nicht.

[Kirsch (Gast)]

Das Problem ist, bei einem Reset ist der Bootloader das erste was 
startet,

der Bootloader fragt dann den HWBE ab, ist der nicht aktiv startet er 
das Hauptprogramm. Du must aus deinem Programm den HWBE irgendwie 
schalten, z.B. eiern Kondensator laden der ihn kurzzeitig aktiv lässt.

Wenn möglich, schau dir den Quellcode (oder das ASM-Listing) vom 
Bootloader an, eventuell gibt es noch andere Abfragen.
Ich hab schon gesehen, das mansche Bootloader ein Flag Abfragen wenn die 
Resetquelle der Watchdog war.

[H.Joachim S. (crazyhorse)]

http://www.atmel.com/Images/doc7618.pdf

figure 3.1
software activation <- das will ich

Wenn ich einfach schreibe

void main (void)
  {
    #asm ("jmp 0x3800")
  .
  .
  }

klappt das auch prima, Atmel USB Device -> ATMega32U4 erscheint in der 
Systemsteuerung, und ich kann mit Flip auf das Teil zugreifen.

Genau das funktioniert aber nicht, wenn vorher schon USB_CDC lief.
Das muss sich doch per Software in einen Zustand versetzen lassen, dass 
das bootprogramm (ATMega32U4-usbdevice_dfu-1_0_0.hex) damit klarkommt 
:-(

Fehlerhaftes USB-Gerät...

[Sebastian V. (sebi_s)]

Schonmal versucht das CDC Device zu deinitialisieren bevor du den 
Bootloader anspringst? Scheint mir so als ob der Bootloader davon 
ausgeht das einige USB Register ihren Default Wert haben. Wenn vorher 
CDC lief trifft das aber nicht mehr zu und irgendwas geht schief.

[H.Joachim S. (crazyhorse)]

Du hast mein Anliegen auf den Punkt gebracht :-), aber wie?

•   Bit 7 – USBE: USB macro Enable Bit
Set to enable the USB controller. Clear to disable and re
set the USB controller, to disable the USB transceiver
and to disable the USB controller clock inputs.

Sollte meiner Meinung nach ausreichen, tut es aber nicht.

[Dennis X. (Gast)]

Hatte letzte Woche das exakt gleiche Problem. Über eine Lösung wäre ich 
auch sehr glücklich. Ich vermute aber auch dass es mit den Standard 
Register Werten zusammenhängt. Hatte das nicht weiter verfolgt und über 
den watchdog gelöst.

[Simon B. (nomis)]

Wichtig: Timer-Interrupts ausschalten.

Ich verwende zusammen mit der LUFA-Library folgenden Code um den 
Bootloader anzuspringen:

              /* jump into the boot loader */
              USB_Detach ();
              _delay_ms (200);
              USB_Disable ();
              _delay_ms (200);
              TIMSK0 = 0x00;
              TIMSK1 = 0x00;
              UCSR1B = 0x00;
              cli ();
              __asm__ ("jmp 0x7000;");

Wobei das für einen at90usb162 ist und mich jetzt im Nachhinein die 
Zieladresse irritiert. Eigentlich müsste die 0x3800 von Dir korrekt 
sein.
Ich kann das leider im Moment nicht gegenchecken. Aber vielleicht ist ja 
schon der Rest ein Hinweis der Dir weiterhilft.

Viele Grüße,
        Simon

[H.Joachim S. (crazyhorse)]

Das beruhigt mich in gewisser Weise...

Eigentlich müsste ja der Bootlader, wenn er als aus der Applikation 
heraus aufrufbar angeboten wird, mit jedem beliebigem vorgefundenen 
Prozessor-Zustand klarkommen. Und da er ja auch auf nichts Rücksicht 
nehmen muss, scheint mir das nicht sehr schwer. Alternativ zumindest 
irgendwo erwähnen, was vorausgesetzt wird? Hardware-reset-Zustand kann 
ja wohl nicht die Lösung sein.

Hilfskrücke jetzt: will ich in den bootlader, schreibe ich was in eine 
eeprom-Zelle und lass den WD auslösen.
Nach reset wird geprüft, was die reset-quelle war.
watchdog + eeprom==0x55 -> eeprom wieder löschen, bootlader
watchdog + eeprom==0xff -> normaler watchdog-reset.

[Simon B. (nomis)]

H.Joachim S. schrieb:
> Eigentlich müsste ja der Bootlader, wenn er als aus der Applikation
> heraus aufrufbar angeboten wird, mit jedem beliebigem vorgefundenen
> Prozessor-Zustand klarkommen.

Ich weiß dass ich irgendwann mal explizit über die Timer-interrupts 
gestolpert bin, insofern hat da Atmel anscheinend keine Rücksicht drauf 
genommen...

Unabhängig davon kann es sich auf jeden Fall lohnen, vor einem Sprung in 
den Bootloader die USB-Verbindung geordnet zu schließen, ansonsten 
kriegt man auf der USB-Host-Seite sehr seltsame Effekte, 
re-enumerationen die nicht gut klappen, timeouts etc.

Viele Grüße,
        Simon

[H.Joachim S. (crazyhorse)]

Danke, das könnte ein Ansatz sein.
Ein nacktes "cli" allein hilft schon mal nichts (müsste aber, wenn 
Timerinterrupts das Problem wären?)

Werde jetzt mal alles stilllegen, was in die Quere kommen könnte. Sind 
noch ein paar mehr Interrupts im System.

[H.Joachim S. (crazyhorse)]

@Simon: beim USB162 müsste es eigentlich 0x1800 sein.

Ebenso wie beim 16U4 :-)

Jetzt bin ich trotzdem unsicher - wird bei jmp die Byte- oder die 
wordadresse angegeben? Lange nichts mit Assembler gemacht :-(

[H.Joachim S. (crazyhorse)]

Jippi, Simon, das wars :-)

habe jetzt alle benutzten Ints ausgeschaltet. Keine Ahnung, ob 
tatsächlich alle ein Problem sein könnten. Interessiert mich jetzt nicht 
wirklich.

case 'b':  USBCON=0;      //disable USB
           TIMSK0=0;
           TIMSK1=0;
           TIMSK3=0;
           TIMSK4=0;
           EIMSK=0;
           PCMSK0=0;
           UCSR1B=0;
           #asm ("cli")
           //StartBoot_ee=0x55;
           //while (1);  //wait for watchdog
           delay_ms (200);
           #asm ("jmp 0x3800")
           break;


Ein klitzekleiner Hinweis in der Flip-Beschreibung hätte mir etliche 
Stunden Frust erspart :-(.
Nun noch Flip als batch aufrufen, dann ist der Kram erledigt.

[H.Joachim S. (crazyhorse)]

Da die DFU-Software nur als hex-file vorliegt
http://www.atmel.com/Images/megaUSB_DFU_Bootloaders.zip
und ich am liebsten nach dem Compilieren direkt brenne, wird jedesmal 
der Bootlader gelöscht, lästig. Und via bootloader geht auch nicht ohne 
Umwege
Vielleicht kann man auch automatisch mehrere Hex-files brennen oder 
vorher zusammenbasteln, weiss ich nicht. Ich habs jetzt so gelöst:

#asm
       .cseg
       .equ boot_adr=0x3800
       .equ oldpc=pc
       .org boot_adr-2
_version:
       .db  4,3,2,1
       .org boot_adr
       .include "ATMega32U4-usbdevice_dfu-1_0_0.asm"
       .org oldpc
#endasm

extern flash unsigned char version[4];

und wird damit direkt ins hex-file eingebunden
Vielleicht kann es ja einer brauchen.