Fehlermeldung AVR Studio und GCC

[Pascal (Gast)]

Hi,

kann mir jemand erläutern wie ich folgende Fehlermeldung zu verstehen 
habe? Die Meldung erschein beim compilieren eines ATMega88 mit dem AVR 
Studio + GCC:

"/cc7GY9hV.s:124: Error: illegal opcode jmp for mcu atmega88"

Hab schon die Suche bemüht, doch leider nichts passendes gefunden.


Gruß

[abc (Gast)]

Anscheinend kennt der 88 den Assemblerbefehl JMP nicht. Richtigen µC-Typ 
im AVR-Studio eingestellt?

[Pascal (Gast)]

Danke!

JMP gibt es beim ATM88 nicht. Mit RJMP gehts....!!!!!

[Hc Z. (mizch)]

Den Opcode „jmp“ gibt es beim ATmega88 nicht.

Hast Du einen Assembler-Source compiliert?  Dann gibt es jmp erst ab 
168.  Ändern in rjmp.

Hast Du C mit Makefile kompiliert?  Dann hast Du vermutlich den 
Prozessor-Typ geändert.  Es muss alles neu kompiliert werden, z.B. durch 
Aufruf von „make -B“.

[Stefan B. (stefan)]

> "/cc7GY9hV.s:124: Error: illegal opcode jmp for mcu atmega88"
In Zeile 124 von cc7GY9hV.s taucht ein jmp auf.

Das ist für den Atmega88 nicht erlaubt, denn
Datenblatt Atmega88: 31. Instruction Set Summary: jmp(1)
(1): Note: 1. These instructions are only available in ATmega168.

Die offenen Fragen sind:

1. ist der nicht gezeigte C-Quellcode, der nach cc7GY9hV.s übersetzt 
wurde, fehlerhaft?

2. ist die nicht näher bezeichnete Toolchain aus AVR Studio und gcc 
fehlerhaft? Hier gab es einen ähnlichen Fall:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=55290

3. sind die nicht gezeichten Compileroptionen (Projekteinstellungen, 
Makefile) fehlerhaft?

Zur Klärung der Symptome (das ist noch noch nicht die Diagnose oder die 
Kur) würde der Tipp von TimothyEBaldwin aus dem avrfreaks.net Thread 
weiterhelfen.

[Jens M. (dl4aas)]

Hallo Pascal,

es ist nicht zufällig eine große switch-Konstruktion, die die Meldung 
erzeugt? Ich habe es schon gehabt, dass der Prozessor die vom Compilter 
gewünschten JMPs nicht beherrschte, wenn der Sprung zu weit wurde..

Gruss
Jens

[abc (Gast)]

Das wäre dann eher ein "out of reach", tritt vorzugsweise bei RJMP auf.

[Jens M. (dl4aas)]

abc, da hast Du wohl recht...

[Pascal (Gast)]

Hi,

hier die Funktion die anscheinend Probleme macht:

 
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

#include "aesglobal.h"
#include "bootldr.h"
#include "loader.h"
#include "bus.h"
#include "crc.h"


//=============================================================================
// Starts here!
//=============================================================================

int main(void)
{
    // enable pullup - give port time to settle
    set_bit(PORTD, PD2);

    busInit();

    // Loop forever (loops only if Application Section is damaged)
    for (;;)
    {
        // Key pressed? Yes -> run the loader routine
        if (!(PIND & (1 << PD2)))
        {
            loader();
        }

#if defined(CRC_CHECK)
        // Check that the Application Section contents is undamaged
        // by calculating the CRC of the whole memory.
        {
      #ifndef RAMPZ
              uint16_t p = 0x000000;
      #else
              uint32_t p = 0x000000;
      #endif

      uint16_t crc = 0;

            do
            {
      #ifndef RAMPZ
        crc = CRC(crc, pgm_read_byte(p));
      #else
                crc = CRC(crc, pgm_read_byte_far(p));
      #endif
            }
            while (++p < MEM_SIZE);

            // Application Section damaged
            //   -> do not jump to Reset Vector of the Application Section
            if (crc)
            {
                DDRB = 0xff;
                for(;;)
                {
                    PORTB ^= 0xff;
                    _delay_ms(500);
                }
            }
        }
#endif

        asm volatile ("rjmp 0");
    }
}

Mir scheint als der der Sprung and die Adresse 0 nicht 
funktioniert......

[Pascal (Gast)]

Das Programm hängt an dieser Stelle:

while (++p < MEM_SIZE);

[Pascal (Gast)]

Sorry, Alarm zurück!

Hab es gerade mal durch den Debugger direkt am Controller laufen lassen.

Das Programm springt anscheinend wirklich nicht an die Adreese 0, 
sondern es wird immer wieder die Main im Bootloader ausgeführt.

[Hc Z. (mizch)]

Ich mag mich täuschen, aber ich denke, den Fall hatte ich auch mal und 
das Problem ist, dass die „0“ bei „rjmp 0“ relativ zur Text Section 
(genauer: zum Beginn dieser) ist.  Somit kommt die 
Bootloader-Startadresse raus.

Du musst ein absolutes Symbol definieren und das als Argument zum rjmp 
mitgeben, also

    asm volatile ("rjmp Application");

schreiben.  Und dem Linker die absolute Adresse von Application entweder 
im Linkerscript mitgeben oder auf der avr-ld-Kommandozeile mit

  --defsym Application=0

oder dem Compiler (avr-gcc) mit

  -Wl,--defsym,Application=0

.

[Pascal (Gast)]

Super HC! Funktioniert einwandfrei!


Vielen Dank!

[Mario (Gast)]

Schau mal in den Wiki-Artikel
AVR Bootloader in C - eine einfache Anleitung

Dort steht auch wie es geht ,z.B.

void (*start)( void ) = 0x0000;

und dann der  Aufruf mit:

start();

Die Beispiele sind übrigens alle für den Atmega88 geschrieben...

[Robert K. (murdok)]

Mario schrieb:
> Schau mal in den Wiki-Artikel
> AVR Bootloader in C - eine einfache Anleitung
>
> Dort steht auch wie es geht ,z.B.
>

> void (*start)( void ) = 0x0000;
>

>
> und dann der  Aufruf mit:
>

> start();
>

>
> Die Beispiele sind übrigens alle für den Atmega88 geschrieben...

Diese Methode funktioniert allerdings nur wenn auf 0x0000 gesprungen 
werden soll.

Beim ATmega644 z.B. ist mit aufgefallen, dass mit diesem Code der Sprung 
auf eine Word-Adresse generiert wird. Wenn dann beispielsweise start 
nicht auf 0x0000 zeigt sondern auf 0xE000, wird auf 0x6000 (wordadress) 
gesprungen obwohl er bei 0x7000 landen sollte.

Mein Workaround bisher:

#define BOOTLOADER_START_ADDRESS    0xE000
#define jump_to_bootloader()   asm volatile ("jmp %a0 :: "i" \
                                 ((uint32_t)(BOOTLOADER_START_ADDRESS) & 0x0000FFFFuL));

Leider ohne automatischer Unterscheidung bei Sprungadressen grösser 
0xFFFF.

Hat hierzu vlt. jemand noch eine Idee?