I use GCC, so I don’t know whether things might work differently with the IAR compiler.
I found that the best way to get a working project (ie. one that builds and runs) is to start with one of the example projects supplied with AVR32 Studio. This is done by selecting File->New->Example (in AVR32 Studio), and then picking an example project for your processor (there are 4 sections in the list of examples). This creates a complete project that builds and runs, and that you can then modify to your heart’s content.
I have just taken one of the undefined symbols at random (AVR32_INTC_IPR0_INTLEV_SIZE) and searched for it in my IAR installation directory, and found it to be defined in IAR Systems\Embedded Workbench 4.0\avr32\inc\avr32\intc.h
However, my installation is not up to date so maybe IAR have changed the names of the definitions?
Also, there was a lot of confusion over header files when this port was first done, some mess up with the compiler or other, and Atmel provided me with a patch for the compiler. Maybe the file comes from that?
Make sure you have v1.3 of Atmel’s framework, you can download from Atmel’s website. The framework contains the headers files in “FrameworkDir/Utils/AVR32_HEADER_FILES”. Unzip to the compiler’s include directory (C:\Program Files\IAR Systems\Embedded Workbench 5.3\avr32\inc\avr32 on my machine). This overwrites the existing files so I recommend backing up the old headers first.
I just tried compiling the latest FreeRTOS download with V2.21B of the IAR tools and it built fine, but as I said before I think I have some patches that were supplied by Atmel. It looks like the latest compiler version I have is 3.10a, I will try installing that now.
You can ignore the warning about the stack, that is just because the compiler expects the stack to be within the region defined in the linker script, whereas in fact its within the heap.
Having installed the new compiler version I can see that the libraries have changed, probably to be made simpler. All was going well doing the updates, as:
Yuk - what on earth is that! I’m sure somebody is very pleased with how clever they have been there but I’m not even going to attempt to fix the compile error its now generating. Its just too horible.
I think I am going to have to get in touch with Atmel and merge the latest FreeRTOS.org version with their software framework. They must have fixed this stuff in there, on the assumption they are using the latest compiler.
The other problem is the different revisions of the chips need different fixes applied, so this also needs sorting.
Sorry not to be of more use, this appears to be a bit of a smudge on the project that needs cleaning off.
Again I think the best course of action would be to use the official Atmel stuff.
I cleaned up the INTLEVEL, PWM, UART (and LED) references and got FreeRTOs AVR32 Demo (V5.1.1) to build under kickstart 5.3, but it ain’t running yet.
(3 days, so far)
I might get some help from Atmel.
I’ll keep you posted.
(Which version of KickStart Workbench does the FreeRTOS AVR32 demo work with?)
Here are my changes that will, at lest, get the demo ‘built’ (though it ain’t running yet:-
in int.c :-
around line 111 :-
__int_handler _get_interrupt_handler(unsigned int int_lev)
{
// ICR3 is mapped first, ICR0 last.
// Code in exception.S puts int_lev in R12 which is used by AVR32-GCC to pass
// a single argument to a function.
// Workbench compatibility issue:-
/* Workbench v?.?
unsigned int int_grp = (&AVR32_INTC.icr3)[INT3 - int_lev];
unsigned int int_req = AVR32_INTC.irr[int_grp];
*/
// Workbench v5.3
unsigned int int_grp = (&AVR32_INTC.icr[INT3])[INT3 - int_lev];
unsigned int int_req = AVR32_INTC.irr[int_grp];
//
Around line 197 :-
// NOTE: The _intx functions are intermediate assembly functions between the
// core interrupt system and the user interrupt handler.
// Workbench compatibility issue:-
/* Workbench v?.?
AVR32_INTC.ipr[int_grp] = ipr_val[int_lev & (AVR32_INTC_IPR0_INTLEV_MASK >> AVR32_INTC_IPR0_INTLEV_OFFSET)];
*/
// Workbench v5.3
AVR32_INTC.ipr[int_grp] = ipr_val[int_lev & (AVR32_INTC_IPR_INTLEV_MASK >> AVR32_INTC_IPR_INTLEV_OFFSET)];
//
}
You can try to compile the V 5.1.1 package with those two environments.
If it does not work, I suggest you use our code examples which are provided in our software framework packages in folder : SERVICES\FREERTOS\Demo
and see if they suit to your needs. In every case, you need to update your header files by unzipping \UTILS\AVR32_HEADER_FILES\AVR32_Header_Files.zip package in C:\Program Files\IAR Systems\Embedded Workbench 4.0\avr32\inc. This will update the avr32 folder including the header files. I advise you backup your original header files first. "
Wow - how did you manage to get an answer from Atmel so quickly? Do you have the email address of an engineer or go through their support ticketing system?
It looks like is going to be some effort to get up to the latest IAR versions.
The best place to ask would be on the AVR freaks forum http://www.avrfreaks.net , although the WEB site only seems to work for me one day in 3. Most AVR32 chatter comes directly from Atmel.