Topics

Upgrade to 1.04 Messed up three chips

buddybrownn5bud@...
 

I tried to upgrade my QCX to 1.04 unsuccessfully. Using programmers and software that has worked several times before I installed version 1.04, beginning with one chip.
When the software said that the upgrade was successful, I went ahead and programed the other two chips. Then the disappointment,upon booting the QCX, the display showed
"USE ORIGINAL IC". What happened and what can be done to recover from this?

Mike Besemer - WM4B
 

Contact Hans directly. I did the same thing. There is a checkbox in a AVRDudess it needs to be checked to prevent overriding the eeprom data.  Naturally I noticed it right after I click 'go'. 

Mike
WM4B

On Mar 17, 2020 7:46 AM, buddybrownn5bud@... wrote:
I tried to upgrade my QCX to 1.04 unsuccessfully. Using programmers and software that has worked several times before I installed version 1.04, beginning with one chip.
When the software said that the upgrade was successful, I went ahead and programed the other two chips. Then the disappointment,upon booting the QCX, the display showed
"USE ORIGINAL IC". What happened and what can be done to recover from this?

N3MNT
 

What Checkbox?

jjpurdum
 

VK3ELH has a nice PDF that explains how it's done. I didn't see any copyright notice, so I attached it.

Jack, W8TEE

On Tuesday, March 17, 2020, 8:38:01 AM EDT, N3MNT <bob@...> wrote:


What Checkbox?

jjpurdum
 

You can recover from it...I did! See the PDF file I attached in a post I made about 5 minutes ago.

Jack, W8TEE

On Tuesday, March 17, 2020, 7:46:38 AM EDT, buddybrownn5bud@... <buddybrownn5bud@...> wrote:


I tried to upgrade my QCX to 1.04 unsuccessfully. Using programmers and software that has worked several times before I installed version 1.04, beginning with one chip.
When the software said that the upgrade was successful, I went ahead and programed the other two chips. Then the disappointment,upon booting the QCX, the display showed
"USE ORIGINAL IC". What happened and what can be done to recover from this?

Mike Besemer - WM4B
 

Disable Flash Erase

On Mar 17, 2020 8:37 AM, N3MNT <bob@...> wrote:
What Checkbox?

Hans Summers
 

Buddy, Mike 

I'm emailing you privately off list.

73 Hans G0UPL 


On Tue, Mar 17, 2020, 14:46 <buddybrownn5bud@...> wrote:
I tried to upgrade my QCX to 1.04 unsuccessfully. Using programmers and software that has worked several times before I installed version 1.04, beginning with one chip.
When the software said that the upgrade was successful, I went ahead and programed the other two chips. Then the disappointment,upon booting the QCX, the display showed
"USE ORIGINAL IC". What happened and what can be done to recover from this?

Alan G4ZFQ
 

VK3ELH has a nice PDF that explains how it's done. I didn't see any copyright notice, so I attached it.
The question still is

What Checkbox?
He has no box checked.
The chip should have it's EEPROM write protected. It should not be possible to erase it without changing the fuses.

But quite a few have found that something goes wrong.
I think checking the fuses first would be a good idea but how do we tell someone before they do it?

73 Alan G4ZFQ

Alan G4ZFQ
 

Disable Flash Erase
Mike,

The upgrade is in the flash.

73 Alan G4ZFQ

Mike Besemer - WM4B
 

I did it just like the PDF and it erased the eeprom.  You need to check the 'Disable Flash Erase' button or put a -D in the 'Additional Settings' block.  

Mike
WM4B

Mike Besemer - WM4B
 

Well shoot... you're right. 

Regardless, I followed the .pdf and it erased the eeprom.

Mike
WM4B

Alan G4ZFQ
 

Regardless, I followed the .pdf and it erased the eeprom.
Mike,
Yes that's the puzzle, it works for some but not others.
It's just like if some chips did not get the fuses set properly. But Hans says that's very unlikely.
I've added a suggestion in my notes that the fuses are checked first.
https://sites.google.com/site/g4zfqradio/qrplabs_program_chip_with_USBasp

73 Alan G4ZFQ

Roy Appleton
 

Like maybe some really don't know what they're doing! 🤔

Roy
WA0YMH

On Tue, Mar 17, 2020, 2:14 PM Alan G4ZFQ <alan4alan@...> wrote:
> Regardless, I followed the .pdf and it erased the eeprom.
>

Mike,
Yes that's the puzzle, it works for some but not others.
It's just like if some chips did not get the fuses set properly. But
Hans says that's very unlikely.
I've added a suggestion in my notes that the fuses are checked first.
https://sites.google.com/site/g4zfqradio/qrplabs_program_chip_with_USBasp

73 Alan G4ZFQ



Bill NF6R
 

Alan,

Perfect timing.  I'm working through the process now learning how to do this.  

2 questions, if I may: 
1)  Does the keying nub of the plug go to the outside of the board?
2)  Are the pins labelled on the bottom of the board?  (It's at home and I haven't pulled it out of the case yet)

Thanks!

--

Bill - NF6R
SKCC 20696 NAQCC 9984 FISTS 19479 CalQRP 78 Flying Pigs 4181

Gregg Myers
 

Hi Bill,

The pins are not labeled on my Rev 4 board that I saw. In my case, the 'nub' of my cable would be on the inside (interior) of the QCX board, not to the outside. One clue to figuring out the correct orientation is to figure out where the ground connection is on the AVR header. Once the upper left corner of the AVR pins is established to be ground (and you can verify this also on the QCX board), the orientation of the header would be like I show below. My AVR programmer cable is keyed so the gray ribbon cable cannot be connected the other way around. What you see in the photograph of the QCX below is exactly how I've upgraded mine (several times now). By the way, I have always used AVRDUDE not AVRDUDESS. That's my preference and the commands I use are always the same, so nothing has ever happened accidentally to me (e.g. forget to check a checkbox or something) and this has worked for me every time. Also, don't try and power the QCX through the AVR programmer. The QCX is running on it's normal power connection when I upgrade the firmware.

The simple command lines I use for my programmer are always like this:

avrdude -c usbtiny -p atmega328p -> will check communication and fuses. I always do this first to check my connection.
avrdude -c usbtiny -p atmega328p -b 19200 -U flash:w:filenamexxx.hex  -> will write new firmware hex file 'filenamexxx.hex' to the QCX

Cable orientation.jpg
:

AVR Orientation.JPG
73,
Gregg
w7grm

On Tue, Mar 17, 2020 at 2:00 PM Bill NF6R <nf6r.bill@...> wrote:
Alan,

Perfect timing.  I'm working through the process now learning how to do this.  

2 questions, if I may: 
1)  Does the keying nub of the plug go to the outside of the board?
2)  Are the pins labelled on the bottom of the board?  (It's at home and I haven't pulled it out of the case yet)

Thanks!

--

Bill - NF6R
SKCC 20696 NAQCC 9984 FISTS 19479 CalQRP 78 Flying Pigs 4181

Mike Besemer - WM4B
 

Alan,

That was the problem in my case; the hfuse was set to 0xD9 instead of 0xD1. Unfortunately, (as you pointed out) I discovered it too late. Hans sent me the .eep file, but have not been able to get it going; it fails the eeprom verification.

I think I'll just order an updated eeprom tomorrow.

73,

Mike
WM4B

-----Original Message-----
From: QRPLabs@groups.io [mailto:QRPLabs@groups.io] On Behalf Of Alan G4ZFQ
Sent: Tuesday, March 17, 2020 11:30 AM
To: QRPLabs@groups.io
Subject: Re: [QRPLabs] Upgrade to 1.04 Messed up three chips

VK3ELH has a nice PDF that explains how it's done. I didn't see any
copyright notice, so I attached it.
The question still is

What Checkbox?
He has no box checked.
The chip should have it's EEPROM write protected. It should not be
possible to erase it without changing the fuses.

But quite a few have found that something goes wrong.
I think checking the fuses first would be a good idea but how do we tell
someone before they do it?

73 Alan G4ZFQ

N3MNT
 

I may be way off here, but if programming an older 1.01 chip with the new firmware, does this comment possibly cause the issue.

"Note that from now on we will supply QCX chips with low fuse 0xD7 not 0xF7. The new recommendation will be 0xD7. The old F7 has a 65ms delay on start-up for slowly rising power line but this is NOT required when you are using a Brownout Detector bit since the brownout logic will hold the reset anyway until the power line comes up (ATmega328 datasheet). D7 removes the 65ms startup delay."

Gregg Myers
 

The one datapoint I can offer is from the oldest chip I have. My oldest chip was on T1.00g according to the label. I have upgraded it with every new version since then as soon as they were released without issue (using avrdude command line statements, as I noted). I can't comment on using other methods as I continue to use what works for me. No need for me to experiment with it since it hasn't failed me yet! 🙂

73,
Gregg


On Tue, Mar 17, 2020 at 6:44 PM N3MNT <bob@...> wrote:
I may be way off here, but if programming an older 1.01 chip with the new firmware, does this comment possibly cause the issue.

"Note that from now on we will supply QCX chips with low fuse 0xD7 not 0xF7. The new recommendation will be 0xD7. The old F7 has a 65ms delay on start-up for slowly rising power line but this is NOT required when you are using a Brownout Detector bit since the brownout logic will hold the reset anyway until the power line comes up (ATmega328 datasheet). D7 removes the 65ms startup delay."

Mike Besemer - WM4B
 

There is really no question about that Roy, but given that the instructions were followed to the letter, knowing what one is doing really isn't necessary.  In my case, the h-fuse was not set to prevent the eeprom from being erased; something that should obviously be checked prior to programming.  Like (I suspect) most people, I knew nothing of such things prior to this, but it didn't take long to do the research to figure it out.  Nobody got killed and I learned something.  Game over.

Mike
WM4B

Mike Besemer - WM4B
 

Gregg,

FWIW, I've tried AVRDUDESS and command line from AVRDUDE with the same results.

Mike
WM4B