Hi All
The following guide can be used to work with AVR32 Studio V2.6 and the uTasker project. Note that there are still a few issues with the latest AVR32 Studio which give a couple of restrictions but the result is workable. The issues have all been tested by the AVR32 developers and confirmed as reproducible problems that have been added to the developer's list of open points/bugs. These will probably therefore be fixed in future versions of AVR32 studio.
The first part is a guide as to how to create an AVR32 project from the uTasker project source (the second deals with some details and workarounds to ensure that things operate on a Windows 7 PC):
1. Select File | New | Other
- chose "AVR32 C Project" then click "Next"
- set project name "uTaskerV1_4" - use default location, chose CPU and Project type AVR32 Standalone Executable - then click "Finish"
This has created an empty "managed-make" project.
2. Click on the project and then right-click to Select Import
- then select File System -> click "Next"
- From directory = "\uTaskerV1.4_AVR32" -- then click on the folder that appears (so that it has a tick in its box)
a) Ether import the complete project, after which some files and directories will need to be later excluded from the build, or
b) Expand the folder and deselect the files Tools, WinSim and also the file Change-Notes.
-- further more, deselect the projects that are not to be compiled in \applications (eg. remove uTaskerBoot and uTaskerSerialBoot if the project is to build the main demo application).
-- there are a few simulation files that specifically need to be removed: Hardware\IIC_devices
Hardware\AVR32\AVR32Sim.c
Hardware\AVR32\AVR32_boot.c
Option "Create selected folders only". Into folder "utaskerV1_4" - this is the destination project that was previously created!
Now the project has a copy of the basic files in it. AVR32 studio has created a make file to build the project but it won't work just yet because its include paths are not correct.
3. Click on the project again and right-click to access the properties menu.
- in C/C++ General, open the Paths and Symbols entry and add /Applications/uTaskerV1.4 to the GNU C include directories (be careful to select this under languages otherwise it will add it to the assembler path instead!).
- then in "Symbols" add _HW_AVR32 and _GNU. They don't need a value - just need to be defined.
4. Unfortunately there may be a few simulator files which AVR32 is still trying to compile. If they did get through during the file system import they will need to be deleted manually - or (see 1 a) above) they can be excluded from the build by selecting the folder (if a complete folder is to be excluded) or the individual file, right-clicking the mouse and setting the option to exclude from the build.
5. The C compiler settings are configured in project properties - C/C++ Build -> Settings -> tool settings. The uTasker project is usually compiled with maximum optimisation for space (-Os). It is simplest to disable all other options and add the following to the Miscellaneous entry -march=ucr2 -Wall -Wstrict-prototypes -g -c -Os
In the linker settings also disable all settings and add the following to the Miscellaneous entry -Wl,-Map=uTaskerV1.4.map -nostartfiles --no-gc-sections -T"${workspace_loc:/uTaskerV1_4/Applications/uTaskerV1.4}"\GNU_AVR32\uTaskerV1.4_AVR32.ld.
6. Note that the linker script to be used was also configured under point 5 with the entry -T"${workspace_loc:/uTaskerV1_4/Applications/uTaskerV1.4}"\GNU_AVR32\uTaskerV1.4_AVR32.ld
This is setting the linker script file relative to the work space location and assumes that the project's name is "uTaskerV1_4" - it is taking the linker script file uTaskerV1.4_AVR32.ld from the GNU_AVR32 sub-directory. If anything doesn't match, modify accordingly - in the worst case use an absolute path to the linker script file on the PC being used.
The project should now compile without any errors and generate an ELF file in the target's output folder (default is the directory debug which AVR32 studio created).
7. It is advisable to generate also a BIN file and display the GCC tool chain version being used (for example, AVR32 Studio V2.6 includes a newer toolchain which is a pre-installed plug-in, which means that the compiler version may unexpectedly change - such things are then visible).
Therefore add the following two entries to the projects C/C++ Build | Settings | Build Steps
Pre-build step command avr32-gcc -v which will cause the version to be displayed before starting the build
Post-build step command avr32-objcopy -O binary uTaskerV1_4.elf uTaskerV1_4.bin which will generate a binary output from the ELF file.
2.1.2011 Version 4. (Used linker script file referenced to the workspace, miscellaneous settings, pre- and post build steps)
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Second part concerning how to ensure that things really work:
1) I am assuming Windows 7 as operating system
2) The lastest official version of AVR32 Studio is V2.6 (at time of writing)
3) In this version the new AVR32 GCC compiler is integrated as a plug-in so doesn't need a further installation of the AVR32 tool chain. Presently this is 4.3.3 (AVR Toolchain 3.0.124).
4) The uTasker project doesn't build with the latest GCC version due to three files which cause the compiler to crash with an internal error (has been reported). The files are GLCD.c, AVR32.c and mass_storage.c - if the optimisation of these files is disabled (set to -O0 rather than -Os, or any other setting) it then builds and runs correctly. Therefore the newest compiler can be used as long as these files are not optimised but there have been reports of further difficulties (like code not working as it should) - therefore this version should be avoided if possible.
The GCC compiler can also be removed from AVR32 studio [Note that to do this you need to start AVR32 studio as administrator by selecting its start button, then right clicking to get the context menu and commanding the execution as administator] as described in the release notes so that older versions can still be used.
The newest AVR utilities can also be de-installed but this doesn't seem to make a difference - best leave them as they are.
5) AVR32 Studio is Java based and so not the faster in the world. AVR32 studio may take several minutes to start so some patience may be required.
6 ) AVR32 Studio presently doesn't like the uTasker project. It builds it without any difficulties but can't FLASH the ELF produced by the project so the post-build step of generating a binary file is of importance. The binary file should be programmed to FLASH using the programming tool in the studio since neither the debugger (which always loads the ELF) nor the programmer (when trying to load ELF) has any real consistent success with it - it will usually hang before it tries actually doing anything with the target so best to just stick to the binary load (AVR32 Studio developers can reproduce the problem and are looking into why the ELF generated by certain projects can cause the tools to go on strike...)
7) Since loading code from the debugger won't work this can be disabled in the debugger setting as follows:
- Locate the ELF file that was generated by the build (usually in the debug directory). Right click to get the context menu and select "Debug as" | "Debug Configuration...". Mark "Suppress programming" so that the ELF file is not loaded to FLASH, and also select "No erase". This means that the debugger will then connect but not try to program anything (of course the binary should have been loaded first) and then it will be able to debug (but see next points too).
8 ) The V2.6 version is not always compatible with projects that were constructed using older versions. If the debugger won't connect and gives a message concerning an extension being missing there is only one solution. You need to rebuild the project according to the instructions at the start of the thread so that it is also constructed in the correct format - no one knows why this is the case but when the project is reconstructed all works normally again.
9) AVR32 Studio may or may not be able to debug - it the debugger hangs and doesn't run after stepping, the following solution can be used: Move to a fresh workspace and import the existing project from the old one (this is simple to do and doesn't require the project to be built up again - the files can still remain in the old workspace) and it then works correctly. I can't explain why but it worked for me...
10) At the moment one nuisance with AVR32 studio is that it only displays CPU register contents as integers - that means that it displays the start address 0x80000000 as -214748364 and one needs a hex calculator at hand to be able to interpret them (unless you happen to be able to convert such numbers in your head).
- Many thanks to Oneill at AVR Freaks for pointing out how to work around this: Open an expression window (Window | Show View | Expressions) and add an expression for each CPU register [$r0, $r1, .. $r12, $sp, $lr, $pc (each entry needs to be added individually)]. Then use the format setting in the context menu to change each expression to be displayed as hexadecimal. The expression window can then be used instead of the CPU register window!
11) This means that AVR32 Studio V2.6 should be workable. It has some basic restrictions (mainly not being able to load ELF files from the project) but, with the workarounds, real project work can be performed with it.
Regards
Mark
