avr mega 2560 not working after programming through avrasp

hii all, i am designing a circuit having atmega2560. strange thing happened when i programmed it through a avrasp programmer. the program was uploaded fine but did not show any output. the circuit is similar to the arduino mega board, instead of using an RC oscillator i used a crystal oscillator of 16Mhz. my fuse bits are HIGH fuse = D8 LOW fuse = FF EXT fuse = FD i can burn my program into mcu without any error through programmer but there is no output. the simple led blink program is also not running.

can anyone suggest any solution for this problem, it will be a life saver.

thanks

So you made your own board or prototype. I wonder if there is something wrong with your design besides fuse values. Plus, you enabled bootloader so did you include bootloader in your compiled code? I guess not :smiley:

hii Liudr,
thanks for replying. actually i did some research & found out that mega 2560 cant be programmed through usbasp programmer. so i brought an arduino mega board & programmed it as an isp, then upload the bootloader into my customized board. after some time an error message is popped up saying bootloader cant be uploaded but the led on 13 pin started blinking. so i hoped the bootloader is uploaded fine but there was a false error message some how.
then after i uploaded a led blink program directly through usb, as my circuit has one ft232rl chip for usb communication. but the strange thing is i can upload any program only once after uploading bootloader.
so i cant understand what i have done wrong in my circuit. please help me solving this issue.

thanks
sashi sekhar sabat

SASHISEKHARSABAT: hii Liudr, i did some research & found out that mega 2560 cant be programmed through usbasp programmer.

i think you are mistaken. i have been programming 2560 with usbasp for years. there are some problems with the "fischel" firmware but cheap $2 chinese ebay versions do an excellent job. imo best programmer out there.

Can you confirm it correctly programs the bootloader at the end of the 2560's flash? A test in this other thread, revealed that the most recent fishl fw did not correctly put the image in flash.

there are some problems with the "fischel" firmware but cheap $2 chinese ebay versions do an excellent job. imo best programmer out there.

Can you point us to a location where the sources of the firmware with the issues fixed can be found?

yes, that is just one of the issues with "fischel" firmware. it has proven nothing but trouble for me and ive had to discard several modules after reflashing that. i think many noobs following the same bad advice too. unfortunately, as mentioned in the other thread today, the chinese firmware is not open source or english docs. code is available for sale and can be stolen on bit torrent by those willing to take the risk.

also note that many problems flashing big chips high were due to bugs in bogus avrdude versions. maybe fixed in recent releases afaik. lots of custom version floating around but im not an expert there. building billy-box apps not my strong suit.

Can you confirm your chinese ebay usbasp can correctly burn the bootloader to an 2560?

Both sashi sekhar sabat and the guy from the thread I referred to above, reported usbasp badly installing the bootloader to their 2560. Both correctly installed the bootloader aferwards using ArduinoISP. Chances are they used a chinese usbasp one too.

(@sashi sekhar sabat: sorry for interfering with your thread)

with the right version of avrdude and correct usbasp firmware not a problem. ive uploaded a few dozen 2560 with custom and standard bootloaders and other code that needs flash write capability. i suspect those who had trouble just lacked the right combination. im very fond of arduino-as-isp but havent tried one for this. if successful it does seem to be the least risky and most convenient method.

and correct usbasp firmware

How do you tell whether your cheap eBay USBASP has "correct" firmware on it?

in my case by purchasing from a known source. i buy hundreds of these for business use and depend on my alibaba contact to supply consistent product. same one for several years now.

its not as tricky as it seems because 99% of random ebay purchase work out if they physically resemble the "good" type. generally baite assembly house with askew mcu. this used to be lowest cost for a dollar or two. now the other type with blue pcb and aligned mcu account for most cheapest. the difference is only a few cents though so id go for the former.

its been a while since last my last personal ebay order but others had good luck with this approach and some say the new design works out ok too now. last time i sampled the lcsoft ones and those in a metal case were trouble. in my experience reflashing any of these with fischel firmware did not work out. neither for units built from scratch.

@john1993: that is interesting info, thanks.

@JSASHISEKHARSABAT: just out of curiosity, (see john's info), can you provide a link to the usbasp you have?

About the original problem: the bootloader might still not be correctly installed. Did you use avrdude 6.1? (ide 1.6.5 installs 6.0.1 which does NOT work correctly).

hii petervh, sorry for the late reply, but still i have tried a 3/4 different usbasp which are available at my nearest electronic shop but no luck. i have tried the arduino as isp. it can upload the boot loader with an error but the error doesn't count perhaps as boot loader works properly. but after that any program uploaded through the arduino as isp not working at all & in the process boot loader also get corrupted.

now pls share some link where i can get proper programmer for programming higher memory chips like atmega2560.

thanks in advance

Here's my experience using USBasp and ATmega2560: I can use the Arduino IDE 1.6.5r5 Burn Bootloader and it works fine. If I do Upload Using Programmer then it appears to upload fine but the program never runs. If I change the line in boards.txt from

mega.menu.cpu.atmega2560.bootloader.high_fuses=0xD8

to

mega.menu.cpu.atmega2560.bootloader.high_fuses=0xD9

As instructed in the topic http://forum.arduino.cc/index.php?topic=126160.msg1839705#msg1839705 and Burn Bootloader using USBasp to set the new fuses then Upload Using Programmer works but if I Burn Bootloader using USBasp and then try to do a serial upload it doesn't work. If I use Atmel AVRISP mkII to Burn Bootloader with the high fuse set to D9 then I can use the bootloader and Upload Using Programmer with the USBasp also works. So if you only want to Upload Using Programmer with your USBasp then change your boards.txt(or better create your own hardware files with the change so that you don't have to redo it every time the Arduino AVR Boards are updated) but be aware this will cause the bootloader to no longer work until you change the high fuse back to D8 and do Burn Bootloader again.

SASHISEKHARSABAT: but after that any program uploaded through the arduino as isp not working at all & in the process boot loader also get corrupted.

The bootloader doesn't get corrupted when you Upload Using Programmer, it gets erased. This is normal and unavoidable. If you want to use the bootloader again after Upload Using Programmer then you will need to Burn Bootloader again first.

so maybe we conclude that with proper usbasp and avrdude this is not the problem flashing high.

westfw explained the reset jump subject quite well. in fact all my other avrs are set to execute from boot area so if there is a bootloader or program up there with code to write flash it runs. otherwise it quickly and harmlessly executes all the ffff instructions and wraps to main code at 0. ffff is the start of a 4 byte instruction so a single nop or jump in the boot area for example can cause a fail but this should not be a problem with nothing there.

so in a nutshell my avrs are always set to boot area even for apps at 0. im surprised its any different for arduino mega.

so in a nutshell my avrs are always set to boot area even for apps at 0.

Well no: not only the reset vector will be in the boot area, the interrupt vectors will be fetched there too. So if your program uses irq's this will not work.

im surprised its any different for arduino mega.

It is not different: a new arduino mega has high fuse is D8, so it jumps to boot load section.

@JSASHISEKHARSABAT:

In your first post, you tried burning a sketch using your usbasp. Your high fuse was set to D8, which is wrong. If you set your high fuse to D9, that is supposed to work with usbasp (since for small sketches you don't touch high memory).

In your second post you try to burn the bootloader. For a bootloader, the D8 fuse is correct. But you probably can't program it with usbasp. The ArduinoISP sketch with avrdude 6.1 should work without error messages. If it doesn't, please post the comlete verbose log over here.

PeterVH: Well no: not only the reset vector will be in the boot area, the interrupt vectors will be fetched there too. So if your program uses irq's this will not work.

actually it does work because ivt can be relocated from user code using ivce/ivsel bits in gicr. i have done this in hundreds of programs with many different chip families. otherwise there would be no way for some bootloaders that do use interrupts to run user programs.

anyway imo it dont look like usbasp, avrdude, or fuse bits prevent writing upper flash. assuming proper versions and configuration.

actually it does work because ivt can be relocated from user code using ivce/ivsel bits in gicr.

Good point. Silly me.

But your in a nutshell suggests to always start from boot area (i.e. hfuse=0xD8) whereas the the suggested solution here is to start from address 0x0 (hfuse=0xD9) when working without bootloader... I have both sketches that work with hfuse=0xD8 (and no bootloader) and sketches that don't (E.g. blink).

anyway imo it dont look like usbasp, avrdude, or fuse bits prevent writing upper flash.

I'll further look into this. See SchroedingersCat_'s thread. I have a suggestion: we can further discuss the general atmega2560/BOOTRST/hfuse/usbasp subjects in SchroedingersCat_'s thread and keep this thread focussed on JSASHISEKHARSABAT's problem.

sorry, the nutshell comment was not general recommendation but just how i personally prefer a simple one size fits all approach. for me the less back-and-forth and things to keep track of the better. specially when it comes to flipping fuse bits.

no need to continue this aspect because most understand principles involved now. as usual this forum is a goldmine of good info and viewpoints. in the process maybe we have eliminated some potential causes for ops woes.

john1993: 99% of random ebay purchase work out if they physically resemble the "good" type. generally baite assembly house with askew mcu. this used to be lowest cost for a dollar or two. now the other type with blue pcb and aligned mcu account for most cheapest.

interesting update. its been a couple years since the cheap blue with aligned cpu and lc logo tested bad but new units seem to be working fine now. a couple people sent me some of these to evaluate and they worked just as well as the slightly more expensive black aligned baite ones. idk if hardware or software was changed but no problem with t13, m2560, and some others in between. like before some problems did crop up after reflashed with fischle firmware. a costly metal cased one i was sent also misbehaved.

so as the case with many things cheapest ebay ones worked better than the more expensive. looks like you dont have to worry about finding special versions now. ardunio-as-isp also highly recommended solution too.