WinAVR Version
AVR Applications Group
October 2005
Introduction
The objective of this Hands-on session is to guide you through the different steps of using the AVR-GCC Plug-In for AVR Studio. It includes step-by-step instructions to point you in the right direction, but does not always include all necessary information to complete the tasks. In many situations you will therefore need to seek answers elsewhere to completely solve the problem. A very useful source for information is the on-line help system in AVR Studio. Always remember to check the help system if you have any questions on how a feature in used.
This training assumes you are somewhat familiar with AVR Studio, stk500 and JTAGICEmkII. Note that it is a step-by-step training and it is therefore very important that you read and complete all tasks before you continue with the next step.
Getting Started
Install Software
This training is based on this software:
AVR Studio 4.12
WinAVR 2005-02-14
Sample code files for the training
In the hands-on text it is assumed that you have used the default installation settings, and that you have copied the sample codes here: C:\avrgcc\code\
Install Hardware
The training is based on the use of this hardware:
STK500
JTAGICEmkII
ATmega32
Before proceeding with the hands-on please install the hardware like this:
STK500
Verify that an ATmega32 is inserted in the correct socket.
Connect the STK500 to the PC with the serial cable.
Connect the ISP/SPI cable.
Connect a 10 pin flat cable between PORTB and LEDS.
Power up and use the AVR Studio programming interface to program the fuses to;
Enable JTAG Interface,
Disable BootReset Vector,
Boot Flash Section Size = 2048 words,
Enable Internal RC Oscillator @ 8MHz
(High fuse: 0x99, Low fuse: 0xD4)
JTAGICEmkII
Connect the STK500/JTAG adapter to the EXPAND0 slot.
Connect the JTAGICEmkII cable to the correct header in the adapter.
Connect the JTAGICEmkII to the PC with the USB cable.
Power up and use the AVR Studio Programming interface to verify the communication with the target AVR.
Task 1: My First Project
Here we will demonstrate the basic steps of creating a GCC project, compiling and debugging it.
Create a new project
Use the Project Wizard
Select New Project
Project Type
AVR-GCC
Project Name
Select your code folder and type a name for your new project.
Select to create initial file.
Use the AVR Simulator & ATmega32
Add code
Type this code into the new file.
MyFirstProject
#include
volatile int MyCounter;
int main()
{
DDRB = 0xFF; /* Set PORTB as output */
while(1)
{
PORTB = MyCounter++; /* Increment MyCounter and */
} /* put it out on PORTB */
}
Compile
Select Build.
AVR Studio will run the compiler and show the output messages in the Build window.
Since the code has no errors you can now select Start Debugging.
Debugging with the simulator
In the code window, select MyCounter variable inside the while loop.
Press F9 to place a Breakpoint at this location.
Right click the mouse on MyCounter and select [Add Watch: “MyCounter”]
Repeatedly clicking F5 will now run the code and stop execution each time it reaches the breakpoint.
Notice that the variable is incrementing in the watch window.
On-chip debugging
Use the JTAGICEmkII to verify correct operation on the real device.
Go to the Debug menu and “Select Device and Debug Platform”.
Change platform to JTAGICEmkII.
Single step the code by pressing F11 repeatedly and verify correct operation on PORTB.
The Generated Files
Open an explorer window to view what files that now have been generated.
All source files must be located in the Project folder together with the AVR Studio project file.
However all other files are generated in a sub folder with the name of the saved configuration.
You will learn more about this later in the hands on training.
All listed files are automatically generated and will be overwritten each time you build the project.
Makefile This is the makefile that includes all the compiler settings for this project.
###.eep A hex file containing the eeprom content. Download this file with a programmer.
###.elf The object file containing all debug data. This file is in the ELF format with DWARF debug data. Open this file to start debugging.
###.hex A hex file containing the flash content. Download this file with a programmer.
###.o Basic object file containing all debug data. Used to generate all other debug files.
You can delete these files by using the Clean option in the Build menu in AVR Studio.
Select Build to re-generate/compile the files.
Task 1 completed
Task 2: Open existing files
Create a new empty project without creating the initial source file.
Call it “Interrupt” and place it in the hands-on code folder called “Interrupt”.
There are 2 ways to add the existing files to the empty project.
-1-
Either by right clicking and selecting “Add Existing File”.
-2-
Or by first opening the folder with your project files in the explorer window.
Select all C files, and use the mouse to Drag-N-Drop all the files into the AVR-GCC Project Tree.
Notice how all C files are automatically added to the Source Files tab.
Compile the project and notice that External Dependences is automatically updated with links to all the included header files.
Notice that if the compilation fails the error messages are tagged RED in the Build window.
Double click the error message and the failing code line will be directly pin pointed.
Correct the error and re-build the project.
Task 2 completed
Task 3: Data Breakpoints
Start Debugging and open the IO view.
Right click the mouse on PORTB, and select [Add Data Breakpoint:”PORTB”]
Run the code, and it will break operation, pointing to the position AFTER the instruction accessing PORTB.
By default it will break on any type of access to this data location.
The AVR Simulator and ICE50 have additional advanced features for data breakpoints.
Lets say we want to only break if bit 4 in PORTB is written to 0.
To do this, find the new Data Breakpoint on the “Breakpoints and Tracepoints” window.
Double click it to enter the properties window.
Select “Bits of location is equal to a value”.
Value = 0
Bitmask = 0x10
Run the project and check if it breaks as expected.
Task 3 completed
Task 4: AVR Libc
The AVR Libc is the standard library package providing a subset of the standard C library targeted for the AVR’s.
Open the AVR-Libc Referance Manual from the on-line help menu in AVR Studio.
This document is the key reference for all code development with the AVR’s.
Here you can find loads of information and code samples on how to use almost all the features.
In AVR-GCC there are two types of macros used for writing interrupts.
What type did we use in the last code example?
What is the difference between the two types?
Use the AVR-Libc Reference Manual to find the answers.
Task 4 completed
Task 5: Compiler Options
Normally customizing compiler options with a GCC compiler involves editing “makefiles”.
However in the AVR Studio plug-in many of these features are automated into a GUI.
To edit the project compiler options; select “Configuration Options”.
The project options is a dialog consisting of five property pages:
General is comprised of options concerned with options controlling the output of a project build.
Include Directories is used for setting up the search path that avr-gcc uses when looking for header files.
Libraries controls the avr-gcc search paths for libraries and sets up libraries to link with.
Memory Settings are used to define new memory segments, relocate standard segments and set up bootloaders.
Custom Options enables individual compiler options for each project source file. Linker options and avr-gcc/make setup is also contained here.
Before proceeding with the hands-on, you MUST read the on-line help describing all these dialogs and options.
Task 5 completed
Task 6: External Makefiles
Writing your own makefiles is a fairly complicated matter. WinAVR has included the MFile tool that can assist you in this process. We will not cover that tool in this training, but you can find more info on the tool in the MFile sub folder of WinAVR.
E.g. C:/Program Files/WinAVR/MFile/README
Instead we will use a pre-made makefile and only slightly modify it for our use.
Still assuming you are in the Interrupt project.
Open the Project Options dialog.
Select “Use External Makefile” and select the new makefile that is in the project root folder.
Note now that it pops up in the “Other Files” tab in the Project tree.
Double click it to open it.
Find the section where you specify the device and change it to ATmega32.
Save the makefile and Build.
Notice the different output that this makefile generates.
Task 6 completed
Task 7: Library Functions
The
Open the main.c file and add the square root function call just after the “led=9;”
Update main.c with this code
(…)
led = sqrt(led);
(…)
Remember to include the
Build the project.
Why do you get an Undefined Reference to sqrt when you compile?
Open the Project Options window and go to the Libraries section.
Library’s made available in the WinAVR distribution are already listed.
Select the libm.a, and move it to the “Link with These Objects” section.
Now re-build the project.
Add a watch to the led variable.
Place a breakpoint before and after the square root function call.
Verify that the math function really works.
Task 7 completed
Task 8: Memory Settings
Create a new empty project without creating the initial source file.
Call it “BootSection” and place it in the hands-on code folder called “BootSection”.
Select JTAGICEmkII and ATmega32 as target.
Add the 2 files (main.c and BootSection.c) to the project.
This is a simple program demonstrating how to program the flash from the application code.
The code first reads a location in flash and puts the content out on PORTB.
Then it programs the complete page with 0xAA.
Finally it reads the same initial location in flash and puts the content out on PORTB.
This simple program will be used to test if we can get the application code to program into its own flash.
Compile and Run the code.
Notice that there are no compile errors, but still PORTB is “dark” indicating that the flash variable is 0xFF and not 0xAA as intended.
Use the Watch feature on the “targetpage” variable to find out what location in flash the code is trying to program.
Open the Memory view and find this memory location in the flash segment.
Notice that the targetpage stores the byte address, while the default view in the memory window shows the word address.
What is the word address of our target page?
Place a breakpoint on each pgm_read_byte() function call.
Run the code while observing the program memory window.
Is the flash updated with 0xAA? Why not?
The code used for programming the flash (BootSection.c) is a pure copy-n-paste from the bootloader example code in the AVR-Libc Reference Manual.
The nature of the SPM instruction is that it is disabled while executed in the Read While Write (RWW) section. I.e. the flash programming code must be placed in the bootloader section of the flash memory.
To instruct the linker to place the boot_program_page() function in the No Read While Write (NRWW) section, first add the following line to the header of the BootSection.c file.
Tell the compiler to place the code in the section called “.bootloader”
void boot_program_page (uint32_t page, uint8_t *buf) BOOTLOADER_SECTION;
The BOOTLOADER_SECTION is defined like this:
#define BOOTLOADER_SECTION __attribute__ ((section (".bootloader")))
By default, code is placed in the .text segment.
We now need to define a memory segment in the flash called “.bootloader” and give it the address of the NRWW section.
Open the Project Options dialog, and the Memory Settings tab.
Create a Memory Segment called “.bootloader” in the flash.
The address is the start address of the Boot Loader Section.
What address should we use? (Tip: look in the bootloader section in the datasheet)
Re-build the project and verify that both PORTB, and the targeted flash page in the memory now view shows 0xAA.
Open the Project Options dialog and enable “Generate Map file” and “Generate List file”.
Re-build the project, and notice that the Map(*.map) and List (*.lss) file is now available in the Other Files tab of the project tree.
Open then List file.
Notice that here you can see information on size and location of the different memory segments.
“Size” shows the size of compiled code, and LMA shows the start address.
Why does it say 0x7000?
Extra task on boot loader debugging
Open the BootSection.c file.
Place a breakpoint on the “for loop”.
Run to this breakpoint.
Look at program/flash in the Memory view.
Why are absolutely all locations of the flash 0xFF?
Task 8 completed
Task 9: Custom Options
The Custom Options tab in the Project Options dialog gives a convenient way of setting different compiler options on different files.
Open the Project Options dialog.
Set optimization level to 0 (-O0), and select to Generate List file.
Build the project.
Open the BootSection.lss file.
Take note of the memory size of the .text and .bootloader segments.
Open the Project Options dialog.
Keep the general optimization level at –O0.
Open the Custom Options tab.
Select the BootSection.c file, type –Os next to the Add button and click Add.
Build the project.
Notice that the .text segment is not effected.
But how much smaller is the bootloader code now as the speed optimization is on here?
Task 9 completed
Task 10: Different Configurations
In the Project Option you can save all settings as different configurations.
This can be used in many ways. E.g.
Debug vs Release configuration
Same project/code on different devices
Different memory mappings (e.g. bootloader location)
etc
Use the same BootSection project. Leave the default configuration for ATmega32 as is, and make a new custom configuration called “m16_boot”.
Set the new configuration to compile for ATmega16, Speed Optimized and with the .bootloader segment pointing at the largest bootloader start address in ATmega16.
Task 10 completed
Task 11: Mixing C and assembly
C and assembly files can be mixed in the same project.
The plug-in will automatically compile all *.c files with c compiler and all *.s files with the assembler.
Create a new empty project without creating the initial source file.
Call it “C_Assembler” and place it in the hands-on code folder called “C_Assembler”.
Add the 3 files (main.c, test_func1.c and test_func2_asm.s) to the project.
Build the project.
Notice that even the assembler files are syntax highlighted.
Single step through the code.
Notice how execution focus moves to the external c file, but NOT the external assembler file.
By looking in the disassembly view you can see that the code is actually being executed correctly.
The reason you can not debug the assembly source file is that there is a bug in the avr-gcc assembler.
It is simply not adding the required debug information to the object file.
Task 11 completed
Tidak ada komentar:
Posting Komentar