Attiny85 Bootloader Reset Vector geht nicht

Hi

Unterschied zwischen Byte- und Wordadresse?

MfG spess

>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.

Hi

> also einem Sprung an die Adresse 0x1800.

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

MfG Spess

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...

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.

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.

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.

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.