I uploaded (successfully) the sketch RAMTest.pde - this worked and confirmed that the RAM was OK. So far, so good. But then attempting to upload another test sketch (RAMDemo1) I kept getting timeout errors:
Even after pressing the reset button, or completely powering down the device, I am unable to upload the sketch. I then removed the MegaRAM board (in case it was interfering somehow) and the sketch still won't upload.
However after powering down, the Blink sketch does upload. It all seems very strange.
I read in some other threads about the watchdog timer not being properly handled in the bootloader. Could someone give precise instructions about how to fix this? Is there a bootloader that should work? I have seem some references to downgrading the bootloader rather than upgrading it. I can use USBtinyISP to install another bootloader, if someone can say where the correct one is located.
I haven't had the timeout problem in a really long time, and when I did, something I messed around with made it work again. So, I'm not much help there. There is a big problem with the loading onto the board though regarding three exclamation points in a row. You can test this easily enough by just putting a text string in your code with "!!!" in it. It won't load. This is insidious because this can be in data as well. I had it happen in the actual code generated and it was really tough to find and work around. Yes, the watchdog doesn't work on the 2560 and I have been trying to get it fixed for months.
The latest news is that there is a fix for the exclamation point problem and the watchdog timer, but I tried to burn it and it failed. So I asked about it on the developers network and they said they would work it out. I have a thread about this at http://arduino.cc/forum/index.php/topic,62813.0.html Go take a look.
As for advice, nothing I've done has had much affect, so maybe yelling irrationally and banging on the wall????
I just received the Rugged Circuits Ram board monday. I was able to load and run the RAMDemo1 sketch OK on my Arduino mega1280 board. I assume it's a different bootloader, so maybe that's where to look at.
results:
Filling RAM with sinusoid ...
Computing FFT ...
Finding largest component ...
FFT says strongest frequency component is at 820.31 Hz
Using my USBtinyISP as the programmer, I successfully uploaded the RAMDemo1 sketch to the Mega2560, and got these results:
Filling RAM with sinusoid ...
Computing FFT ...
Finding largest component ...
FFT says strongest frequency component is at 820.31 Hz
So that would seem to confirm that:
The USBtinyISP is working
The Mega2560 is working
The MegaRAM board is working
So then I tried to upload a bootloader using the Arduino IDE (so whatever came with the IDE) - selecting USBtinyISP as the programmer - and after a fairly lengthy delay, saw this:
avrdude: verification error, first mismatch at byte 0x3e000
0x0d != 0xff
avrdude: verification error; content mismatch
I tried again and got the same results. So it seems that the IDE can't even upload a bootloader - it isn't really clear why this should be the case. After all, the same hardware uploaded the RAMDemo1 sketch.
Despite the error message, I can use the bootloader to upload Blink, so the board is still usable. However I can't upload RAMDemo1 using the IDE.
So we seem to have multiple problems with the bootloader, both in what it does, and even uploading it to the board.
avrdude: verification error, first mismatch at byte 0x3e000
0x0d != 0xff
avrdude: verification error; content mismatch
I've gotten this particular error many, many times. When experimenting with the bootloader they said would work, this error happened when I put the original bootloader back so I could use my board. I found a couple of places on the web where it was claimed that one could ignore this particular message and my experience says the same. Nowhere did I find an explanation of this error though, perhaps it's one byte too far or something?? However, I have been able to load a bootloader on the board successfully.
And, thanks for the idea on using the isp programmer to load the board. If I had been smart enough to try that I wouldn't have had to hex dump, hand disassemble and mess around for hours to get code onto the board when I first encountered this kind of thing.
I don't have too much experience with the Arduino's yet, am learning slowly.
but
I am having a similar problem as this one, with the same error message when trying to upload a program. One minute my edited programs were loading fine and running, then all of a sudden the connection error...
avrdude: stk500_2_ReceiveMessage(): timeout
I believe its a MAC issue... where the ttyl.serialUSB**** in the tools/serialconnection disappears. My original fix, was to change my USB port from the hub and connect the ARDUINO direct to the back of the machine. This reloaded the network preferences again, selected "apply" and it began to communicate properly. This may work for you as well.
However, since editing and running, the system lost the connection again and now I'm stuck as I can't get it back again. Is this a common problem, any other suggestions of possible tweaks would be appreciated.
All observations gratefully received. Your comments would seem to confirm that this problem is not restricted to a couple of people, like draythomp and myself.
I am inclined to conclude that the Mega2560 is not widely used, or more people would be screaming about this.
The 2560 bootloader has had some serious flaw(s) sense introduction (the !!! comes to mind, triggering the monitor) and I feel the Arduino team has been quite slow and casual about getting it fixed. They seem to just defer to the original author of the bootloader and not really try to expedite the solution, although a fixed bootloader is suppose to be avalible? Too sidetracked because of the Arduino 1.0 project rather then on maintenance issues of the exiting products in my opinion.
retrolefty, I totally agree with you. I also think the board is not widely used, however I do know for a fact that a couple of people just gave up and moved on because they decided there were other ways to do what they wanted to do that weren't so frustrating. I've actually communicated with the developer of the bootloader and he tells me that he fixed the exclamation points a year ago and the watchdog was taken on about the same time by another developer. Neither of these is available as something we can actually try out because the .hex file they pointed me to won't load.
When people ask me I suggest they get some other board to work with and give the 2560 time to grow up.
Congratulations !!! (exclamation points intentional). Didn't that use a dragon board though? With the price of the mega and a dragon board, it puts the solution out of reach for many people. Maybe I should go rattle the cages on the development list again.
Yes it did. But as I pointed out, the Dragon board can be obtained for $US 51, compared to $US 22 for the USBtinyISP. The USBtinyISP from Adafruit costs $22, and then you have to assemble it. For just $29 more, you can get the assembled AVR Dragon.
Considering that the Mega board itself costs $65, I don't think an extra $51 to program it, and other boards, is altogether excessive. After all, one Dragon can program many boards. In fact the Dragon board can do High Voltage programming, so you can recover a chip that you might have foolishly changed the fuses on, so it can't be programmed any other way.
I also found that programming via the Dragon only took two seconds, compared to over 8 minutes using the USBtinyISP. If you were debugging or making a lot of changes, you would quickly grow tired of waiting 8 minutes every time you wanted to test.
OK, I may not be paying attention well enough. Help me here.
You put a new bootloader on the 2560 using the Dragon board. I got that part. Now, how did you load the sketch? Using the Dragon board also or did you use the bootloader you found on cbxdragbike's site?
cbxdragbike is the author of the 2560 bootloader that you and I started with and somehow I got the impression that the bootloader you grabbed from his site had a 128K limit on it so we couldn't use the entire 256K of the board. However, I'm not the sharpest tool in the shed so I may have gotten a neuron crossed somewhere. Because, if you can load the hello sketch with the arduino IDE and it gives us all the memory on the chip, half of the nasty problems are gone already.
draythomp:
cbxdragbike is the author of the 2560 bootloader that you and I started with and somehow I got the impression that the bootloader you grabbed from his site had a 128K limit on it so we couldn't use the entire 256K of the board.
Hmmm, I see what you mean. From the source it looks like the address bytes are only two bytes (ie. going up to FFFF) which is only 64 Kb. I don't see how this even gets past 64 Kb, except that the length is also 2 bytes, so I suppose if you address 0xFFFF for length 0xFFFF you would get up to 0x1FFFE.
Oh well, I have the technique right now, so what I need now is a bootloader (hex) file that supports the full 256 Kb.
From what I have been able to work out, and this isn't easy, to find stuff out, the protocol stk500 has a 2-byte address, whereas the protocol stk500v2 has a 4-byte address. So perhaps we need a v2 bootloader. However one that doesn't have the issue with watchdog timers etc.
That's exactly what I remember from when I looked at it several months ago. However, there still a lot of room there and it will load stuff, so maybe it'll hold you until they get something that we can try out. It would actually be nice if the bootloader you got had the watchdog working on it. Then the only problem is the memory range.
