RE: [avr-gcc-list] winavr 20080411 and atmega324p

[alexander]

I am using the SPI and I assume I have it set ok as I use the same settings
I was using on an atmega328p and I got no problems there. For further
verification I added some eeprom writes to the code to find out where I am
actually crashing.
2 things I noticed:
1) I crash after I finished accessing the spi, so I assume that is not the
"initial" problem
2) the whole eep got messed up and I had suddenly values where I never wrote
anything to - I assume that must have to do with the program crashing whilst
I was writing to the eep probably. (iam using eeprom.h)

On another test, I verified the initial values I store in the eep. In 1
instance they were written ok, in another they weren't - could also be the
result of a crash whilst I was writing to the eep.

When I do not use the SPI the code seems to run but that is hardly any
evidence on what's really happening because most of the stuff I do happens
around the SPI. So test code with my init of the spi and all ports as well
as some i/o's switching on/off (for debugging purposes to see if I make it
through all my subroutines in main (except the most important one where I
utilize the spi) runs fine for several minutes. In addition I set the
watchdog to 4s. (I flip the i/o's every second, so in case I crash I would
see no status change for at least 4 seconds) - and also that confirmed that
the code was running fine.

I also tried something else and that might be the key to find out what's
wrong:
I used my full code, stripped it a bit down but the main part where I use
the spi is intact. I access the spi 8 times per cycle. Then I set one i/o
pin to low right before I call the sub for the spi and high after I finished
this and all other subs (end of main).
At first I saw the signal to be low, fluctuating every 4 seconds (wdt
timeout). That made me think. So I changed that i/o low part to happen after
the spi sub. What now happens is that the signal stays high!
So effectively that means that I go through the SPI sub and all my other
subs at least once. So the spi access I am doing does not necessarily and
directly make the code crash. However on the next or one of the following
cycles the code crashes in that SPI subroutine because if it would crash
later I would see my i/o high and not low (first test).
So as it seems not to happen right away I assume some pointer/stack overflow
of some kind is happening? I am a noob when it comes to that, just what I
observed now.
I ran the same testcode on an atmega168p and it was basically running
indefinetly without a wdt reset.
Again any suggestions or help is highly appreciated!
THANKS


-----Original Message-----
From: address@hidden [mailto:address@hidden 
Sent: Saturday, April 19, 2008 7:37 PM
To: address@hidden; address@hidden
Subject: Re: [avr-gcc-list] winavr 20080411 and atmega324p

Alexander,

> Does the latest winavr work with the mega324p right out of
> the box? I saw there are patches in the source folder - do 
> they have to be installed? If so, which patches in order to 
> make the 324p work?

Not sure if you're trying to do work on the WinArv itself
or justing trying to get something installed that works so
forgive me.

I'm have working production code built off of WinAVR-20071221
I did have some issues with it being a bit more aggressive in
optimizing away variable that should have had a volatile ];'

And also the register names for the SPI bus were changed to
reflect that the ATmeaga324p only has one SPI bus. IE, SPSR0
became SPSR, etc etc.

Matt