| Author |
Message |
|
|
 Posted: Apr 29, 2012 - 10:02 AM |
|
Joined: Jun 15, 2007
Posts: 42
Location: Moscow, Russia
|
|
Hi all,
i work on respectively big project (18144 bytes of code with -Os option on mega32). i use AVRStudoi4, AVR Toolchain Release 3.3.0.710, avr-libc 1.7.1. My project use periphery - internal and external - actively. My problems started few weeks ago. I fill some structures during initialization and use it without changes after that.
Code:
typedef struct {
volatile int x;
volatile int y;
volatile int z;
}Magnet;
Magnet minMagnet, maxMagnet;
Magnet min, max, delta;
Magnet magnet;
void fillMagnetEdges(){
minMagnet = hmc[0];
maxMagnet = hmc[0];
for(uint8_t i = 1; i < tailIndex; i++){
if(minMagnet.x>hmc[i].x) minMagnet.x = hmc[i].x;
if(minMagnet.y>hmc[i].y) minMagnet.y = hmc[i].y;
if(minMagnet.z>hmc[i].z) minMagnet.z = hmc[i].z;
if(maxMagnet.x<hmc[i].x) maxMagnet.x = hmc[i].x;
if(maxMagnet.y<hmc[i].y) maxMagnet.y = hmc[i].y;
if(maxMagnet.z<hmc[i].z) maxMagnet.z = hmc[i].z;
}
}
this portion was written earlier, tested well and caused no problems. When i worked on other part (even other module) i noticed unexpected unpredictable changes of some members of the structure maxMagnet. Namely maxMagnet.y or maxMagmet.z high byte was replaced with 0x98 or 0x9b. I added 'const' modifier to it and rewrote code to fill using pointer - no efect. I isolated the structure and filler to separate module so it helped.
Now i added I2C error handlers to improve stability to magnetometer driver (really needed):
Code:
void HMC5883ReadMagnet(){
I2C_ERROR_HANDLE:
if(i2cError){
i2c_stop();
_delay_us(20);
i2c_disable();
wdt_reset();
_delay_ms(1);
i2c_init();
i2cError = 0;
}
int value;
//static int prev;
i2c_start_wait(HMC5883ADDR | I2C_WRITE);
i2cError = i2c_write(HMC5883_X_MSB);
if(i2cError)
goto I2C_ERROR_HANDLE;
i2cError = i2c_rep_start(HMC5883ADDR | I2C_READ);
if(i2cError)
goto I2C_ERROR_HANDLE;
//i2c_readAck ();
value = i2c_readAck2();
if(i2cError)
goto I2C_ERROR_HANDLE;
if(value != -4096) {
magnet.x = value;
}
else {
magnet.x = ((magnet.x > 0)?2047:(-2048));
}
value = i2c_readAck2();
if(i2cError)
goto I2C_ERROR_HANDLE;
if(value != -4096)
magnet.y = value;
else {
magnet.y = ((magnet.y > 0)?2047:(-2048));
}
value = i2c_readNak2();
if(i2cError)
goto I2C_ERROR_HANDLE;
if(value != -4096)
magnet.z = value;
else {
magnet.z = ((magnet.z > 0)?2047:(-2048));
}
}
and surprised: filler that i described previously worked fine but axis magnet.y was always achieving with high byte == 0. I wrote simple "int i2c_readAck2()" function to replace 2 sequential calls
value = i2c_readAck ()<<8;
value |= i2c_readAck ();
and used it to fill magnet.y. It helped but the same problem appeared with magnet.x. Repeated with x - appeared with z, repeated with z - magnet started work OK but filler problem came back. I tried all optimizer options except -O0 - no effect.
Now i confused completely. I hope i wrong and it's my fault but it looks like inadequate compiler behavior. I think to migrate to IAR but it takes a time while project is almost done. So please help me with some tricks or maybe compiler settings change.
Thanks in advance. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 10:11 AM |
|
Joined: Feb 12, 2005
Posts: 16280
Location: Wormshill, England
|
|
Atmel's Toolchain has many features. No-one knows whether they have any intention of fixing them.
Compile your code with WinAvr-20100110 which is well proven and reliable for a mega32.
David. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 10:13 AM |
|
Joined: Jun 15, 2007
Posts: 42
Location: Moscow, Russia
|
|
thanks,
i'll try it first. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 12:45 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
It's likely you hit PR46779. This bug is "unstable", i.e. slighly changing the code in other places, may make the bug appear or disapper. Thus, changing the code is not reliable as the bug might come back again later.
In order to verify that it's actually PR46779, look at an assembler listing or disassembly. For affected variables, there are typically moves to and from R28/R29, where in one direction an 8-bit move is missing. The missing instruction is close (clode with respect to data flow, not with respect to code flow) to the R28/R29 move.
PR46779 is fixed in 4.6.2. For private distributions/ports, consult the bugtracker for your distribution/port.
Besides that there are some issues with the application code:
I'd guess it generates really bloated code because of how you use volatile/volatile variables.
besides that, depending on surrounding code, you may hit gliches because the code is not interrupte save: (x,y,z) are obvioulsy a vectors that shall be handled as a whole, not as several unrelated variables x, y, and z. |
_________________
avr-gcc News • ABI • Options • 4.8-Windows • Inline Asm
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 02:39 PM |
|
Joined: Feb 12, 2005
Posts: 16280
Location: Wormshill, England
|
|
@SprinterSB,
Unless a punter wants to build her own avr-gcc from source, surely the easiest solution is to use the last known 'good' release. e.g. WinAvr-20100110
In the years to come, Atmel may choose to include a fresh build of avt-gcc in their Studio 5 or Studio 6. OTOH, they may just not bother.
David. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 03:31 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
david.prentice wrote:
Unless a punter wants to build her own avr-gcc from source, surely the easiest solution is to use the last known 'good' release. e.g. WinAvr-20100110.
I just mentioned what version of GCC comes with a fix of this bug, which is 4.6.2.
The bug is in GCC since 10 years at least, see respective commit, which was GCC 3.2 and then was backported to 3.1.
As this bug is unstable unter other, unrelated changes in the compiler, in the application code and in the command options used, the bug might just as well pop up with any version below 4.6.2, which includes 4.3 and 4.4. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 03:55 PM |
|
Joined: Jun 15, 2007
Posts: 42
Location: Moscow, Russia
|
|
|
Quote:
In order to verify that it's actually PR46779
ok, i'll check it. now i removed toolchain and experimenting with winavr as david.prentice recommended. Can i just replace avr-gcc in winavr to last version or it will damage assembly?
Quote:
I'd guess it generates really bloated code because of how you use volatile/volatile variables.
i added volatiles to guarantee store/restore data to RAM cause i thought data damaged being in registers
Quote:
you may hit gliches because the code is not interrupte save
i tried atomic reading too - no difference. i use interrupts only with USART and timers so no issues at this side
Is it possible that my problems are due to stack overflow My bss section is 1830 bytes, i do not use allocs so i have 2048-1830=218 bytes for stack. In other hand i avoided recursion and thought stack is not a bottleneck for me.
Code:
Program: 23976 bytes (73.2% Full)
(.text + .data + .bootloader)
Data: 1830 bytes (89.4% Full)
(.data + .bss + .noinit)
EEPROM: 938 bytes (91.6% Full)
(.eeprom)
by the way, stack pointer initialized with 0x85f as RAMEND defined in <iom32>. the actual RAM size is 0x800 and RAM starts from 0. so how stack pointer can exceed 0x7ff? |
|
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 04:48 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
masmart wrote:
Quote:
In order to verify that it's actually PR46779
Can i just replace avr-gcc in winavr to last version or it will damage assembly?
You can "install" as many GCCs as you want. Just drop them at some place (nut not one inside another and with reasonable, *nix-friendly pathnames) and call the compiler from respective bin subrirectory by its absolute path name.
That way you can easily switch back an forth between several toolchains by adjusting the path in your Makefile.
Quote:
Quote:
I'd guess it generates really bloated code because of how you use volatile/volatile variables.
i added volatiles to guarantee store/restore data to RAM cause i thought data damaged being in registers
Quote:
you may hit gliches because the code is not interrupte save
i tried atomic reading too - no difference. i use interrupts only with USART and timers so no issues at this side
The volatile gave rise to the assumpltion that the data is used across several IRQ-levels.
volatile for data that is just used in one IRQ level makes no sense; just leads to code bloat.
And: The compiler must use registers. Even with volatile, data must be loaded to registers in order to operate on them.
Quote:
Is it possible that my problems are due to stack overflow My bss section is 1830 bytes, i do not use allocs so i have 2048-1830=218 bytes for stack. In other hand i avoided recursion and thought stack is not a bottleneck for me.
Try to put big constant array into flash. Search for PROGMEM and pgm_read_byte et al. functions from AVR-LibC.
Also have a look at the mem-check module to get a hint on actual stack usage:
http://www.rn-wissen.de/index.php/Speic ... -Verbrauch
Quote:
by the way, stack pointer initialized with 0x85f as RAMEND defined in <iom32>. the actual RAM size is 0x800 and RAM starts from 0. so how stack pointer can exceed 0x7ff?
No, RAM starts at 0x0060. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 06:26 PM |
|
Joined: Jul 18, 2005
Posts: 62245
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
It is rather a shame that the most recent main distribution on Windows is only a 4.5.x and worse still its built by Atmel.
I do wonder exactly how much effort it would be for someone who already has the infrastructure to build on Windows to make a complete WinAVR2012 style distribution to replace the WinAVR2010 we're all hanging on to. |
_________________
|
| |
|
|
|
|
|
|
Posted: Apr 29, 2012 - 06:41 PM |
|
Joined: Feb 12, 2005
Posts: 16280
Location: Wormshill, England
|
|
I was not aware of this bug in WinAvr-2010. (avr-gcc 4.3.3)
Perhaps it has just never bitten me, nor many other WinAvr-2010 users.
It does seem to appear often in Toolchain.
David. |
|
|
| |
|
|
|
|
|
|
Posted: May 02, 2012 - 06:20 PM |
|
Joined: Jun 15, 2007
Posts: 42
Location: Moscow, Russia
|
|
| I tried WinAvr 2010 and for now it's stable. I still testing. |
|
|
| |
|
|
|
|
|
|
Posted: May 02, 2012 - 07:04 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
|
|
|
|
|
Posted: May 02, 2012 - 07:24 PM |
|
Joined: Dec 20, 2002
Posts: 7276
Location: Dresden, Germany
|
|
> I was not aware of this bug in WinAvr-2010. (avr-gcc 4.3.3)
I've never heard of the bug before (AVR-)GCC 4.4.x. If Johann tells us it's
been sitting around for ages, I'm sure he's sure about that ;-), but for
whatever reason, it appears the bug never really manifested itself in those
old days. Then, some change on the way to GCC 4.4 suddenly made it appear
much more frequently, so people started noticing it. |
_________________
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
|
| |
|
|
|
|
|
|
Posted: May 02, 2012 - 08:09 PM |
|
Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA
|
|
|
clawson wrote:
It is rather a shame that the most recent main distribution on Windows is only a 4.5.x and worse still its built by Atmel.
I do wonder exactly how much effort it would be for someone who already has the infrastructure to build on Windows to make a complete WinAVR2012 style distribution to replace the WinAVR2010 we're all hanging on to.
I'm always open to doing projects like this. Perhaps you could explain what "the infrastructure to build on Windows", i.e. development tools needed, are required in this context. (Saves me the time of replicating work - ok, I'm a little bit lazy now while my pump is healing)
Collaborative work might be the key to this happening. |
_________________
Larry
Those afraid to embrace the future will quickly fade into the past. - larryvc
Last edited by larryvc on May 02, 2012 - 10:51 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: May 02, 2012 - 09:03 PM |
|
Joined: Jul 18, 2005
Posts: 62245
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
Larry,
But that's exactly the issue. Only a few arch mages steeped in the runes know exactly what you have to do to build a fully patched avr-gcc on Windows. If it were easy we'd all be doing it ourselves.
Cliff |
_________________
|
| |
|
|
|
|
|
|
Posted: May 02, 2012 - 10:59 PM |
|
Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA
|
|
Thanks Cliff,
Unfortunately most of the arch mages I know are from the Sir William school of thought. 
I think it would still be worth looking into. Maybe those in the know could step up and help. |
_________________
Larry
Those afraid to embrace the future will quickly fade into the past. - larryvc
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 06:46 AM |
|
Joined: Jan 14, 2008
Posts: 1147
Location: San Diego
|
|
The avr-libc manual has instructions for building an avr-gcc toolchain.
I don't think making a Windows toolchain is that much more complicated compared to Linux. It's basically just needing a mingw/Cygwin environment set up. |
_________________
~~John
TWI C source code
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 07:35 AM |
|
Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA
|
|
I figured that mingw would be in the equation. I already put together a pretty robust dev environment last year. I needed it to build a modified avrdude to support my programmer. The latest and greatest avrdude still does not support it, I will add my mods again.
I guess I have some reading to do.
Thanks |
_________________
Larry
Those afraid to embrace the future will quickly fade into the past. - larryvc
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 07:58 AM |
|
Joined: Jan 23, 2004
Posts: 9822
Location: Trondheim, Norway
|
|
|
Quote:
It is rather a shame that the most recent main distribution on Windows is only a 4.5.x and worse still its built by Atmel.
It's still in testing, but:
Code:
avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2
So it's not all bad. I've said it before and I'll say it again - if you have a bug report to make about the Atmel Toolchain just let me know (or place it in the AS6 tracker here) and I'll add it to the Toolchain team's tracker. I want it to improve just as much as everyone else, but it won't unless the Atmel team are aware of all the issues.
- Dean  |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 08:05 AM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
IMHO, if anybody wants to invest time into avr-gcc and suite testing, it's more worth to go for Georg-Johann's 4.7+ builds from http://sourceforge.net/projects/mobilec ... 8Win32%29/ discussed in http://www.avrfreaks.net/index.php?name ... p;t=115337 .
May miss some of the xmegas' support, on the other hand it comes with the native _pgm etc. named address spaces support and link-time optimization.
JW
PS. Moderator: This has drifted too far off topic and is worth splitting. The OP's problem is in my opinion stack-overwrite related, far more probable than triggering an obscure compiler bug. |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 08:44 AM |
|
Joined: Dec 20, 2002
Posts: 7276
Location: Dresden, Germany
|
|
> The OP's problem is in my opinion stack-overwrite related, far more
> probable than triggering an obscure compiler bug.
I disagree. As Johann already suspected, it's very likely bug #46779.
It is really "unstable" in that changing just a couple of lines in the
sourcecode might decide between working and broken code. Been there
myself. |
_________________
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 08:52 AM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
Fancy a bet, Jörg?
Jan |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 08:59 AM |
|
Joined: Mar 27, 2002
Posts: 18537
Location: Lund, Sweden
|
|
|
Quote:
I want it to improve just as much as everyone else, but it won't unless the Atmel team are aware of all the issues.
Works both ways, Dean. People will be more inclined to contribute if they know they are reporting something new, rather than something known. As our resident mole - go over to the tools folks and tell them to have a published version of their bug tracker list.
-----
As for building the avr-gcc tool chain, I've been contemplating it. The instructions in the avrlibc documentation seems to be good, but it is when I look into the totally mysterious world that is "patches, how and which to apply, etc...", that I give up before really having started. |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 10:42 AM |
|
Joined: Dec 20, 2002
Posts: 7276
Location: Dresden, Germany
|
|
> patches, how and which to apply
Start building without patches. If all works out, you can see what you
really need.
At the rate Johann has been integrating bugfixes, and even the Xmega patch
series lately, I think you'll be fine with an unpatched GCC version now in
most situations (i.e. for everything except really new AVR devices which
did not make their way back upstream). |
_________________
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 11:32 AM |
|
Joined: Jan 23, 2004
Posts: 9822
Location: Trondheim, Norway
|
|
|
Quote:
Works both ways, Dean. People will be more inclined to contribute if they know they are reporting something new, rather than something known. As our resident mole - go over to the tools folks and tell them to have a published version of their bug tracker list.
I know, I think it's silly too - but the tools team is worried about exposing sensitive internal information (which can happen, since it's internal people throw around internal documents all the time). Our Apps department is a little different since we are open source anyway.
For now, I'm going to have to act as a human JIRA bot, shuffling reports in an out of the system (censoring as required).
- Dean |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 11:44 AM |
|
Joined: Mar 27, 2002
Posts: 18537
Location: Lund, Sweden
|
|
Thanks, Dean!
[Please ignorethe rest, this is just a rant]
Quote:
Our Apps department is a little different since we are open source anyway.
Last time I checked GCC and Binutils was GPL or whatever. Are the lawyers, the web designer and the tools team sharing a floor and a coffee room?  |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 11:52 AM |
|
Joined: Jan 23, 2004
Posts: 9822
Location: Trondheim, Norway
|
|
|
Quote:
Last time I checked GCC and Binutils was GPL or whatever. Are the lawyers, the web designer and the tools team sharing a floor and a coffee room? Evil or Very Mad
I don't know much about it, but it appears the patches for the Atmel Toolchain are located in the "source" folder - in both the standalone and Atmel Studio releases of the toolchain.
- Dean |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 12:00 PM |
|
Joined: Jul 18, 2005
Posts: 62245
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I don't know much about it, but it appears the patches for the Atmel Toolchain are located in the "source" folder - in both the standalone and Atmel Studio releases of the toolchain.
Except that if you are a Linux user those files are embedded inside an installation .exe that requires Windows to run
(OK I know they are published separately on the web but that is not properly version managed - you cannot tell which variant of 5.1 any set applies to fo example). |
_________________
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 12:19 PM |
|
Joined: Feb 12, 2005
Posts: 16280
Location: Wormshill, England
|
|
Surely you could have a simple list of reported bugs.
As far as I can see, the Bugzilla has no evidence of the incorrectly spelled interrupt vectors in the avr-gcc <iomxxxA.h> header files.
In fact it does not even seem to have anything much with avr-gcc Toolchain.
David. |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 01:22 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
abcminiuser wrote:
Quote:
Works both ways, Dean. People will be more inclined to contribute if they know they are reporting something new, rather than something known. As our resident mole - go over to the tools folks and tell them to have a published version of their bug tracker list.
I know, I think it's silly too - but the tools team is worried about exposing sensitive internal information (which can happen, since it's internal people throw around internal documents all the time).
They use a bugtracker like bugzilla to throw around internal documents all the time?
There is no document management system? Or email? Or sharing files?
And there would be no different between an internel lissue tracker and an official one outside the firewall?
Well, ... |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 01:33 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
SprinterSB wrote:
abcminiuser wrote:
Quote:
Works both ways, Dean. People will be more inclined to contribute if they know they are reporting something new, rather than something known. As our resident mole - go over to the tools folks and tell them to have a published version of their bug tracker list.
I know, I think it's silly too - but the tools team is worried about exposing sensitive internal information (which can happen, since it's internal people throw around internal documents all the time).
They use a bugtracker like bugzilla to throw around internal documents all the time?
There is no document management system? Or email? Or sharing files?
And there would be no different between an internel lissue tracker and an official one outside the firewall?
Well, ...
I believe the problem is not that whole internal document may get public inadvertently, rather, that snippets of potentially sensitive (and sometimes even more so without proper context) internal information may be leaked by the insider writing to a public place by mistake.
Not that I like the status quo, just understand why the resistance...
JW
PS. Moderator, now this thread got so HOPELESSLY OT, deserving to be cut to quite a couple of pieces... |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 06:28 PM |
|
Joined: Dec 06, 2007
Posts: 2512
Location: Redmond, WA USA
|
|
|
wek wrote:
PS. Moderator, now this thread got so HOPELESSLY OT, deserving to be cut to quite a couple of pieces...
I couldn't agree more.
I would like to continue to have a discussion about building an avr-gcc for windows, but I feel this is not the place for it. |
_________________
Larry
Those afraid to embrace the future will quickly fade into the past. - larryvc
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
