Forum: Mikrocontroller und Digitale Elektronik Attiny85 Bootloader Reset Vector geht nicht


von ChrisMicro (Gast)


Lesenswert?

Im Moment versuche ich gerade einen Bootloader für einen Attiny85 zu 
erstellen.

Hier gibt es eine gute Anleitung dazu:
http://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C

Wenn ich den Code aus der Anleitung nehme und compiliere
1
                                                             // Dieser Wert muss evtl. angepasst werden:
2
#define BOOTLOADER_ADDRESS     0x1800                        // bootloader start address, e.g. 0x1800 = 6144
3
4
#define RJMP                   (0xC000U - 1)                 // opcode of RJMP minus offset 1
5
#define RESET_SECTION          __attribute__((section(".bootreset")))
6
7
uint16_t                       boot_reset RESET_SECTION = RJMP + BOOTLOADER_ADDRESS / 2;

erhalte ich an der Reset-Adresse folgende Werte:
ff 08

Das kann doch eigentlich nicht sein, oder? Normalerweise sollte dort der 
Code für RJMP xxx stehen, als der Opcode 0xCxxx.
Wenn ich mit dem Simulator durchsteppe spring der Processor auch nach 
dem Reset nicht sondern durchläuft die folgenden NOPs des leeren 
Speichers.

Woran könnte das liegen?

von spess53 (Gast)


Lesenswert?

Hi

Unterschied zwischen Byte- und Wordadresse?

MfG spess

von ChrisMicro (Gast)


Lesenswert?

>Unterschied zwischen Byte- und Wordadresse?

Wahrscheinlich eher nicht. In der Beschreibung oben steht folgendes:

###################################################################
Später werden wir dafür in der erzeugten HEX-Datei sehen:

   :02000000FFCB34

Diese Zeile bedeutet: 2 Bytes im Flash an der Adresse 0x0000, die Werte 
sind: FF CB (Little Endian, daher hier "rückwärts" zu lesen). Der Opcode 
ist also CB FF, was einem "RJMP +17FE" entspricht, also einem Sprung an 
die Adresse 0x1800.
###################################################################

Es will aber einfach kein FF CB an der Adresse 0 auftauchen.
Ob es vielleicht am Simulator liegt? Vielleicht sollte ich mal 
versuchen, einen Attiny85 zu flashen und schauen, ob der Wert dann 
stimmt.

von spess53 (Gast)


Lesenswert?

Hi

> also einem Sprung an die Adresse 0x1800.

Der Attiny85 hat aber nur Adressen von 0x0000 bis 0x0FFF.

MfG Spess

von c-hater (Gast)


Lesenswert?

ChrisMicro schrieb:

> Es will aber einfach kein FF CB an der Adresse 0 auftauchen.
> Ob es vielleicht am Simulator liegt?

Wohl kaum. Der Simulator hat ja direkt beim Start der Anwendung (in 
diesem Fall also des Bootloaders) noch rein garnix getan. In diesem 
Moment zeigt er nur genau das an, was das Image der Anwendung in seinen 
simulierten Flash reingespielt hat, ist also eigentlich kaum mehr als 
ein Hex-Editor...

Sprich: der Fehler liegt wohl im Image.

Man kann das verifizieren, indem man sich einfach nur das *.hex bzw. 
*.elf anschaut. Dann ist der Simulator definitiv völlig raus...

von ChrisMicro (Gast)


Lesenswert?

Hallo Spess,

die Zeile oben aus dem Bootloader-Code teilt die Adresse durch 2
1
uint16_t                       boot_reset RESET_SECTION = RJMP + BOOTLOADER_ADDRESS / 2;

also 0x1800/2 = 0x0C00

Da die Adresse im RJMP 1 kleiner sein muss ergibt sich wohl

0x0C00-1 = 0x0BFF

Zusammen mit dem Opcode für RJMP 0xC000

ergibt sich 0xC000+0x8FF= 0xCBFF

Also müsste FF CB an der Adresse 0 stehen.

Ich habe gerade mal einen Attiny85 per ISP geflasht und via Debug-Wire 
kontrolliert. Leider steht an der Stelle 0 nur FF FF.

von c-hater (Gast)


Lesenswert?

spess53 schrieb:

>> also einem Sprung an die Adresse 0x1800.
>
> Der Attiny85 hat aber nur Adressen von 0x0000 bis 0x0FFF.

Jetzt bist allerdings eher du auf das Problem Byte- vs. Wordadresse 
reingefallen. 0x1800 ist ganz offensichtlich als Byteadresse gemeint.

> RJMP + BOOTLOADER_ADDRESS / 2;

Man beachte das "/ 2"

Die Rechnung passt also durchaus, es sollte 0xCBFF rauskommen, also in 
der little endian Darstellung in bytes "FF CB" ab Adresse 0 auftauchen, 
genau wie der TO es erwartet hat.

von ChrisMicro (Gast)


Lesenswert?

Jetzt versuche ich mal ein auf das Wesentliche reduziertes Programm:
1
#define BOOTLOADER_ADDRESS     0x1800                        // bootloader start address, e.g. 0x1800 = 6144
2
3
#define RJMP                   (0xC000U - 1)                 // opcode of RJMP minus offset 1
4
#define RESET_SECTION          __attribute__((section(".bootreset")))
5
6
uint16_t                       boot_reset RESET_SECTION = RJMP + BOOTLOADER_ADDRESS / 2;
7
8
#define LEDPORT (1<<PB1); //PB1 pin 6 Attiny85
9
#define INITLED {DDRB|=LEDPORT;}
10
11
int main()
12
{
13
  INITLED;
14
  while(1);
15
}

und in Atmeo Studio 7 => Toolchain/AVR_GNU_Linker/Memory Settings

.text=0x0D00
.bootreset=0x00

Aber leider stimmt der Bootvektor immer noch nicht.

von ChrisMicro (Gast)


Lesenswert?

Hier noch ein Nachtrag. Damit der Test compiliert muss boot.h includiert 
werden:
#include <avr/boot.h>
ausserdem sollte .text hier liegen:
.text=0x0C00

Aber es funktioniert trotzdem nicht. Es sieht so aus, als ob die Zeile
1
uint16_t                       boot_reset RESET_SECTION = RJMP + BOOTLOADER_ADDRESS / 2;

einfach vom Compiler ignoriert und weg optimiert wird.

Bitte 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
Noch kein Account? Hier anmelden.