nobody39 wrote on Monday, October 03, 2005:
Hi,
I have followed Richard Barrys instructions (http://sourceforge.net/forum/message.php?msg_id=3250052) to change the code for ATMega128.
I run this in AVR Studio with JTAGICE. It works perfect until the final step where I notice that the program jumps to strange places (comments) in the file tasks.c. Does anybody have a clue?
I have increased the heap size to 3500.
nobody wrote on Monday, October 03, 2005:
If your debugger jumps to comments it normally means the file being executed (debugged) is not up to date with the source files. The debugger thinks it is showing you the line it is executing, whereas in fact the source files have changed and it is showing you a comment line.
Can you do a ‘make clean’, then rebuild - and ensure it is the elf file that you are debugging.
Also check that the elf file being debugged is coming from the directory you think it is.
nobody39 wrote on Monday, October 03, 2005:
Starting all over again with new files and Richard Barrys instructions.
In the makefile: DEBUG = ELF/DWARF-2
I do a ‘make clean’.
I do a ‘make all’.
I am using rtosdemo.elf in AVR Studio 4.11.
When executing
vTaskStartScheduler();
AVR Studio asks me to locate a file.
If I select ‘tasks.c’ the debugging continues in the tasks.c-file with the above error (execution ending up in the comments).
It is strange to me that I have to locate a file. All files are visible in the workspace window under project in AVR Studio.
rtel wrote on Monday, October 03, 2005:
I agree being asked to locate a file seems odd and contrary to my experience. However, I have only used AVR Studio with the simulator.
Old versions of WinAVR could not produce extended coff or elf formats - so all the object code had to be in the same directory for AVR Studio to be able to locate them. To get around this the FreeRTOS demo was built using a batch file that copied all the required source into a single location.
Later versions of WinAVR could produce extended coff, getting around this limitation so the batch file was ditched - builds simply using make and the included makefile.
Even newer versions of WinAVR have the elf outupt which is even better.
I have found that opening the AVR Studio GUI, then simply opening the elf file using the File->Open menu automatically created a AVR Studio project that contained all the source and object file necessary.
A few questions:
Which version of WinAVR are you using?
Are you building from the command line using the provided make file?
Have you modified the build at all?
How did you create the AVR Studio project (as described about?)?
Regards.
nobody39 wrote on Tuesday, October 04, 2005:
>> Which version of WinAVR are you using?
I use 20050214.
>> Are you building from the command line using the provided make file?
I build from the menu: Tools / [WinAVR] Make All
>> Have you modified the build at all?
I do the necessary changes to port to ATMega 128 and edit the makefile in WinAVR (MCU = atmega128 and DEBUG = ELF/DWARF2). When make is done, I simply start AVR and open rtosdemo.elf.
>> How did you create the AVR Studio project (as described about?)?
I simply start AVR and open ‘rtosdemo.elf’ from the menu File / Open.
I do not create a new project, neither in WinAVR or AVR Studio. I get the same result from another computer using the AVR simulator.
Starting all over again, with the original demo application, editing, make and AVR Studio, it also asks me to locate other files, i.e. ParTest.c.
I have tried Windows XP and Windows 98 with the same result.
rtel wrote on Tuesday, October 04, 2005:
>I use 20050214
I am using the same. I am using V4.11 of AVR Studio.
>I build from the menu: Tools / [WinAVR] Make All
I have always done this from the command line - but presumable this makes no difference.
>DEBUG = ELF/DWARF2
This should not be necessary. Using the makefile from the download you should get both coff and elf output. Try a clean build without this line. If this still does not work, would you be able to send me a zip file of your project? Include all the output object files, elf file, etc, and send it to the address from the FreeRTOS.org WEB site contacts page (r dot barry _at_ freer…).
Regards.
rtel wrote on Tuesday, October 04, 2005:
I have unzipped your files and opened your aps (AVR Studio project) file. To do this without rebuilding I had to place them in the same path as per your installation, then change from using the ICE to using the simulator (I don’t have the ICE).
Now, using your elf file and your object files I am able to step through the code with no problem. The first time tasks.c is used is when a task is created. I am able to step into this file without being asked for the object code location, and without the incorrect line being displayed in the debugger.
I have also tried doing a clean build, using your source and makefile without being able to replicate the problem.
Maybe it is something to do with the ICE configuration? Other than that some sort of build environment problem?
Regards.
nobody39 wrote on Tuesday, October 04, 2005:
I installed AVR Studio 4.12 and now it works.
I do not know why I have got the same fault in two different systems. Even though I’m a little curious and want to get a better knowledge of this, I will leave it and go on with “the real” project.
Thank you for your attention and help.
epsilonrt wrote on Sunday, November 13, 2005:
I use FreeRTOS to produce a robot (mavrix).
I use a ATMEGA128 and AVR Studio 4.12rc1
I created a small very simple demonstration to play of the music.
In the task which plays the music, the call with xTaskGetTickCount starts an error of AVRSTUDIO:
AVR Simulator: Invalid opcode 0xffff at address 0x003322
I suspect a overflow of pile (Richard put 112233 at the end of the stack) but even by increasing the size of that does not change anything. If you have an idea, I am interested… Thank you.