Toolchain creates Illegal Opcode?

Last post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there,
I tried to convert a Project from the AVR32 Studio to the AVR Studio 5.
After several fails, I broke down the project step by step till there are only some commands to drive a Led.
After that failed too, I started all over from scratch, using the EVK1100 and the Dragon.
The disassembly during debugging looks like:

   #define BIT(n)  (1<<(n))
   #define Led0  BIT(27)
   #define Led1  BIT(28)
      	
	AVR32_GPIO.port[1].oders = Led0 | Led1;
80000088  mov R8, -61440		 
8000008C  movhi R9, 0x1800    ********		 
80000090  st.w R8[324], R9		 
	AVR32_GPIO.port[1].gpers = Led0 | Led1;
80000094  st.w R8[260], R9		 
	AVR32_GPIO.port[1].ovrc = Led0;
80000098  movhi R9, 0x0800    ********** 
8000009C  st.w R8[344], R9		 
	AVR32_GPIO.port[1].ovrs = Led1;
800000A0  movhi R9, 0x1000   ********** 
800000A4  st.w R8[340], R9		 
800000A8  rjmp 0x800000a8

During single-stepping the lines marked with asterisks cause a jump to adress 0x80000220:

80000218  rjmp 0x80000218		 
8000021A  add R0, R0		 
8000021C  rjmp 0x8000021c		 
8000021E  add R0, R0		 
80000220  rjmp 0x80000220   <<<<<<<<<<<		 
80000222  add R0, R0		 
80000224  rjmp 0x80000224		 
80000226  add R0, R0	

The file exception.S shows the following (included through ASF):

  // EVBA must be aligned with a power of two strictly greater than the EVBA-
  // relative offset of the last vector.
  .balign 0x200

  // Export symbol.
  .global _evba
  .type _evba, @function
_evba:

[snip]

        .org  0x020
        // Illegal Opcode.
_handle_Illegal_Opcode:
        rjmp $

It looks like the Toolchain generates wrong code for the 32UC3A0512.

Any suggestions?

Greetings, Lunchen.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The illegal instructions are new instructions introduced in rev2 of the AVR32 architecture.
Some of the EVK1100s out there use an older revision chip that does not have these instructions. These chips are not (yet?) supported by AS5, but you can get the compiler to generate good code for them (part uc3a0512es).

Here's how I tweaked an AS5 installation to accept the unsupported part [deleted, hce has a better solution]

Edit: better solution provided below by hce.
Try though -march=ucr1 for your EVK1100.

Dan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can also force the toolchain to compile for an older UC3 arch by supplying -march=ucr2 in the toolchain settings. The biggest issue might arise if there are changes in peripherals not compatible with the newer revisions.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your help.
Now I got a clue. I'll try both options.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Overiding -march is not sufficient, you'll need to hack the io.h from the header files to select the correct header files set (uc3a0512es and uc3a0512 have a different set).

-sma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sma wrote:
Overiding -march is not sufficient, you'll need to hack the io.h from the header files to select the correct header files set (uc3a0512es and uc3a0512 have a different set).

-sma

How do I do that? I have this problem and am stuck :-(