Go Down

Topic: avr mega 2560 not working after programming through avrasp (Read 4446 times) previous topic - next topic

SASHISEKHARSABAT

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

liuzengqiang

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 :D
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

SASHISEKHARSABAT

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

john1993

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.

PeterVH

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.

Quote
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?

john1993

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.

PeterVH

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)

john1993

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.

westfw

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


john1993

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.

PeterVH

@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).


SASHISEKHARSABAT

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

pert

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
Code: [Select]
mega.menu.cpu.atmega2560.bootloader.high_fuses=0xD8
to
Code: [Select]
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.
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.

john1993

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.

PeterVH

Quote
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.

Quote
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.

Go Up