Hallo, ich habe den CAN-Bootloader von Fabian Greif auf einen ATMega328p geflasht. An dem Mega 328p ist ein MCP2515 CAN Controller angeschlossen. Der Mega328p befindet sich irgendwie immer im Bootloader-modus wenn der CAN-Bootloader per SPI geflasht wurde. Wenn ich nun das Hex-File per CAN-Bus mit dem Python-Script übertrage dann funktioniert das auch alles wunderbar. Aber anschließend blinkt die "BOOT LED" wieder in einem 0,5s takt und ich kann immer wieder neu das Programmfile x.hex per Canbus übertragen, ohne einen Reset einzuleiten. Als ob der µC immer im Bootloader modus bleibt. Kann mir jemand tips geben wo ich anfangen soll den Feghler zu suchen? Gruß Dennis
Wenn ich alles Richtig verstanden habe dann liegt der Bootloader in einem speziellen Bereich des Speichers dessen Startadresse abhängig von der Größe und der gesetzten flags ist. in diesem Beispiel: 512 Words Startadresse des Bootloaders: 0x3E00 Die Flags sind eingestellt auf: L:FF H:DC E:FD Der Bootloader scheint auch zu arbeiten denn er antwortet auf die gesendeten Packete. Woran kann es liegen das das programm nicht gestartet wird? wenn ich den µC Resette startet er auch kein Anwendungsprogramm. Gruß Dennis
g0nz00 schrieb: > Woran kann es liegen das das programm nicht gestartet wird? Die Umschaltung von Boot-Modus auf Normal in Zeile 42 ist fehlerhaft. > wenn ich den µC Resette startet er auch kein Anwendungsprogramm. Das soll er auch nicht. Nach Reset soll er brav den Bootloader starten. Denn das ist der Sinn des Bootloaders.
Laut Beschreibung von http://www.kreatives-chaos.com/artikel/can-bootloader , wartet der Bootloader 500ms auf die CAN-Message die eine Datenübertragung einleitet ansonsten startet er das Anwendungsprogramm mit einen Sprung auf Adresse Null. Ich habe im Makefile nur die Startadresse des Bootloaders angepasst da diese nicht über ein stimmte mit dem Datenblatt. MCU = atmega328p F_CPU = 16000000 BOOTLOADER_BOARD_ID = 0x01 else ifeq ($(MCU), atmega328p) BOOTSTART = 0x7C00 << hier die Änderung auf 0x3E00 http://www.atmel.com/Images/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf Seite: 343 Beim Ausführen von Make all hatte ich einen Fehler mit -msshort-calls daher habe ich diesen auskommentiert. #CFLAGS += -mshort-calls Es mussten nur noch in der default.h die Bit Timings geändert werden da der MCP an einem 8MHz Quarz läuft. // CAN Bitrate 125 kbps #define R_CNF1 (1<<BRP2)|(1<<BRP1)|(1<<BRP0) <<< hier BRP2 entfernt #define R_CNF2 (1<<BTLMODE)|(1<<PHSEG11) #define R_CNF3 (1<<PHSEG21) anschließend hat alles geklappt mit dem Bootloader und der Übertragung. Nur das Starten des Anwenderprogramms scheitert.
g0nz00 schrieb: > Ich habe im Makefile nur die Startadresse des Bootloaders angepasst da > diese nicht über ein stimmte mit dem Datenblatt. Fehler Nummer 1. Im Flash wird manchmal Wortweise gezählt, manchmal Byteweise. > Beim Ausführen von Make all hatte ich einen Fehler mit -msshort-calls > daher habe ich diesen auskommentiert. Fehler Nummer 2. Dadurch sind die Fehler verschwunden? Ein Kind hält sich die Hand vor die Augen und sagt "du kannst mich nicht sehen". > anschließend hat alles geklappt mit dem Bootloader und der Übertragung. Woraus schliesst du das? Hast du nach der Übertragung das Flash ausgelesen und auf korrekten Inhalt geprüft?
Zu Nummer 1: Boot Reset Address (Start Boot Loader Section) = 0x3E00 steht so im datenblatt und ja es wird Wordweise gezählt aber es geht doch um die Startadresse. Zu Nummer 2: Irgendwo wurde dazu geraten das man ohne diese option compilieren soll. Quelle habe ich nicht zur hand. Zu Nummer 3: Das pytonscript initialisiert den Bootloader und fängt nach der initialisierung an das programm zu übertragen und fragt immer wieder nach ob alles angekommen ist. Das funktioniert ..... ob alles an seinem platz steht habe ich nicht getestet. womit kann ich den Flash komplett auslesen?
g0nz00 schrieb: > womit kann ich den Flash komplett auslesen? Mit jedem gängigen ISP Programmierer. Wie hast du denn deinen Bootlader in den Chip geladen?
Alles klar werde das zu hause mal probieren mit dem auslesen. Mit der Adressierung des Bootloaders hast du wohl recht .... Es wird die Adresse des Bytes im Makefile angegeben und nicht des Wortes. Habe mal zum vergleich ins datenblatt vom Mega32 geguckt und auch da wird die Startadresse mit 0x3C00 angegeben. und Endadresse (0x3FFF) - Startadresse (0x3C00) sind dann 0x1FF und das dezimal sind dann 511 Worte. und im Makefile wird die Start adresse dann wohl in Byte angegeben. Also ist mein "Bootloader" ein Programm im Programmbereich des Speichers. und die Byteadressen 0x0000 bis zur 0x3BFF werden übersprungen weil sie leer sind und der "Bootloader" dann ab 0x3C00 ausgeführt und weil er mit seinen 1040Byte (0x3C00 bis 0x2008 ) in den Programmspeicher passt auch ausgeführt.
g0nz00 schrieb: > und die Byteadressen 0x0000 bis zur 0x3BFF werden übersprungen > weil sie leer sind und der "Bootloader" dann ab 0x3C00 ausgeführt Das passiert nur, wenn die Bootloader-Fuses nicht richtig gesetzt sind. Der Bootloader wird schon direkt angesprungen. Sonst könnte man den ja auch nur einmal benutzen...
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.