I've found that I'm unable to write a new .hex file to my MCU maybe.. 95% of the time? Maybe more?

Some important facts:

• make works just fine, the .hex file is built
• avrdude reads from the MCU fine, and deletes the existing data
• The battery is definitely NOT flat (using a desktop power supply set around 9v, confirmed with 2 DMMs)
• Output from the 7805 is just shy of 5V (4.96V or so)
• On a scope, I measure the freuqency of the crystal at 14.7477MHz - slightly high but I assume this is OK?
• I'm running Linux (Ubuntu 11.10, 64-bit). Is this a known issue? I was really, really happy at how easy it is to get everything working under Linux (basically just apt-get and you're done :) - would be a shame if it is easy but broken!

So far, I have written initialload.hex to the MCU successfully, two times. After writing it one time, I pulled the power to the MCU, re-connected, re-ran make and BAM! back to not working (ahh, the point is - I didn't change anything at all, it just worked, then stopped working).

I've tried different USB ports, I've tried pulling it apart and re-assembling, leaving the LCD detached, jiggling wires, using a bigger cap over the power-supply pins (7 and 8), etc. It just seems to be fundamentally unreliable.

Anyway, what I'm wondering is - should I just solder everything onto a PCB, and make some jumper wires from the PCB back to the breadboard (for future prototyping)? What tricks have people used to make writing to the MCU more reliable? Do I perhaps just have a dud MCU or USB cable?

James -

Before you jump to soldering to a PCB, there might be a few things to try first. Try posting a pic of your board (might be something simple). Also, if you can post the entire error message you get when you try uploading (from where you type "make" to the final line).

You certainly narrowed down the possibilities with your diagnostics :D

James -

One thing jumped to mind. Do you have a Windows box you could try? If so, this would eliminate the bum MCU/USB theory.

Hey pcbolt,

Thanks for the idea - I've just written to the MCU successfully 3 times in a row (just writing the initialload program) under Windows 7.

This is a shame - I really don't want to have to boot into Windows just to program the MCU.

Has anyone else had similar reliability issues under Linux? And, more imporantly, figured out any way to resolve these issues?

Thanks

Ok, I'm back in Linux and..

Connecting to programmer: .
Found programmer: Id = "FDL v02"; type = S
    Software Version = 0.2; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x35

avrdude: devcode selected: 0x35
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9406
avrdude: safemode read 1, lfuse value: 3f
avrdude: safemode read 2, lfuse value: 3f
avrdude: safemode read 3, lfuse value: 3f
avrdude: safemode: Fuse reading not support by programmer.
              Safemode disabled.
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "initialload.hex"
avrdude: input file initialload.hex auto detected as Intel Hex
avrdude: writing flash (7886 bytes):

Writing |                                                    | 0% 0.00savrdude: ser_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
make: *** [initialload-upload] Error 1

:(

P.S. Obviously, I have not changed anything on the breadboard while rebooting. All I have done is disconnect & reconnect the power-supply to the MCU to reset it.

Try unplugging and replugging your USB, check your com port also a reboot might be necessary!

Ralph

James -

I've seen some posts on this both here and on othe forums but no real solution. It has something to do with the fuse reading stage and safemode or the Com port being renamed. Unfortunately I'm not a Linux guy just yet, so I'll have to defer to others for more expertise. You can try Googling "avrdude linux problems" etc to see if someone has seen this before. If you do find an answer...please post it here.

Hi JamesFysh,

I have a thought, you may be running into a similar issue that some Mac users have been running into. Try altering your Makefile to put in a sleep between the read and write cycles? Take a look at this forum post where this similar issue is discussed. About half way down on Jaunary 24th Mike suggests a fix to the Makefile you can make that might fix this problem.

Humberto

Hi Humberto.

Yep, that did the trick! Have been able to load initialload.hex twice in a row now, on Linux

It's a shame there's no command-line option (in avrdude) to introduce a small delay -- I think this would be a better fix than multiple calls + a sleep, in a Makefile.

For anyone else experiencing this issue under Linux (or OS X?), you want to seek out the lines:

initialload-upload: initialload.hex
    avrdude ${AVRDUDEFLAGS} -U flash:w:initialload.hex:a

and replace with:

initialload-upload: initialload.hex
    avrdude ${AVRDUDEFLAGS} -e
    sleep 0.1
    avrdude ${AVRDUDEFLAGS} -D -U flash:w:initialload.hex:a

(NOTE: This is a Makefile, you MUST have a TAB character before each line following the rule)

So what does this do? With the original avrdude invocation, avrdude performs the following:

• read information from the MCU
• erase MCU contents (well, not the bootloader, but the content contained in the last .hex file you wrote)
• write the .hex file specified (i.e. initialload.hex)

As Mike / Humberto suggest, the issue occurs because the last step, writing, is attempted by avrdude too early after the delete step is finished.

With this change, avrdude now does the following:

(first avrdude instance spawned by make)

• read existing information from the MCU
• erase MCU contents
• exit

(make sleeps here for ~100ms)

(second avrdude instance spawned by make)

• read information from the MCU
• write new .hex file to the MCU

And with the delay introduced, it seems to work really reliably!

James -

Good job...and better explanation. This will make for an excellent thread for future users to refer to. Two thumbs up.

It's a pity there isn't a way to "sticky" posts that describe common issues and how to fix them.

I also had the issue where text would always be written to the first line of the LCD (looks like avr-gcc optimisations are unreliable), which is fixed by changing -Os to -O0 in all Makefiles and recompiling all .o, .hex files. It took me a bit of searching around the forums to find this one out.

I'll have to look at the library, and if there's anywhere sensible there to put these problems + resolutions.

Thanks for all the help everyone :)

P.S. Usually I have a far superior experience developing code under Linux versus Windows or Mac.. avr under Linux (at least, Ubuntu) seems very broken so far! Maybe I need to grab the latest avrdude / avr-gcc tar-balls and build it all from source?