avr mega 2560 not working after programming through avrasp

[PeterVH]

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

[john1993]

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.

[PeterVH]

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.

[john1993]

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.

[PeterVH]

Hi John,


I am still intrigued by the oddities around usbasp support for atmega256O. I believe I've found some interesting results. I will report them back shortly.

I bought such an 'LC Technology' programmer too and agree it is a fine board.

... no problem with t13, m2560,

Mine certainly showed problems with the m2560 related to flash>128KB, I will detail them later.
Mine came with a firmware that is a mod of Fischl 1.2. The flash is not locked so I could read it in and compare it with Fischl 1.2, so I know it is a mod, not identical. I backed it up so I can restore it if needed. Note 1.2 is old, it dates from 2007.

What is in yours? You can look at the USB manufacturer string and bcdDevice version: mine are "www.fischl.de" and "1.2" respectively. For Fischl firmware, the bcdDevice version corresponds to the firmware version.

like before some problems did crop up after reflashed with fischle firmware

That is weird. If the programmer uses the same pinout as the original Fischl usbasp, why would the Fischl firmware not work?
Mine runs (almost) fine with Fischl 1.4, better than with the original fw. Even Fischl 1.4 has problems with flash > 128KB,  but I found a fix for that.

But maybe you tried other things. Can you describe what kind of problems you observed?

Peter.

[krupski]

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

I know it's difficult NOW to get an Atmel AVRISPMKII, but I still laugh when I read all of the "I saved three dollars and bought a cheap programmer clone off EBAY and it doesn't work - wah wah wah".

Ya gets what ya pays for.

[pert]

Ya gets what ya pays for.

Actually Atmel AVRISP mkII doesn't work for Burn Bootloader in the Arduino IDE for many people: https://github.com/arduino/Arduino/issues/2986. I bought the AVRISP mkII first because I thought it would be worth spending extra to have the best programmer but now I use the USBasp I bought as a backup instead. The only time I use my AVRISP mkII is for Upload Using Programmer with ATmega2560 because the USBasp doesn't work for that.