Pumpkin, Inc.

Pumpkin User Forums

AVR simulator: excessive stack overflow

For issues specific to Atmel's AVR and MegaAVR microcontrollers, including Atmel AVRStudio and ImageCraft's ICCAVR C compiler.

Re: AVR simulator: excessive stack overflow

Postby aek » Thu Dec 14, 2006 10:14 am

Wow. It is a simulator problem.

This is the oddest simulator problem I have ever seen.

To prove this, I modified the application very slightly so that I could see what was going on ...

code:
#include <inttypes.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>

#include "salvo.h"

#define TASK_MEASURE_P OSTCBP(1) /* task #1 */
#define PRIO_MEASURE 10 /* task priorities*/
#define BINSEM_ADCRDY_P OSECBP(1) /* binSem #1 */


_OSLabel(TaskMeasurel)

unsigned int counter, counter2, counter3;


void TaskMeasure( void )
{
counter2 = 0x1234;
counter3 = 0x4567;

for (;;)
{
OS_Yield(TaskMeasurel);
counter++;
}
}


int main( void )
{
/* Initialize the OS */
OSInit();

/* Create all tasks */
OSCreateTask(TaskMeasure, TASK_MEASURE_P, PRIO_MEASURE);

/* Create semaphores */


/* Run the scheduler */

for (;;)
{
OSSched();
}
}


. The counters allow me to find them in the RAM, and to see one of them increase monotonically. I then created a Project built from external executable in IAR Embedded Workbench, set the target to an ATmega8, set the linker to generate (actually, to expect) an Intel standard hex file, added the output of WinAVR (qsfp.hex) to the Embedded Workbench project, and started C-SPY.

This loaded the project into the C-SPY simulator. I then set a few breakpoints (it's a little tricky because WinAVR shows the addresses as words and IAR shows them as bytes, so I had to multiply by two to find the correct addresses). I set a breakpoint at OSInit() (to catch resets), watched RAM, and then ran the application in C-SPY. [b]It runs forever[b], whereas it crashes after 511 calls to OSYield() in the WinAVR simulator. I can clearly see the 0x1234 and 0x5678 values, as well as counter incrementing (they're located at 0x64, 0x60 and 0x62, respectively).

So, since I'm running the exact same executable (a hex file) on two radically different simulators, AND there should not be any difference between the ATmega64 and 32 and 16 w/regard to Salvo's operation, at this point I must assume that the WinAVR simulator has some weird problem that Salvo tickles and causes it to crash. I will source some real silicon to test this ...

This took in excess of 7 hours to nail down the problem ... :(

So, it would be very helpful if you could program one of the "suspect" chips with a simple "LED counter" Salvo application and report back if it works on the chip.

------------------

[This message has been edited by aek (edited December 14, 2006).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: AVR simulator: excessive stack overflow

Postby aek » Thu Dec 14, 2006 10:44 am

Also, if you keep stepping after the overflow, it keeps giving you the overflow message, but everything else continues to work properly (you can see watched variables continue to increment as long as you have scope in a source-code file).

So it really looks to me like the stack overflow component of WinAVR is not working properly in these chips ... but I could be wrong.

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: AVR simulator: excessive stack overflow

Postby aek » Thu Dec 14, 2006 10:56 am

In case anyone thinks that Salvo is somehow using up the RAM, here are the build results:
code:
Build started 15.12.2006 at 00:08:59
avr-gcc.exe -I"C:PumpCustAlexNgi2qsfp." -I"C:salvoinc" -mmcu=atmega8 -Wall -gdwarf-2 -DF_CPU=4000000UL -O0 -fsigned-char -MD -MP -MT main.o -MF dep/main.o.d -c ../main.c
avr-gcc.exe -mmcu=atmega8 -Wl,-Map=qsfp.map main.o mem.o qins.o timer.o delay.o event.o init.o initecb.o inittask.o inittcb.o sched.o task.o binsem.o portgccavr.o idle.o -L"C:salvolibgccavr" -o qsfp.elf
avr-objcopy -O ihex -R .eeprom qsfp.elf qsfp.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex qsfp.elf qsfp.eep
avr-objdump -h -S qsfp.elf > qsfp.lss

AVR Memory Usage
----------------
Device: atmega8

Program: 2428 bytes (29.6% Full)
(.text + .data + .bootloader)

Data: 37 bytes (3.6% Full)
(.data + .bss + .noinit)


Build succeeded with 0 Warnings...


This was built using the latest gcc-avr from Win-AVR (20060421) and latest WinAVR:
code:
AVR Studio		4.12.498  Service Pack 4
GUI Version 4, 12, 0, 491
AVR Simulator 1, 0, 1, 8
ATmega8 213

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: AVR simulator: excessive stack overflow

Postby aek » Wed Dec 20, 2006 2:28 am

I obtained an ATmega8515 and and ATmega16, and programmed each with a slightly expanded version of the code, one that shows the counter value on the 8 LEDs of the STK500. They both work on real hardware, and the ATmega16 version still fails in the WinAVR simulator, whereas the ATmega8515 version does not.

I have supplied Atmel with a sample project and the files required to reproduce the problem ...

------------------

[This message has been edited by aek (edited December 20, 2006).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: AVR simulator: excessive stack overflow

Postby aek » Mon Feb 19, 2007 2:59 am

So far I have received no response from Atmel re the problems in their simulator ...

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Previous

Return to Atmel AVR and MegaAVR

Who is online

Users browsing this forum: No registered users and 0 guests

cron