avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] xmega128A1 + WinAvr 20081205


From: Russell Shaw
Subject: Re: [avr-gcc-list] xmega128A1 + WinAvr 20081205
Date: Tue, 03 Feb 2009 11:08:31 +1100
User-agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)

larry barello wrote:
Is anyone successfully using WinAvr and Xmega (and fp/printf) in a significant project? I already corrected the vararg problem and have my project running, but there is a rare stack corruption problem with the xmega that I don’t see on the mega series (mega128 and mega1280). Interrupts and i/o change protection are the big differences between the two series so that seems like a possible source of errors.


I have five serial sources and a 1khz system timer and a multitasking kernel that relies on nesting interrupts (run to completion model) and a GUI. So it is pretty busy and, as I said, works sweet on the m128. The problem is subtle. There is no evidence of stack overrun. Just one task eventually ends up somewhere it shouldn’t be and dies. Evidence pointing to it being my problem is that it is always the same task and indirectly the same routine because if I cut the routine out, the problem either disappears or becomes so rare I never wait long enough… The routine is a character glyph bitblit. The evidence that it isn’t my code is that I have two other bitblit routines (windows bmp, and a specialized fill routine) that have the same code in their core (about a dozen lines) and they don’t fail. Failure occurs in minutes to hours after starting a test screen.

Anyway, I am running out of ideas and starting to consider moving to the mega1280. I don’t want a big discussion, but would be interested in knowing if others have success, or have seen problems. That will help me decide if I am going to pursue this more (i.e. my code issues, or possible compiler issues) or drop it (chip issues).

Does the code poke any hardware? Some hardware is globally shared but
hidden such as when a 16-bit peripheral is loaded, causing strange
corruption problems.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]