It seems we have some relatively large proportion of problems with the latest batch of blank ATmega328 chips. Actually these are the large stash of ATmega328's I bought from Digikey while I was in the US for Dayton FDIM/hamvention. We are now finding that in each tube of 14 chips, the 7'th chip is always a failure. How weird is *that*? Always chip number 7 of 14... I was skeptical... but it has happened now many times...
Now with the T1.00f firmware update a few days ago for the QCX, on flashing the chip the firmware first checks everything then activates the beeper on our programmer here. So we now have a built-in confirmation that the chip is Ok and now we can reject any problem chips before sending them out.?
In the meantime if anyone has an issue with a chip then please contact me off list, I will help you sort it out (if you have an AVR programmer) or send you a new chip (if you do not have an AVR programmer).?
On Sat, Aug 4, 2018 at 10:10 AM James Anderson <james21170@...> wrote:
Carl, do you have an arduino?
If so look here:-?
If not, beg borrow or buy one then look here Hi.?
Forget Avrdude..?
It just over complicates things.?
Download AVRDUDESS which is a more modern piece of programming software and then wait for Hans to get in touch with you.?
Regards, James.?
On 4 Aug 2018, at 07:51, Greg Hering <glhering@...> wrote:
I read Bernie's response about .eep and .hex files, started doing some searches. There seem to be 5 areas on the chip that can be programmed
flash,
eeprom,
hfuse,
lfuse and?
efuse
There are 'avrdude' programmer commands on ?to read and to write each of those five areas.? If we need all five files (.eep, .hex, .bin or whatever, the extension is probably just a convenience) to reflash a new controller then we should add those to the firmware archives, with some QRP
specific instructions.
