Pumpkin, Inc.

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).]

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.

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

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

---

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

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).]

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

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