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?
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...
Gast
#4299471
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.
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.
Gast
#4299577
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.
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...
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.
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.
Gast
#4299757
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.
Wichtig: Timer-Interrupts ausschalten. Ich verwende zusammen mit der LUFA-Library folgenden Code um den Bootloader anzuspringen:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
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
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.
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
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.
@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 :-(
Angehängte Dateien:
-
USB_boot.PNG
(71 KB)
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.
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.