Arduino Forum

Using Arduino => Installation & Troubleshooting => Topic started by: SurferTim on Jul 25, 2011, 12:34 pm

Title: Linux V0022 Mega 2560 crash (SOLVED?)
Post by: SurferTim on Jul 25, 2011, 12:34 pm
After  a couple days of testing, I found these commands cause the Mega 2560 to crash if compiled on Linux compiler:
Code: [Select]
Serial.begin(9600);
Client client(server,80);

Crashes on Linux compiled code. Runs fine on Windows compiled code.
OnLinux, I am using V0022 and avr-gcc 4.4.2

So no serial or ethernet client available on newest Linux compiler.  =(

What I mean by "crash" is it crashes on sketch upload, not when the command is executed.

Title: Re: Linux V0022 Mega 2560 crash
Post by: gerg on Jul 26, 2011, 01:32 pm
Where did you get your compiler? Are you using the compiler supplied with your distribution? If so, that's likely the problem.

You may find this thread (http://arduino.cc/forum/index.php/topic,66243.msg488563.html) to be enlightening.
Title: Re: Linux V0022 Mega 2560 crash
Post by: retrolefty on Jul 26, 2011, 02:09 pm
Quote
What I mean by "crash" is it crashes on sketch upload, not when the command is executed.


Well uploading usually leaves error messages in the IDE output window if unsuccessful, as uploading is a simple serial communications of the hex file data that avrdude uses to send to the bootloader code in the arduino board and stored in program flash memory area. If you get no errors on uploading (get the uploading complete message), then the code is indeed crashing as it tries to execute the code, more likely stuck in some infinite loop.

Usually one can embed diagnostic serial messages into the sketch code to determine how far the program is getting before 'crashing'.

Lefty

Title: Re: Linux V0022 Mega 2560 crash
Post by: SurferTim on Jul 26, 2011, 02:51 pm
The upload shows successful, but the code will not start on upload or reset.
I have experimented with this for two days, and finally came up with this code to determine where the crash was happening. The LED does not light. Remark out the "Serial.begin(9600);", and all is as you would expect.

Code: [Select]
void setup()
{
 pinMode(13,OUTPUT);
 digitalWrite(13,HIGH);
 delay(1000);
 Serial.begin(9600);
}

void loop()
{
}


EDIT: The code produced by the Linux version and the Windows version are different sizes.
Title: Re: Linux V0022 Mega 2560 crash
Post by: retrolefty on Jul 26, 2011, 02:55 pm
That would imply that you should be able to upload the example blink sketch and it would run ok?
Title: Re: Linux V0022 Mega 2560 crash
Post by: SurferTim on Jul 26, 2011, 02:58 pm
Blink runs great! This works perfect:

Code: [Select]
void setup()
{
 pinMode(13,OUTPUT);
}

void loop()
{
 digitalWrite(13,HIGH);
 delay(500);
 digitalWrite(13,LOW);
 delay(500);
}


EDIT: I know it says "newbie", but that is not exactly true. Only with Arduino. I wrote my first compiler (yes, wrote a compiler) for the MCS51 series controller in 1996.
Title: Re: Linux V0022 Mega 2560 crash
Post by: gerg on Jul 26, 2011, 03:19 pm
That's a basic confirmation of a buggy compiler. Again, I refer you to the thread linked above.

As this was seemingly, completely ignored, I'll stress this part once again:
Quote
Where did you get your compiler? Are you using the compiler supplied with your distribution? If so, that's likely the problem.

Title: Re: Linux V0022 Mega 2560 crash
Post by: SurferTim on Jul 26, 2011, 03:44 pm
Yes. I did download it from the repository for my version of Linux. These are the versions they show:
avr-gcc 4.4.2
avr-binutils 2.20
avr-libc 1.67

The repository has been very reliable in the past. Do you see anything here that should be upgraded? Did I miss a utility?
If so, I can recommend the repository team compile new versions. It might take a while tho.

EDIT: I missed the link on your first post. I see it now, and thanks!  :)

I do not really see a "problem solved" anywhere tho. The Windows version compiler works great. It is set a a tcp client with an ethernet shield, and after "flying" all night, it just "phoned home", and established 2-way comm immediately. Very impressive hardware.
Title: Re: Linux V0022 Mega 2560 crash
Post by: gerg on Jul 26, 2011, 04:08 pm

Yes. I did download it from the repository for my version of Linux. These are the versions they show:
avr-gcc 4.4.2
avr-binutils 2.20
avr-libc 1.67

The repository has been very reliable in the past. Do you see anything here that should be upgraded? Did I miss a utility?
If so, I can recommend the repository team compile new versions. It might take a while tho.



Based on my own experience, chances are very high they are handing out known buggy compilers. You can compile your own binutils, compiler, and libc; which I strongly recommend. Again, from my own experience, the distros are very much aware they have a crappy AVR compiler but just don't care. I guess from their perspective, the number of users who not only cross compile for AVR AND are using one of the MCUs which are buggy with their compiler is so small, its not worth their time.

As a stop gap, so as to allow you to use the Serial interface with your compiler, try this. Modify HardwareSerial.cpp. Make the following changes at the end of the file.
Code: [Select]
#if defined(UBRR1H)
 //HardwareSerial Serial1(&rx_buffer1, &UBRR1H, &UBRR1L, &UCSR1A, &UCSR1B, &UDR1, RXEN1, TXEN1, RXCIE1, UDRE1, U2X1);
 #warning serial port 1 disabled because of compiler bug
#endif
#if defined(UBRR2H)
 //HardwareSerial Serial2(&rx_buffer2, &UBRR2H, &UBRR2L, &UCSR2A, &UCSR2B, &UDR2, RXEN2, TXEN2, RXCIE2, UDRE2, U2X2);
 #warning serial port 2 disabled because of compiler bug
#endif
#if defined(UBRR3H)
 //HardwareSerial Serial3(&rx_buffer3, &UBRR3H, &UBRR3L, &UCSR3A, &UCSR3B, &UDR3, RXEN3, TXEN3, RXCIE3, UDRE3, U2X3);
 #warning serial port 3 disabled because of compiler bug
#endif


The Mega2560 has four hardware UARTS. This change means only one is available (Serial); without manually instantiating them inside your loop. Furthermore, instantiating other global objects will likely also trigger the compiler bug which screws up save/restore of a couple of registers. This in turn means you'll need to move some globals into the loop() scope. This in turn means lots of examples will not work without change. Furthermore, this means a lot of code will simply not work without yet more changes.

If compiling for the 2560 is important for your project, I strongly encourage you to compile your own compiler. The combination which works is documented in the thread. The important part is applying the patches. As noted in that thread, one hunk from one patch failed to apply for me. Regardless, once done you should have a compiler which at the very least is far more reliable than the one provided by your distribution.

Now if only the arduino devs would release a 0023 based on the current libc + gcc 4.6.x. In doing so, it would likely prevent the Linux problems altogether. But once again, I guess the cross section of users means they don't really care either.
Title: Re: Linux V0022 Mega 2560 crash
Post by: SurferTim on Jul 26, 2011, 04:16 pm
Thanks very much. I missed the link to the other post my first time through. I will try the patch, but my current app requires ethernet client to work also, so overall it will help, but not enough for this project.

Winavr works good. Gotta get back to my Windoze computer and do some coding. It is compiling everything correctly. Serial, ethernet client, and all....so  :) but  =(
Title: Re: Linux V0022 Mega 2560 crash
Post by: SurferTim on Jul 29, 2011, 05:59 pm
A followup. I downloaded the newest 8-bit compiler from Atmel.
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=17311&category_id=163&family_id=607&subfamily_id=760
Unzipped it and copied the files to the /usr/ folder.
Tried to compile a test program and crash! Got an error about delay.h when it compiled. An error about fabs and ceil.
No problem here. That is because they forgot the
#include <math.h>
So if you are following along, open
/usr/avr/include/util/delay.h
and add the #include <math.h>.
Try a compile, and crash!
Now something about "( or : expected before double".
So open
/usr/avr/include/math.h
and remark out this line:
Code: [Select]
extern double round (double __x) __ATTR_CONST__;
Can anyone see why that line generates an error?

EDIT2: IT IS WORKING!! Serial works, ethernet doesn't crash.  :)
I forgot to set the board type after the new install. Now it uploads and all...
Thisis what I show now:

avr-gcc (AVR_8_bit_GNU_Toolchain_3.2.3_314) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But you must do the changes to the header files or it will still crash.
Title: Re: Linux V0022 Mega 2560 crash (SOLVED?)
Post by: gerg on Jul 29, 2011, 07:28 pm
I should had said in the other thread that I also tried their compiler. It didn't work for me. I didn't spend much time on it but that also ignores they install the compiler into a system location they shouldn't be, which makes it all the more unattractive.

At any rate, I strongly encourage you to compile your own compiler.

Having said that, I may yet try again given your success.
Title: Re: Linux V0022 Mega 2560 crash (SOLVED?)
Post by: SurferTim on Jul 29, 2011, 07:41 pm
I disagree. If this were a compiler for Linux, I would agree. But it isn't. This codes for Atmel. Has nothing to do with the host machine. Kinda like Java in a way.

I really wish you would try it, just on a test machine if you have one. Wouldn't it be nice to be able to download this and have work right "out of the box"?
Title: Re: Linux V0022 Mega 2560 crash (SOLVED?)
Post by: gerg on Jul 29, 2011, 07:58 pm

I disagree. If this were a compiler for Linux, I would agree. But it isn't. This codes for Atmel. Has nothing to do with the host machine. Kinda like Java in a way.

I really wish you would try it, just on a test machine if you have one. Wouldn't it be nice to be able to download this and have work right "out of the box"?



Standard convention is they should not be installing anything into /usr. They should be installing into /opt or /usr/local. To install third party software into /usr is a horrible violation of standard and best practices; especially since it can directly conflict with system provided packages. There is nothing about it which is a good idea.

And as I said, I did previously try it and it failed right off. I don't recall the nature of the issue I experienced but it may be what observed. Its also worth noting, I'm running 64-bit which can sometimes further complicate things. Again, as I said, I may give it another whirl.
Title: Re: Linux V0022 Mega 2560 crash (SOLVED?)
Post by: SurferTim on Jul 29, 2011, 08:16 pm
Many thanks for your input. I had not considered the location of the code. I had gone only by what the repository had done. That may be a good thing to consider. My repository put the files in
/usr/avr/
/usr/bin/
/usr/include/
etc.

The types of files that it put in those locations fit. That is the same file location/type that came from Atmel also. ??

Any time you download executable files, or even source code to build them, you are taking a bit of a chance. It is best if you stick to reputable suppliers. That link above is to the Atmel website, where I downloaded this from.

WARNING!! It did NOT work in all cases. ethernet client has problems with client.available() and client.read().
Title: Re: Linux V0022 Mega 2560 crash (SOLVED?)
Post by: gerg on Jul 29, 2011, 08:47 pm
Quote
Many thanks for your input. I had not considered the location of the code. I had gone only by what the repository had done. That may be a good thing to consider. My repository put the files in
/usr/avr/
/usr/bin/
/usr/include/


That means it was installed into /usr. That's a no-no for a third party in general and a major no-no for software which is extremely likely to be in direct conflict with software provided by the system. They should be installing into /opt (historical) or /usr/local (more semi-recent Linux-esk convention).

Quote
The types of files that it put in those locations fit. That is the same file location/type that came from Atmel also. ??


Its has nothing to do with the "types of files", and everything to do with the fact that Atmel is not the maintainer of your distribution, which furthermore makes assumptions about the layout, disposition, and architecture of your distribution.

Quote
Any time you download executable files, or even source code to build them, you are taking a bit of a chance. It is best if you stick to reputable suppliers. That link above is to the Atmel website, where I downloaded this from.


That's true only from a security perspective, not a system maintenance and correctness perspective.

Here is but one example that bites people from time to time. Let say you installed the compilers provided by your distribution. Rightly so, they likely installed into /usr. For the sake of example, let's go with that. You now download Atmel's compiler and install it. Its now installed directly over the top of the system provided compiler +- an odd file here and there. Things are good. Now, at some point down the road your distribution notifies you of updates and you accept the updates. Some time later you notice that your "Atmel compiler" is now producing buggy code and only for some not so common code constructs. You hunt and hunt and you can only seem to determine its a compiler bug. You report the bug to Atmel which says no such problem exists.

Turns out the problem was, your distribution found some bugs and re-released their compiler suite which was a valid candidate for update since you had your distro's version installed. The update fixed the original problems which required the install of the Atmel compiler but there was still some odd bug which still lurked. This odd bug is now exposed as the distribution update installed right over the top of your Atmel compiler install which in turn was installed right over the top of the distribution's provided compiler.

The above is just the tip of the iceberg and is but one example of why its a very, very bad idea. There are very good reasons why there are places for vendors to install their software, and failing doing so when its in direct conflict with software provided by the distribution is always an extremely bad idea. This is also one of the classic reasons why Windows is traditionally a royal cluster-f for system correctness and maintenance.

Now then, that doesn't mean it can't be managed but that also doesn't make violation of standards and best practices a good idea. In fact, bluntly, its a very bad idea and shame on Atmel for doing so.

Title: Re: Linux V0022 Mega 2560 crash (SOLVED?)
Post by: SurferTim on Jul 30, 2011, 12:28 am
@gerg: I see your point. You would prefer the install in "/usr/local/". Hope we don't overwrite something there.

For the rest, the functions supplied by Atmel seem to be working.

The ethernet library functions (maintained by Arduino?) are not. The Client::read() apparently does not remove the characters from the ethernet buffer. Even if I quit sending characters from the server, "client.read()" keeps returning the same several characters over and over.

EDIT: I sent the two corrections to Atmel with a mention of the ethernet client.read() problem. Maybe they will feel obliged to do that for me?