Hallo, zusammen, ich habe hier ein Problem, das mich langsam in den Wahnsinn treibt, vielleicht kann mir von Euch jemand zeigen, wie ich aus diesem Film herauskomme. Bin versierter Entwickler, aber das hier ist mir zuviel Neuland: Hardware: Ein Crumb 128-Board von Chip45, aufgesetzt auf ein eigenes Eva-Board, Programmer: Ein STK200 kompatibler ISP-Dongle, selbstgeschnitzt, funktioniert soweit ganz gut Entwicklungsumgebung ist die WINAVR-Suite mit AVRDude als Pgm.-Software Diverse Progrämmchen zum Betrieb von RS232, eines LC-Grafikdisplays etc. funktionieren soweit gut. Das Testsystem läuft also grundsätzlich Jetzt das Problem: Für spätere Anwendungen brauchts einen Bootloader. Um einen Einstieg ins Thema zu kriegen habe ich einen Bootloader von CHIP45.COM (ATMEGABOOT) heruntergeladen und kompiliert. Und geflasht. Und geht nicht. Warum? Makefiles sind mir noch etwas fremd, aber alle zur Kompilierung nötigen Info, Parameter und Flags sollten sich dort finden. OK, die Fuses des AVR: LFUSE = 0xFF (im wesentlichen Taktparam., geht auch gut so), HFUSE = 0x98, d. h. BOOTSZ1=BOOTSZ0=0, BOOTRST=0 -> Der Bootvektor sollte also auf 0x1E00 zeigen. Setze ich das BOOTRST-Bit probehalber auf 1 (-> HFUSE=0x98) starten Programme auch ganz normal bei 0x00000. Das Makefile enthält die Zeilen: ifeq ($(PRODUCT),CRUMB128) // OK, ist oben definiert MCU_TARGET = atmega128 // falsch, aber vorläufig OKgibts noch Probleme mit dem CAN128 #MCU_TARGET = at90can128 // noch nicht in devlist LDSECTION = --section-start=.text=0x1E000 // GENAU! Hierhin muss es ISPFUSES = avrdude -c $(ISPTOOL) -p m128 -P $(ISPPORT) $(ISPSPEED) -u -U efuse:w:0xff:m -U hfuse:w:0xc8:m -U lfuse:w:0xdf:m ISPFLASH = avrdude -c $(ISPTOOL) -p m128 -P $(ISPPORT) $(ISPSPEED) -V -U flash:w:$(PROGRAM)_$(PRODUCT)_$(BUILD).hex Ein Blick aufs Hexfile mit Galep zeigt auch einen ab 0x0000 leeren Puffer, aber Code an der richtigen Stelle: 1E000: 0C 94 46 F0 0C 94 63 F0............................... Schätze, das ist der Startup-Code. OK, um die Funktion des Bootloader-Codes mal grundsätzlich zu überprüfen, habe ich den Loader abgekürzt, und schlicht folgende Zeilen eingefügt: /* main program starts here */ int main(void) { // 'vorhandener Code..unwichtig: uint8_t ch,ch2; uint16_t w; asm volatile("nop\n\t"); /* set pin direction for bootloader pin and enable pullup */ /* for ATmega128, two pins need to be initialized */ #ifdef _AVR_ATmega128_ BL_DDR &= ~_BV(BL0); BL_DDR &= ~_BV(BL1); BL_PORT |= _BV(BL0); BL_PORT |= _BV(BL1); #else BL_DDR &= ~_BV(BL); BL_PORT |= _BV(BL); #endif //////////////////////////////////////////////////////////////////////// ///////////////////////// Hier nun mein Code, der nicht funktioniert: #define LEDRD_PORT PORTG #define LEDRD PG0 #define LEDRD_DDR DDRG #define LEDRDON LEDRD_PORT |= _BV(LEDRD) #define LEDRDOFF LEDRD_PORT &=~_BV(LEDRD) LEDRD_DDR |= LEDRD; while (1) { LEDRDON; LEDRDOFF; } Und jetzt frage ich mich, warum ich am Port G0 nichts messen kann. Der Code läuft, wenn ichs mit normalem Resetvektor 0x0000 flashe. Eine merkwürdige Sache: Der AVRDude bringt NACH der Programmierung die Meldung "avrdude.exe: 123578 bytes of flash written" 1. Warum soviele. Bootloader hat doch nur ein paar kB und sollte ab 1E000 geflasht werden? 2. Ist das normal, dass der STK200/AVRDude für 123578 Bytes 90sec(!). brauchen? 3. Wieso ausgerechnet ca 8kB weniger als ins FlashROM passt (128kB)? 4. Warum aber sinds nicht exakt 8kB (8192Byte) sondern nur 7940 Byte weniger? Liegt da der Hund begraben? Aber warum? Ich komm nicht drauf. Hab schon alle Foren etc. abgegrast.... Wer kann hier helfen? Ich danke im voraus vielmals für Tips. Grüßle Andreas Paulin
hallo, ideen jede menge, aber imo recht konfus, was so geschrieben steht. aber der reihe nach. >Setze ich das BOOTRST-Bit probehalber auf 1 (-> HFUSE=0x98) starten >Programme auch ganz normal bei 0x00000. das ist falsch ( und hoffentlich ein tippfehler). hfuse sollte dafür 0xC9 werden. >Eine merkwürdige Sache: Der AVRDude bringt NACH der Programmierung die >Meldung >"avrdude.exe: 123578 bytes of flash written" >1. Warum soviele. Bootloader hat doch nur ein paar kB und sollte ab >1E000 geflasht werden? ist bei avrdude so, da wird von 0x0000 bis zum ende geflash-ed. leider. 2. Ist das normal, dass der STK200/AVRDude für 123578 Bytes 90sec(!). brauchen? das ist normal. > 3. Wieso ausgerechnet ca 8kB weniger als ins FlashROM passt (128kB)? keine ahnung, bin grad zu faul, nachzurechnen :) 4. Warum aber sinds nicht exakt 8kB (8192Byte) sondern nur 7940 Byte weniger? möglicherweise ist der bootloader nicht größer. wie testest du den port g? bye kosmo
Hallo, Joe, danke fürs Feedback. Die Punkte: "das ist falsch ( und hoffentlich ein tippfehler)." hfuse sollte dafür 0xC9 werden." Stimmt. Tippfehler. Bit 0 Muss 1(!) sein, dann ist Reset bei 0x00000. War Tippfehler, Unterschied 0x99<->0xC9 ist unwesentlich, ist nur das JTAGEN-Bit, das hat imho nichts mit dem reset zu tun..werds aber auch mal checken. "ist bei avrdude so, da wird von 0x0000 bis zum ende geflash-ed. leider." OK, das erklärt das. Da kommt so oder so ein Zeitproblem bei der Entwicklung auf mich: zu lange Turnaround-Zeiten. Gibts eine andere Pgm-SW, die mit STK200 arbeitet und nur die zu flashenden Bereiche brennt? Sonst wird das Herumprobieren am Bootloader zur Mühsal bis unmöglich Oder würdest Du eine komplett andere Prommer/Software-Kombination empfehlen? OK, zur Sache: Den Port schaue ich mir mit dem Oszi an. Da muss sich (bei Bootloader-modus, HFUSE = 0xC8) im us-Bereich was tun. Tut sich aber nichts.........
Ich habe auch Probleme, die Fragestellung zu verstehen ;-) Das glaube ich verstanden zu haben: Target ist AT90CAN128, der aber als ATMEGA128 programmiert wird. Usercode nach 0x0000 geladen, funktioniert. Abgespeckter Bootloadercode nach 0x1E00 geladen, funktioniert nicht. Abgespeckter Bootloadercode nach 0x0000 geladen, funktioniert (BOOTRST-Bit probehalber auf 1) Funktionieren heisst LED an PORTG lässt sich toggeln. > 3. Wieso ausgerechnet ca 8kB weniger als ins FlashROM passt (128kB)? Hast du schon probiert die Boot-Fuses erst NACH dem Flashen zu setzen? Nicht dass durch die gesetzte Boot-Fuses der genau 8 KB grosse Bootloaderbereich schreibgeschützt ist... Ansonsten mach nach dem Flashen einen Memdump und schau nach, was im Bootloaderbereich drin steht.
@ Stefan: Danke Dir. Ja, das IST so durcheinander. Schlag mich nicht, wenns nachher was ganz simples war..... Joes Posting scheint mir den Grund für "8kb weniger" zu erklären: Der AvrDude flasht echt ALLES mit Nullen voll bis 0x1e000, dann den 'Loader'. Da der aber nur ein paar hundert Byte hat, siehts FAST so aus wie wenns 128kB - 8kB wären. Die Bootsize-Fuses haben damit nichts zu tun, für programmierbarkeit oder nicht sind die Lock-Fuses zuständig, und die sind alle '1' (=freier R/W-Zugriff). Oki, einen Memdump könnte ich mal machen.....NEIN, der Avrdude HAT doch schon erfolgreich verifiziert!
@ Joe: Die HFUSE sollte WIRKLICH 0xD8/0xD9 sein, nicht 0xC8, 0xC9. Der Unterschied liegt im Watchdog: Wenn diese Fuse (Bit4) als '0' programmiert wird, ist der Watchdog eingeschaltet.
Wichtige Erkentnisse: - Watchdog MUSS ausgeschaltet bleiben (HFUSE =0xD8/9) - Der Avrdude im Terminalmode MUSS mit 'quit' verlassen werden, ERST dann startet der AVR neu. Bleibt noch ein anderes Problem: Warum führt der Avrdude IMMER einen Chip erase durch? Per AvrdudeGUI lasse ich nun erst den 'Bootloader' MIT Chip-Erase (Param -e) nach 0x1e000 brennen und dann OHNE Chip-Erase die 4K Standardfirmware @0x00000. Der AvrdudeGUI schiebt zu letzterem folgende Kommandozeile raus: "E:\Programme\WinAVR\bin\avrdude.exe" -p m128 -c stk200 -C "E:\Programme\WinAVR\bin\avrdude.conf" -P lpt3 -U flash:w:"E:\CSS Projekte\RolliX\Firmware\HelloCSS\HelloCSS.hex":i -v -V -E reset,novcc Stimmt, der Parameter '-e' ist nicht da. :) Der Bootloader wird aber trotzdem gelöscht :( wie ein Memdump ab 0x1E000 zeigt (Danke, Stefan :) Warum???
warum nicht? das ist ein chip erase, da wird nun einmal alles platt gemacht (naja, fast alles). auszuschalten via -D option warum lädst du die firmware nicht über den bootloader? da solltest du das problem nicht haben. und dafür ist der auch gedacht, ist kein selbstzweck, das ding. bye kosmo
ach ja: von welcher mcu reden wir denn überhaupt? doch wohl dem mega128, oder? >Die HFUSE sollte WIRKLICH 0xD8/0xD9 sein, nicht 0xC8, 0xC9. >Der Unterschied liegt im Watchdog: Wenn diese Fuse (Bit4) als '0' >programmiert wird, ist der Watchdog eingeschaltet. man, das hättst ja mal konkret herausstellen könnnen. bin_grad_tierisch_bedient >Hardware: Ein Crumb 128-Board von Chip45, aufgesetzt auf ein eigenes was du meinst, ist ein "Crumb128-CAN" da sich diese in der hfuse unterscheiden, hat mich das erst stutzig gemacht. ja klar, watchdog aus, was'n sonst. junge junge :)
@ kosmo: Der Sinn eines Bootloaders ist mir schon klar, kosmo. Ich lade die Firmware nicht über den Bootloader, weil das schlicht nicht funktioniert. Der Bootloader ist der bei www.chip45.com herunterladbare 'ATMegaBoot'. Hierzu gibts auch Makefiles für alle Varianten der dort angebotenen Prozessormodule. Fast alle. Ich habe ein Crumb128-CAN. Für Crumb128-CAN gibts da noch GARNICHTS. Also behelfe ich mir mit Code für den ähnlichsten Controller. Den 'Crumb128'. Es passt aber keins der Makefiles so richtig, weil nirgends die Konstante F_CPU auf 16000000 steht: Es sind Makefiles für den CRUMB128 mit 14.75 MHz und 20.0MHz vorhanden, aber keines für einen CRUMB128-CAN mit 16MHz. Davon hängt aber wiederum die Baudrate der ser. Schnittstelle ab. Und darüber soll ja die Software geladen werden. Also: Falsche Taktangabe bei Compilierrung macht download unmöglich. ergo: Rein ins Getümmel und die Sache ändern. Und wenns dann nicht läuft speckt man normalerweise den Code auf rudimentäre Reste ab und geht zurück zur Badstraße......... Im zugehörigen Makefile werden übrigens auch auch die Fuses (hier: HFUSE)definiert. Siehe oben. Genauso, wie Du oben vorgeschlagen hast: 0xC8 Soweit sind Dr. Lins und Du also einer Meinung im Bit#4 Was den ATMEGA128 betrifft, voll OK. Was leider für meinen Fall anders ist: Das Bit #4 der HFUSE ist beim ATMega128 die 'CKOPT', bei meinem AT90CAN128 aber das 'WDTEN'-Bit. Da läuft bei mir also der Watchdog......... Ergo: ATMega128 und AVR90CAN128 haben unterschiedliche HFUSEs. In EINEM Bit unterschiedlich. Eben im Datasheet gesehen. Und ich renne voll ins Messer. Thanks a lot. Ich tret dem blöden Lins die Eier blau. Ich hab das Crumb128CAN gekauft um nen leichten Einstieg zu kriegen, und nicht in Makefiles zu stochern! OK, jedenfalls 1 Schritt weiter......... Aber zum Avrdude. Du schreibst: "warum nicht? das ist ein chip erase, da wird nun einmal alles platt gemacht (naja, fast alles). auszuschalten via -D option" Weil ich die Option "-e: perform a chip erase" ausgeschaltet hatte. Deshalb sollte er keinen chip erase durchführen. Das war meine Frage. Aber Du sagst da was Gutes: '-D' gibts auch noch. Ich war hier auf die Option '-e' fixiert. Wieder ein Schritt....... wichtig für später....... Jetzt nehme ich mal alle erkentnisse zusammen, und schau, obs nicht langsam klappt. Bleiben Sie dran ;-)
nimm doch den hier, sonst wirst du ja nie fertig :) http://www.siwawi.arubi.uni-kl.de/avr_projects/#avrprog_boot der geht. muss man auch ein bichen frickeln, aber nur ganz kurz. oder ich schicke dir gleich nen bl für CAN. bye kosmo
OK, Kosmo, danke für den Tip, hab die 0.81 mal runtergelden, und werde
gleich die Fuses mal checken.....
Aaaaaaaaaaaaber:
Grundsätzlich möchte ich schon aus eigener Kraft ein Winzprogramm
hinkriegen, das es schafft
- mittels Bootvektor auf 0x1E000
- nach einem Reset
- den dort vorhandenen Code auszuführen.
Und der geht mittlererweile so:
DDRD |= 0x40;
while (1)
{
PORTD |=0x40;
PORTD &=~0x40;
}
SOWEIT möchte ich als Entwickler die Maschine schon in den Griff
kriegen.
Wenn DAS dann mal grundsätzlich läuft ists ok, dann werde ich klar den
vorhandenen Bootloader verwenden. Den Teufel werde ich die ganzen
Flash-Algorithmen neu erfinden, das braucht ja ewig ;-)
Aber erstmal müssen die wesentlichen Grundlagen stimmen.
also... soll heißen: Da muss irgendwann mal am Port D6 was zucken, ne?!
Du hast bereits sichergestellt, dass dein main() Code grundsätzlich lauffähig ist (Test als Programm ab 0x0000 - LED blinkt). Du hast bereits sichergestellt, dass dein Programm von AVRDUDE in den Bootloaderbereich geflasht wird (Memdump). Du musst jetzt kontrollieren, ob das Bootloader-Programm auch in dem Bootloaderbereih lauffähig ist. D.h. ob dein bewusst geschriebener Code (main()) und der dazugebundene Code (C Startupcode) von der Toolchain korrekt für die Adresse 0x1E00 übersetzt sind. Dafür würde ich Option der Toolchain benutzen, die mir ein ASM-Listing (*.LSS) erzeugt. Dieses Listing würde ich dann mit dem Datenblatt "8-bit Microcontroller with 32K/64K/128K Bytes of ISP Flash and CAN Controller - AT90CAN32 AT90CAN64 AT90CAN128" und dem Bereich über den Bootloader (S. 61ff und 320ff) vergleichen.
Hi, Stefan, danke für den Tip. Die Listings enden aber mit *.LST ;-) Egal, ich habs gefunden: Ich hab das Listing mal komplett angehängt. Bin kein Assemblerkenner, aber ich sehe da ein Programm, das bei 0x1E000 anfängt, eine Vektortabelle, irgendwelches Startupzeugs, einen Sprung mach main... und dann: 0001e278 <main>: 1e278: cf ef ldi r28, 0xFF ; 255 1e27a: d0 e1 ldi r29, 0x10 ; 16 1e27c: de bf out 0x3e, r29 ; 62 1e27e: cd bf out 0x3d, r28 ; 61 1e280: 00 00 nop Das hier ist wohl mein Code: 1e282: 8e 9a sbi 0x11, 6 ; 17 1e284: 96 9a sbi 0x12, 6 ; 18 1e286: 96 98 cbi 0x12, 6 ; 18 1e288: 96 9a sbi 0x12, 6 ; 18 1e28a: 96 98 cbi 0x12, 6 ; 18 1e28c: fb cf rjmp .-10 ; 0x1e284 <main+0xc> OK, da werden Bits in den IO-Adressen 0x11 und 0x12 gesetzt und gelöscht. ???????? HÄ??? Laut Datasheet AT90CAN128, IOMemory: 0x11: PORTF 0x12: PING Mein Source MEINTE aber PORTD, bzw. DDRD. Sollte da etwa.... Blick ins ATMEGA128-Datasheet, IO-Memory:: 0x11: DDRD 0x12: PORTD So. Danke. Das wars. Mein Standardprogram@0x00000 hat schon die AT90CAN128-Header eingebunden, den Bootloader von Chip45 habe ich mit 'ATMEAG128-Option kompiliert, weils für das Crumb128-CAN von Chip45.com gar keinen expliziten Bootloader gibt. Und für mich als AVR-Newbie der ATMEGA128 sehr ähnlich dem AT90CAN128 schien. Und als AVR-Newbie portier ich halt nicht mal kurz den ganzen Bootloader auf einen anderen Controller, ne?! Fazit: Den ganzen Code für das Crumb128-Modul kann sich der Herr Dr. Lins in seinen Doktorarsch schieben, weil das ganze Zeug nicht für sein CRUMB128-CAN-Modul taugt!! Die zwei Controller unterscheiden sich GRAVIEREND! Muss man wissen, ich komme aus dem PIC-Lager, da sind alle SFR-Adressen ungefähr gleich............... Danke, Stefan, danke, Kosmo, schätze jetzt komme ich weiter. Und jetzt mache ich mit dem Bootloader von Martin Thomas weiter, der Lins hat verschissen!
tut mir leid, aber mit deinem ton hast du dich grade rausgekickt :( wenn du im makefile nicht siehst, dass das für den mega128 gemacht ist: selber schuld.
1 | MCU_TARGET = atmega128 |
2 | |
3 | override CFLAGS = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) -D$(PRODUCT) -D$(AVR_FREQ) $(DEFS) |
4 | |
5 | $(PROGRAM).elf: $(OBJ) |
6 | $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS) |
sicher steht auf der website, dass der bootloader auch für den at90can128 gemacht ist. dann aber bitte gehirn einschalten, das ändern und bei chip45.com bescheid geben, damit andere nicht auch da rein stolpern. bye kosmo
@ kosmo: Dochdoch, Kosmo, der Ton ist berechtigt. Aber voll. Du hast keine Ahnung, wie lange ich an dem Thema schon rumnage......... Schließlich haben wir die zwei Crumbs ja bestellt, um uns den Einstig ins Thema einfacher zu machen. Um Softwareunterstützung zu erhalten, um schneller mit diesem neuen Controller starten zu können ;-) Das Resultat war ne kleinere Doktorarbeit. Als Anfänger........... Das MCU_TARGET im Makefile habe ich schon gesehen. Es gab aber keine Alternative, also habe ich das genommen, was meinem Crumb am ähnlichsten schien: Crumb128 statt Crumb128CAN. Die Ähnlichkeit ist frappierend, ne?! Und wenns keine andere Firmwarevariante vom Hersteller für mein Produkt gibt, gehe ich mal davon aus, dass das schon passen wird. Wie gesagt: JETZT weiß ich, dass auch ähnlich erscheinende AVR gravierende Unterschiede, auch in der SFR-Belegung, haben. Aber dem Lins mal Bescheid sagen, das werde ich ;-)
das eine ist ein mega, das andere nicht. probier doch mal aus, das makefile um den at90 zu erweitern. ist ja nicht so schwer.
kriegst noch futter: AVR096: Migrating from ATmega128 to AT90CAN128 http://www.atmel.com/dyn/resources/prod_documents/doc4313.pdf
@kosmo: Danke. Guter Background Naja, das Material von Chip45 ist auch nicht sooo schlecht. Ohne diese Zusammenstellung von Software hätts noch länger gedauert. Das meiste IST ja auch für alle Produktvarianten brauchbar. Ich hab mir nur prompt den Bootloader rausgesucht, der nicht für den AT90CAN128 angepasst hat und bin halt in die Falle gelaufen.......... mit ner neuen uC-Familie im Gepäck, IDE-verwöhnt in der Kommandozeilen-Welt unterwegs, Makefiles und CFLAGS... gg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.