|
Gang,
Over the past couple of days Hans and I have been trying to work out what's going on with the ATmega328 chip in my QCX.
As you can read in the first post, when I power up my QCX I get a message on the LCD saying 'use original ic' and that is it. The controls don't do anything, there is no signal demodulated and the radio just stays in that state forever. In the hope to resolve the matter quickly, Hans kindly provided me privately with the .hex and .eep files for the T1.00e firmware so I could reprogram the original ATmega chip from my kit with avrdude.
For most of my projects, I use a Sparkfun (PGM-09825) Pocket AVR Programmer () and use their 10-way to 6-way adapater cable and can confirm that it matches the ISP header pinout as used on the QCX board.
However, when I run the recommended avrdude command, the last step of the programming fails (a verification step) and when checking the radio again, the firmware is still not behaving any different.
===[The avrdude command I used]=== avrdude -v -c usbtiny -b 19200 -p m328p -U flash:w:T1.00e.hex -U eeprom:w:T1.00e.eep -U efuse:w:0x04:m -U hfuse:w:0xD1:m -U lfuse:w:0xF7:m -F===
(this is on Debian Linux)
===[avrdude verbose output]===
map@inspire:~/local/qcx$ ./prog-qcx.sh
avrdude: Version 6.1, compiled on Sep 11 2014 at 21:49:31
???????? Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
???????? Copyright (c) 2007-2014 Joerg Wunsch
???????? System wide configuration file is "/etc/avrdude.conf"
???????? User configuration file is "/home/map/.avrduderc"
???????? User configuration file does not exist or is not a regular file, skipping
???????? Using Port??????????????????? : usb
???????? Using Programmer????????????? : usbtiny
???????? Overriding Baud Rate????????? : 19200
avrdude: usbdev_open(): Found USBtinyISP, bus:device: 005:002
???????? AVR Part????????????????????? : ATmega328P
???????? Chip Erase delay????????????? : 9000 us
???????? PAGEL???????????????????????? : PD7
???????? BS2?????????????????????????? : PC2
???????? RESET disposition???????????? : dedicated
???????? RETRY pulse?????????????????? : SCK
???????? serial program mode?????????? : yes
???????? parallel program mode???????? : yes
???????? Timeout?????????????????????? : 200
???????? StabDelay???????????????????? : 100
???????? CmdexeDelay?????????????????? : 25
???????? SyncLoops???????????????????? : 32
???????? ByteDelay???????????????????? : 0
???????? PollIndex???????????????????? : 3
???????? PollValue???????????????????? : 0x53
???????? Memory Detail???????????????? :
????????????????????????????????? Block Poll?????????????? Page?????????????????????? Polled
?????????? Memory Type Mode Delay Size? Indx Paged? Size?? Size #Pages MinW? MaxW?? ReadBack
?????????? ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
?????????? eeprom??????? 65??? 20???? 4??? 0 no?????? 1024??? 4????? 0? 3600? 3600 0xff 0xff
?????????? flash???????? 65???? 6?? 128??? 0 yes???? 32768? 128??? 256? 4500? 4500 0xff 0xff
?????????? lfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? hfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? efuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? lock?????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? calibration??? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0???? 0???? 0 0x00 0x00
?????????? signature????? 0???? 0???? 0??? 0 no????????? 3??? 0????? 0???? 0???? 0 0x00 0x00
???????? Programmer Type : USBtiny
???????? Description???? : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
avrdude: programmer operation not supported
avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
???????? To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: Using SCK period of 10 usec
avrdude: reading input file "T1.00e.hex"
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: writing flash (31990 bytes):
Writing | ################################################## | 100% 18.75s
avrdude: 31990 bytes of flash written
avrdude: verifying flash memory against T1.00e.hex:
avrdude: load data flash data from input file T1.00e.hex:
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: input file T1.00e.hex contains 31990 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 16.75s
avrdude: verifying ...
avrdude: 31990 bytes of flash verified
avrdude: reading input file "T1.00e.eep"
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: writing eeprom (1024 bytes):
Writing | ################################################## | 100% 141.11s
avrdude: 1024 bytes of eeprom written
avrdude: verifying eeprom memory against T1.00e.eep:
avrdude: load data eeprom data from input file T1.00e.eep:
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: input file T1.00e.eep contains 1024 bytes
avrdude: reading on-chip eeprom data:
Reading | ################################################## | 100% 17.15s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
???????? 0x20 != 0x00
avrdude: verification error; content mismatch
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: safemode: Fuses OK (E:07, H:D9, L:62)
avrdude done.? Thank you.
map@inspire:~/local/qcx$
===
Now, I'm no AVR guru, but I have compiled and written code for ATtiny's and ATmega's many times and never hit a snag, so I'm optimistic that my programmer is working correctly. What I have never done before is to use .hex and .eep files.
Not to be deterred, I grabbed a couple of new, blank ATmega328P-PU DIPs that I had lying around and tried programming them in the same way (with the blank chip in the QCX).
The result was the same.
The new chip was programmed with the QCX firmware, but also failed on the last step with the same avrdude error codes, And on power-up they also show on the LCD 'use original ic'. That confirms to me that the programmer did indeed upload the QCX firmware into the new chips, but there is still something wrong.
A fellow ham who also received a QCX offered me his ATmega (same 1.00e firmware) to try out in my radio. The result was that my radio came to life and everything worked. I was able to go through the menus, do the alignment, got 2.5W @ 12V and 3W @ 13V on transmit. So that confirms to me that all the surrounding circuitry around the ATmega is correct.
I ran md5 checksums on both files and they match with Hans' files.
?
I tried reprogramming another blank chip, with external power and power through the ISP header, with and without the LCD attached, and I even programmed the chips off-board in a breadboard setup and then inserted the chip back in the QCX. All with the same non-functional result.
The easiest solution would be to just get a new chip from Hans, but both Hans and I are very intrigued as to what the underlying problem is that causes my efforts to program these chips to fail.
Anyone any ideas?
|
Have you tried a different chip? The device might be defective.
toggle quoted message
Show quoted text
On 6/16/2018 7:52 PM, post.marcel@... wrote: Gang,
Over the past couple of days Hans and I have been trying to work out what's going on with the ATmega328 chip in my QCX.
As you can read in the first post, when I power up my QCX I get a message on the LCD saying 'use original ic' and that is it. The controls don't do anything, there is no signal demodulated and the radio just stays in that state forever.
In the hope to resolve the matter quickly, Hans kindly provided me privately with the .hex and .eep files for the T1.00e firmware so I could reprogram the original ATmega chip from my kit with avrdude.
For most of my projects, I use a Sparkfun (PGM-09825) Pocket AVR Programmer ( <>) and use their 10-way to 6-way adapater cable and can confirm that it matches the ISP header pinout as used on the QCX board.
However, when I run the recommended avrdude command, the last step of the programming fails (a verification step) and when checking the radio again, the firmware is still not behaving any different.
===[The avrdude command I used]===
avrdude -v -c usbtiny -b 19200 -p m328p -U flash:w:T1.00e.hex -U eeprom:w:T1.00e.eep -U efuse:w:0x04:m -U hfuse:w:0xD1:m -U lfuse:w:0xF7:m -F
===
(this is on Debian Linux)
===[avrdude verbose output]===
map@inspire:~/local/qcx$ ./prog-qcx.sh
avrdude: Version 6.1, compiled on Sep 11 2014 at 21:49:31
???????? Copyright (c) 2000-2005 Brian Dean,
???????? Copyright (c) 2007-2014 Joerg Wunsch
???????? System wide configuration file is "/etc/avrdude.conf"
???????? User configuration file is "/home/map/.avrduderc"
???????? User configuration file does not exist or is not a regular file, skipping
???????? Using Port??????????????????? : usb
???????? Using Programmer????????????? : usbtiny
???????? Overriding Baud Rate????????? : 19200
avrdude: usbdev_open(): Found USBtinyISP, bus:device: 005:002
???????? AVR Part????????????????????? : ATmega328P
???????? Chip Erase delay????????????? : 9000 us
???????? PAGEL???????????????????????? : PD7
???????? BS2?????????????????????????? : PC2
???????? RESET disposition???????????? : dedicated
???????? RETRY pulse?????????????????? : SCK
???????? serial program mode?????????? : yes
???????? parallel program mode???????? : yes
???????? Timeout?????????????????????? : 200
???????? StabDelay???????????????????? : 100
???????? CmdexeDelay?????????????????? : 25
???????? SyncLoops???????????????????? : 32
???????? ByteDelay???????????????????? : 0
???????? PollIndex???????????????????? : 3
???????? PollValue???????????????????? : 0x53
???????? Memory Detail???????????????? :
????????????????????????????????? Block Poll Page?????????????????????? Polled
?????????? Memory Type Mode Delay Size? Indx Paged? Size?? Size #Pages MinW? MaxW?? ReadBack
?????????? ----------- ---- ----- ----- ---- ------ ------ ---- ------
----- ----- ---------
?????????? eeprom??????? 65??? 20???? 4??? 0 no?????? 1024??? 4????? 0
3600? 3600 0xff 0xff
?????????? flash???????? 65???? 6?? 128??? 0 yes???? 32768? 128??? 256
4500? 4500 0xff 0xff
?????????? lfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0
4500? 4500 0x00 0x00
?????????? hfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0
4500? 4500 0x00 0x00
?????????? efuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0
4500? 4500 0x00 0x00
?????????? lock?????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0
4500? 4500 0x00 0x00
?????????? calibration??? 0???? 0???? 0??? 0 no????????? 1??? 0
0???? 0???? 0 0x00 0x00
?????????? signature????? 0???? 0???? 0??? 0 no????????? 3??? 0
0???? 0???? 0 0x00 0x00
???????? Programmer Type : USBtiny
???????? Description???? : USBtiny simple USB programmer,
avrdude: programmer operation not supported
avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
???????? To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: Using SCK period of 10 usec
avrdude: reading input file "T1.00e.hex"
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: writing flash (31990 bytes):
Writing | ################################################## | 100% 18.75s
avrdude: 31990 bytes of flash written
avrdude: verifying flash memory against T1.00e.hex:
avrdude: load data flash data from input file T1.00e.hex:
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: input file T1.00e.hex contains 31990 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 16.75s
avrdude: verifying ...
avrdude: 31990 bytes of flash verified
avrdude: reading input file "T1.00e.eep"
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: writing eeprom (1024 bytes):
Writing | ################################################## | 100% 141.11s
avrdude: 1024 bytes of eeprom written
avrdude: verifying eeprom memory against T1.00e.eep:
avrdude: load data eeprom data from input file T1.00e.eep:
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: input file T1.00e.eep contains 1024 bytes
avrdude: reading on-chip eeprom data:
Reading | ################################################## | 100% 17.15s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
???????? 0x20 != 0x00
avrdude: verification error; content mismatch
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: safemode: Fuses OK (E:07, H:D9, L:62)
avrdude done.? Thank you.
map@inspire:~/local/qcx$
===
Now, I'm no AVR guru, but I have compiled and written code for ATtiny's and ATmega's many times and never hit a snag, so I'm optimistic that my programmer is working correctly. What I have never done before is to use .hex and .eep files.
Not to be deterred, I grabbed a couple of new, blank ATmega328P-PU DIPs that I had lying around and tried programming them in the same way (with the blank chip in the QCX).
The result was the same.
The new chip was programmed with the QCX firmware, but also failed on the last step with the same avrdude error codes, And on power-up they also show on the LCD 'use original ic'. That confirms to me that the programmer did indeed upload the QCX firmware into the new chips, but there is still something wrong.
A fellow ham who also received a QCX offered me his ATmega (same 1.00e firmware) to try out in my radio. The result was that my radio came to life and everything worked. I was able to go through the menus, do the alignment, got 2.5W @ 12V and 3W @ 13V on transmit. So that confirms to me that all the surrounding circuitry around the ATmega is correct.
I ran md5 checksums on both files and they match with Hans' files.
I tried reprogramming another blank chip, with external power and power through the ISP header, with and without the LCD attached, and I even programmed the chips off-board in a breadboard setup and then inserted the chip back in the QCX. All with the same non-functional result.
The easiest solution would be to just get a new chip from Hans, but both Hans and I are very intrigued as to what the underlying problem is that causes my efforts to program these chips to fail.
Anyone any ideas?
--
Cecil - k5nwa
|
Never programmed the particular hardware you are discussing and my EEPROM days were a very long time ago BUT 0x20 is an ASCII space -- That might be a useful observation...
On Sat, Jun 16, 2018 at 9:00 PM, Cecil Bayona <cecil.bayona@...> wrote: Have you? tried a different chip? The device might be defective.
On 6/16/2018 7:52 PM, post.marcel@... wrote:
Gang,
Over the past couple of days Hans and I have been trying to work out what's going on with the ATmega328 chip in my QCX.
As you can read in the first post, when I power up my QCX I get a message on the LCD saying 'use original ic' and that is it. The controls don't do anything, there is no signal demodulated and the radio just stays in that state forever.
In the hope to resolve the matter quickly, Hans kindly provided me privately with the .hex and .eep files for the T1.00e firmware so I could reprogram the original ATmega chip from my kit with avrdude.
For most of my projects, I use a Sparkfun (PGM-09825) Pocket AVR Programmer ( <>) and use their 10-way to 6-way adapater cable and can confirm that it matches the ISP header pinout as used on the QCX board.
However, when I run the recommended avrdude command, the last step of the programming fails (a verification step) and when checking the radio again, the firmware is still not behaving any different.
===[The avrdude command I used]===
avrdude -v -c usbtiny -b 19200 -p m328p -U flash:w:T1.00e.hex -U eeprom:w:T1.00e.eep -U efuse:w:0x04:m -U hfuse:w:0xD1:m -U lfuse:w:0xF7:m -F
===
(this is on Debian Linux)
===[avrdude verbose output]===
map@inspire:~/local/qcx$ ./prog-qcx.sh
avrdude: Version 6.1, compiled on Sep 11 2014 at 21:49:31
????????? Copyright (c) 2000-2005 Brian Dean,
????????? Copyright (c) 2007-2014 Joerg Wunsch
????????? System wide configuration file is "/etc/avrdude.conf"
????????? User configuration file is "/home/map/.avrduderc"
????????? User configuration file does not exist or is not a regular file, skipping
????????? Using Port??????????????????? : usb
????????? Using Programmer????????????? : usbtiny
????????? Overriding Baud Rate????????? : 19200
avrdude: usbdev_open(): Found USBtinyISP, bus:device: 005:002
????????? AVR Part????????????????????? : ATmega328P
????????? Chip Erase delay????????????? : 9000 us
????????? PAGEL???????????????????????? : PD7
????????? BS2?????????????????????????? : PC2
????????? RESET disposition???????????? : dedicated
????????? RETRY pulse?????????????????? : SCK
????????? serial program mode?????????? : yes
????????? parallel program mode???????? : yes
????????? Timeout?????????????????????? : 200
????????? StabDelay???????????????????? : 100
????????? CmdexeDelay?????????????????? : 25
????????? SyncLoops???????????????????? : 32
????????? ByteDelay???????????????????? : 0
????????? PollIndex???????????????????? : 3
????????? PollValue???????????????????? : 0x53
????????? Memory Detail???????????????? :
?????????????????????????????????? Block Poll? ? ? ? ? ? ? ?Page?????????????????????? Polled
??????????? Memory Type Mode Delay Size? Indx Paged? Size?? Size #Pages MinW? MaxW?? ReadBack
??????????? ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
??????????? eeprom??????? 65??? 20???? 4??? 0 no?????? 1024??? 4????? 0
3600? 3600 0xff 0xff
??????????? flash???????? 65???? 6?? 128??? 0 yes???? 32768? 128??? 256
4500? 4500 0xff 0xff
??????????? lfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0
4500? 4500 0x00 0x00
??????????? hfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0
4500? 4500 0x00 0x00
??????????? efuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0
4500? 4500 0x00 0x00
??????????? lock?????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0
4500? 4500 0x00 0x00
??????????? calibration??? 0???? 0???? 0??? 0 no????????? 1??? 0
0???? 0???? 0 0x00 0x00
??????????? signature????? 0???? 0???? 0??? 0 no????????? 3??? 0
0???? 0???? 0 0x00 0x00
????????? Programmer Type : USBtiny
????????? Description???? : USBtiny simple USB programmer,
avrdude: programmer operation not supported
avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
????????? To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: Using SCK period of 10 usec
avrdude: reading input file "T1.00e.hex"
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: writing flash (31990 bytes):
Writing | ################################################## | 100% 18.75s
avrdude: 31990 bytes of flash written
avrdude: verifying flash memory against T1.00e.hex:
avrdude: load data flash data from input file T1.00e.hex:
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: input file T1.00e.hex contains 31990 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 16.75s
avrdude: verifying ...
avrdude: 31990 bytes of flash verified
avrdude: reading input file "T1.00e.eep"
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: writing eeprom (1024 bytes):
Writing | ################################################## | 100% 141.11s
avrdude: 1024 bytes of eeprom written
avrdude: verifying eeprom memory against T1.00e.eep:
avrdude: load data eeprom data from input file T1.00e.eep:
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: input file T1.00e.eep contains 1024 bytes
avrdude: reading on-chip eeprom data:
Reading | ################################################## | 100% 17.15s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
????????? 0x20 != 0x00
avrdude: verification error; content mismatch
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: safemode: Fuses OK (E:07, H:D9, L:62)
avrdude done.? Thank you.
map@inspire:~/local/qcx$
===
Now, I'm no AVR guru, but I have compiled and written code for ATtiny's and ATmega's many times and never hit a snag, so I'm optimistic that my programmer is working correctly. What I have never done before is to use .hex and .eep files.
Not to be deterred, I grabbed a couple of new, blank ATmega328P-PU DIPs that I had lying around and tried programming them in the same way (with the blank chip in the QCX).
The result was the same.
The new chip was programmed with the QCX firmware, but also failed on the last step with the same avrdude error codes, And on power-up they also show on the LCD 'use original ic'. That confirms to me that the programmer did indeed upload the QCX firmware into the new chips, but there is still something wrong.
A fellow ham who also received a QCX offered me his ATmega (same 1.00e firmware) to try out in my radio. The result was that my radio came to life and everything worked. I was able to go through the menus, do the alignment, got 2.5W @ 12V and 3W @ 13V on transmit. So that confirms to me that all the surrounding circuitry around the ATmega is correct.
I ran md5 checksums on both files and they match with Hans' files.
I tried reprogramming another blank chip, with external power and power through the ISP header, with and without the LCD attached, and I even programmed the chips off-board in a breadboard setup and then inserted the chip back in the QCX. All with the same non-functional result.
The easiest solution would be to just get a new chip from Hans, but both Hans and I are very intrigued as to what the underlying problem is that causes my efforts to program these chips to fail.
Anyone any ideas?
--
Cecil - k5nwa
|
Can you copy the firmware from a GOOD 328 to a blank 328 and get it to verify.
?
Bob Macklin
K5MYJ
Seattle, Wa.
"Real Radios Glow In The Dark"
toggle quoted message
Show quoted text
----- Original Message -----
Sent: Saturday, June 16, 2018 5:52 PM
Subject: [QRPLabs] avrdude firmware writing question #firmware #qcx
Gang,
Over the past couple of days Hans and I have been trying to work out what's going on with the ATmega328 chip in my QCX.
As you can read in the first post, when I power up my QCX I get a message on the LCD saying 'use original ic' and that is it. The controls don't do anything, there is no signal demodulated and the radio just stays in that state forever.
In the hope to resolve the matter quickly, Hans kindly provided me privately with the .hex and .eep files for the T1.00e firmware so I could reprogram the original ATmega chip from my kit with avrdude.
For most of my projects, I use a Sparkfun (PGM-09825) Pocket AVR Programmer () and use their 10-way to 6-way adapater cable
and can confirm that it matches the ISP header pinout as used on the QCX board.
However, when I run the recommended avrdude command, the last step of the programming fails (a verification step) and when checking the radio again, the firmware is still not behaving any different.
===[The avrdude command I used]===
avrdude -v -c usbtiny -b 19200 -p m328p -U flash:w:T1.00e.hex -U eeprom:w:T1.00e.eep -U efuse:w:0x04:m -U hfuse:w:0xD1:m -U lfuse:w:0xF7:m -F
===
(this is on Debian Linux)
===[avrdude verbose output]===
map@inspire:~/local/qcx$ ./prog-qcx.sh
avrdude: Version 6.1, compiled on Sep 11 2014 at 21:49:31
???????? Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
???????? Copyright (c) 2007-2014 Joerg Wunsch
???????? System wide configuration file is "/etc/avrdude.conf"
???????? User configuration file is "/home/map/.avrduderc"
???????? User configuration file does not exist or is not a regular file, skipping
???????? Using Port??????????????????? : usb
???????? Using Programmer????????????? : usbtiny
???????? Overriding Baud Rate????????? : 19200
avrdude: usbdev_open(): Found USBtinyISP, bus:device: 005:002
???????? AVR Part????????????????????? : ATmega328P
???????? Chip Erase delay????????????? : 9000 us
???????? PAGEL???????????????????????? : PD7
???????? BS2?????????????????????????? : PC2
???????? RESET disposition???????????? : dedicated
???????? RETRY pulse?????????????????? : SCK
???????? serial program mode?????????? : yes
???????? parallel program mode???????? : yes
???????? Timeout?????????????????????? : 200
???????? StabDelay???????????????????? : 100
???????? CmdexeDelay?????????????????? : 25
???????? SyncLoops???????????????????? : 32
???????? ByteDelay???????????????????? : 0
???????? PollIndex???????????????????? : 3
???????? PollValue???????????????????? : 0x53
???????? Memory Detail???????????????? :
????????????????????????????????? Block Poll?????????????? Page?????????????????????? Polled
?????????? Memory Type Mode Delay Size? Indx Paged? Size?? Size #Pages MinW? MaxW?? ReadBack
?????????? ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
?????????? eeprom??????? 65??? 20???? 4??? 0 no?????? 1024??? 4????? 0? 3600? 3600 0xff 0xff
?????????? flash???????? 65???? 6?? 128??? 0 yes???? 32768? 128??? 256? 4500? 4500 0xff 0xff
?????????? lfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? hfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? efuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? lock?????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? calibration??? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0???? 0???? 0 0x00 0x00
?????????? signature????? 0???? 0???? 0??? 0 no????????? 3??? 0????? 0???? 0???? 0 0x00 0x00
???????? Programmer Type : USBtiny
???????? Description???? : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
avrdude: programmer operation not supported
avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
???????? To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: Using SCK period of 10 usec
avrdude: reading input file "T1.00e.hex"
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: writing flash (31990 bytes):
Writing | ################################################## | 100% 18.75s
avrdude: 31990 bytes of flash written
avrdude: verifying flash memory against T1.00e.hex:
avrdude: load data flash data from input file T1.00e.hex:
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: input file T1.00e.hex contains 31990 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 16.75s
avrdude: verifying ...
avrdude: 31990 bytes of flash verified
avrdude: reading input file "T1.00e.eep"
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: writing eeprom (1024 bytes):
Writing | ################################################## | 100% 141.11s
avrdude: 1024 bytes of eeprom written
avrdude: verifying eeprom memory against T1.00e.eep:
avrdude: load data eeprom data from input file T1.00e.eep:
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: input file T1.00e.eep contains 1024 bytes
avrdude: reading on-chip eeprom data:
Reading | ################################################## | 100% 17.15s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
???????? 0x20 != 0x00
avrdude: verification error; content mismatch
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: safemode: Fuses OK (E:07, H:D9, L:62)
avrdude done.? Thank you.
map@inspire:~/local/qcx$
===
Now, I'm no AVR guru, but I have compiled and written code for ATtiny's and ATmega's many times and never hit a snag, so I'm optimistic that my programmer is working correctly. What I have never done before is to use .hex and .eep files.
Not to be deterred, I grabbed a couple of new, blank ATmega328P-PU DIPs that I had lying around and tried programming them in the same way (with the blank chip in the QCX).
The result was the same.
The new chip was programmed with the QCX firmware, but also failed on the last step with the same avrdude error codes, And on power-up they also show on the LCD 'use original ic'. That confirms to me that the programmer did indeed upload the QCX firmware
into the new chips, but there is still something wrong.
A fellow ham who also received a QCX offered me his ATmega (same 1.00e firmware) to try out in my radio. The result was that my radio came to life and everything worked. I was able to go through the menus, do the alignment, got 2.5W @ 12V and 3W @ 13V
on transmit. So that confirms to me that all the surrounding circuitry around the ATmega is correct.
I ran md5 checksums on both files and they match with Hans' files.
?
I tried reprogramming another blank chip, with external power and power through the ISP header, with and without the LCD attached, and I even programmed the chips off-board in a breadboard setup and then inserted the chip back in the QCX. All with the
same non-functional result.
The easiest solution would be to just get a new chip from Hans, but both Hans and I are very intrigued as to what the underlying problem is that causes my efforts to program these chips to fail.
Anyone any ideas?
|
Can you copy the firmware from a GOOD 328 to a blank 328 and get it to verify.
?
Bob Macklin
K5MYJ
Seattle, Wa.
"Real Radios Glow In The Dark"
----- Original Message -----
Sent: Saturday, June 16, 2018 5:52 PM
Subject: [QRPLabs] avrdude firmware writing question #firmware #qcx
Gang,
Over the past couple of days Hans and I have been trying to work out what's going on with the ATmega328 chip in my QCX.
As you can read in the first post, when I power up my QCX I get a message on the LCD saying 'use original ic' and that is it. The controls don't do anything, there is no signal demodulated and the radio just stays in that state forever.
In the hope to resolve the matter quickly, Hans kindly provided me privately with the .hex and .eep files for the T1.00e firmware so I could reprogram the original ATmega chip from my kit with avrdude.
For most of my projects, I use a Sparkfun (PGM-09825) Pocket AVR Programmer () and use their 10-way to 6-way adapater cable
and can confirm that it matches the ISP header pinout as used on the QCX board.
However, when I run the recommended avrdude command, the last step of the programming fails (a verification step) and when checking the radio again, the firmware is still not behaving any different.
===[The avrdude command I used]===
avrdude -v -c usbtiny -b 19200 -p m328p -U flash:w:T1.00e.hex -U eeprom:w:T1.00e.eep -U efuse:w:0x04:m -U hfuse:w:0xD1:m -U lfuse:w:0xF7:m -F
===
(this is on Debian Linux)
===[avrdude verbose output]===
map@inspire:~/local/qcx$ ./prog-qcx.sh
avrdude: Version 6.1, compiled on Sep 11 2014 at 21:49:31
???????? Copyright (c) 2000-2005 Brian Dean,
???????? Copyright (c) 2007-2014 Joerg Wunsch
???????? System wide configuration file is "/etc/avrdude.conf"
???????? User configuration file is "/home/map/.avrduderc"
???????? User configuration file does not exist or is not a regular file, skipping
???????? Using Port??????????????????? : usb
???????? Using Programmer????????????? : usbtiny
???????? Overriding Baud Rate????????? : 19200
avrdude: usbdev_open(): Found USBtinyISP, bus:device: 005:002
???????? AVR Part????????????????????? : ATmega328P
???????? Chip Erase delay????????????? : 9000 us
???????? PAGEL???????????????????????? : PD7
???????? BS2?????????????????????????? : PC2
???????? RESET disposition???????????? : dedicated
???????? RETRY pulse?????????????????? : SCK
???????? serial program mode?????????? : yes
???????? parallel program mode???????? : yes
???????? Timeout?????????????????????? : 200
???????? StabDelay???????????????????? : 100
???????? CmdexeDelay?????????????????? : 25
???????? SyncLoops???????????????????? : 32
???????? ByteDelay???????????????????? : 0
???????? PollIndex???????????????????? : 3
???????? PollValue???????????????????? : 0x53
???????? Memory Detail???????????????? :
????????????????????????????????? Block Poll?????????????? Page?????????????????????? Polled
?????????? Memory Type Mode Delay Size? Indx Paged? Size?? Size #Pages MinW? MaxW?? ReadBack
?????????? ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
?????????? eeprom??????? 65??? 20???? 4??? 0 no?????? 1024??? 4????? 0? 3600? 3600 0xff 0xff
?????????? flash???????? 65???? 6?? 128??? 0 yes???? 32768? 128??? 256? 4500? 4500 0xff 0xff
?????????? lfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? hfuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? efuse????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? lock?????????? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0? 4500? 4500 0x00 0x00
?????????? calibration??? 0???? 0???? 0??? 0 no????????? 1??? 0????? 0???? 0???? 0 0x00 0x00
?????????? signature????? 0???? 0???? 0??? 0 no????????? 3??? 0????? 0???? 0???? 0 0x00 0x00
???????? Programmer Type : USBtiny
???????? Description???? : USBtiny simple USB programmer,
avrdude: programmer operation not supported
avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
???????? To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: Using SCK period of 10 usec
avrdude: reading input file "T1.00e.hex"
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: writing flash (31990 bytes):
Writing | ################################################## | 100% 18.75s
avrdude: 31990 bytes of flash written
avrdude: verifying flash memory against T1.00e.hex:
avrdude: load data flash data from input file T1.00e.hex:
avrdude: input file T1.00e.hex auto detected as Intel Hex
avrdude: input file T1.00e.hex contains 31990 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 16.75s
avrdude: verifying ...
avrdude: 31990 bytes of flash verified
avrdude: reading input file "T1.00e.eep"
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: writing eeprom (1024 bytes):
Writing | ################################################## | 100% 141.11s
avrdude: 1024 bytes of eeprom written
avrdude: verifying eeprom memory against T1.00e.eep:
avrdude: load data eeprom data from input file T1.00e.eep:
avrdude: input file T1.00e.eep auto detected as Intel Hex
avrdude: input file T1.00e.eep contains 1024 bytes
avrdude: reading on-chip eeprom data:
Reading | ################################################## | 100% 17.15s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
???????? 0x20 != 0x00
avrdude: verification error; content mismatch
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: safemode: Fuses OK (E:07, H:D9, L:62)
avrdude done.? Thank you.
map@inspire:~/local/qcx$
===
Now, I'm no AVR guru, but I have compiled and written code for ATtiny's and ATmega's many times and never hit a snag, so I'm optimistic that my programmer is working correctly. What I have never done before is to use .hex and .eep files.
Not to be deterred, I grabbed a couple of new, blank ATmega328P-PU DIPs that I had lying around and tried programming them in the same way (with the blank chip in the QCX).
The result was the same.
The new chip was programmed with the QCX firmware, but also failed on the last step with the same avrdude error codes, And on power-up they also show on the LCD 'use original ic'. That confirms to me that the programmer did indeed upload the QCX firmware
into the new chips, but there is still something wrong.
A fellow ham who also received a QCX offered me his ATmega (same 1.00e firmware) to try out in my radio. The result was that my radio came to life and everything worked. I was able to go through the menus, do the alignment, got 2.5W @ 12V and 3W @ 13V
on transmit. So that confirms to me that all the surrounding circuitry around the ATmega is correct.
I ran md5 checksums on both files and they match with Hans' files.
?
I tried reprogramming another blank chip, with external power and power through the ISP header, with and without the LCD attached, and I even programmed the chips off-board in a breadboard setup and then inserted the chip back in the QCX. All with the
same non-functional result.
The easiest solution would be to just get a new chip from Hans, but both Hans and I are very intrigued as to what the underlying problem is that causes my efforts to program these chips to fail.
Anyone any ideas?
-- Clint. M0UAW IO83
No trees were harmed in the sending of this mail. However, a large number of electrons were greatly inconvenienced.
|
@Cecil
Yes, I tried three different chips now. None of them works.
|
@Bob Macklin
?> Can you copy the firmware from a GOOD 328 to a blank 328 and get it to verify.
I have the original (what I believe to be good) firmware from Hans so if that isn't good, I don't know what is, hehe.. :-)
I am worried though that I might do something to my friend's good ATmega chip. I'm already grateful that I have a second chip I can test with, but I would rather not probe the good one any further.
What puzzles me though, is that the original chip that came with my kit behaves in exactly the same way as a reprogrammed blank chip that I provided.
|
Seems fairly obvious that Hans has implemented some form of copy protection in the firmware so unless there¡¯s been a die revision which stops it working that Hans hasn¡¯t spotted it has to be related to either your chips or programming environment/settings. What¡¯s the date code on the two chips that fail, is one the original as supplied by Hans??
@Bob Macklin
?> Can you copy the firmware from a GOOD 328 to a blank 328 and get it to verify.
I have the original (what I believe to be good) firmware from Hans so if that isn't good, I don't know what is, hehe.. :-)
I am worried though that I might do something to my friend's good ATmega chip. I'm already grateful that I have a second chip I can test with, but I would rather not probe the good one any further.
What puzzles me though, is that the original chip that came with my kit behaves in exactly the same way as a reprogrammed blank chip that I provided.
-- Clint. M0UAW IO83
No trees were harmed in the sending of this mail. However, a large number of electrons were greatly inconvenienced.
|
It sounds like you have a problem with your programmer!
?
Bob Macklin
K5MYJ
Seattle, Wa.
"Real Radios Glow In The Dark"
toggle quoted message
Show quoted text
----- Original Message -----
Sent: Sunday, June 17, 2018 12:15 AM
Subject: Re: [QRPLabs] avrdude firmware writing question #firmware #qcx
@Bob Macklin
?> Can you copy the firmware from a GOOD 328 to a blank 328 and get it to verify.
I have the original (what I believe to be good) firmware from Hans so if that isn't good, I don't know what is, hehe.. :-)
I am worried though that I might do something to my friend's good ATmega chip. I'm already grateful that I have a second chip I can test with, but I would rather not probe the good one any further.
What puzzles me though, is that the original chip that came with my kit behaves in exactly the same way as a reprogrammed blank chip that I provided.
|
@Clint
I can't confirm the copy protection part; maybe Hans could chime in, but he wouldn't have sent me the .hex and .eep files if he didn't believe I could program the chip myself.
Apart from that, why would programming a new, blank chip fail and then boot up with exactly the same symptoms as the original chip that came with the kit?
There's probably two things here that are mysterious:
1 - why did the original chip that came with the kit fail? (we probably can't answer that, but I'm sure Hans would be interested to find out)
2- why does programming a new, blank chip, with the recommended avrdude command and supplied files fail?
After my testing, I was able to successfully upload a 'blink' sketch to one of the new, blank chips and it worked as expected, so that still leaves me to believe that there is nothing wrong with my programmer and wiring.
What else could I try?
|
@Bob Macklin
As much as I would like to suspect it, I have no good reason to. Another ATmega328p chip programs just fine.
It's only the supplied .hex and .eep files from Hans that do not work.
Thanks guys, I really appreciate your thinking along.
|
Have you tried slowing the write speed right down?
Sunday, June 17, 2018
toggle quoted message
Show quoted text
@Clint I can't confirm the copy protection part; maybe Hans could chime
in, but he wouldn't have sent me the .hex and .eep files if he
didn't believe I could program the chip myself. Apart from that, why would programming a new, blank chip fail and
then boot up with exactly the same symptoms as the original chip that came with the kit? There's probably two things here that are mysterious: 1 - why did the original chip that came with the kit fail? (we
probably can't answer that, but I'm sure Hans would be interested to find out) 2- why does programming a new, blank chip, with the recommended
avrdude command and supplied files fail? After my testing, I was able to successfully upload a 'blink'
sketch to one of the new, blank chips and it worked as expected, so
that still leaves me to believe that there is nothing wrong with my programmer and wiring. What else could I try? -- 2E0ILY Best regards, Chris mailto:chris@...
--
Best regards, Chris Wilson (2E0ILY)
|
I suspect the failure to reprogram may well work out to be a programmer/software/setting problem eventually but the original chip being ¡®wrong¡¯ is what made me think it might be something like a silicon revision issue though how Hans could have missed that and for it not to have been seen by someone else too is a little baffling.?
If you¡¯re anywhere near Manchester I¡¯d be interested and willing to help investigate...
On Sun, 17 Jun 2018 at 11:30, Chris Wilson < chris@...> wrote: Have you tried slowing the write speed right down?
?Sunday, June 17, 2018
> @Clint
> I can't confirm the copy protection part; maybe Hans could chime
> in, but he wouldn't have sent me the .hex and .eep files if he
> didn't believe I could program the chip myself.
> Apart from that, why would programming a new, blank chip fail and
> then boot up with exactly the same symptoms as the original chip that came with the kit?
> There's probably two things here that are mysterious:
> 1 - why did the original chip that came with the kit fail? (we
> probably can't answer that, but I'm sure Hans would be interested to find out)
> 2- why does programming a new, blank chip, with the recommended
> avrdude command and supplied files fail?
> After my testing, I was able to successfully upload a 'blink'
> sketch to one of the new, blank chips and it worked as expected, so
> that still leaves me to believe that there is nothing wrong with my programmer and wiring.
> What else could I try?
--
?2E0ILY
Best regards,
?Chris? ? ? ? ? ? ? ? ? ? ? ? ? ? mailto:chris@...
--
Best regards, Chris Wilson (2E0ILY)
-- Clint. M0UAW IO83
No trees were harmed in the sending of this mail. However, a large number of electrons were greatly inconvenienced.
|
@Chris
Good suggestion, I'll try that and let you know.
@ Clint
Yeah, I'm somewhat worried that my chips could be not 100 per cent genuine Atmel's. I normally order QFP ones but got a batch of 10x DIPs instead. I never had a use for them until now.
The lettering on my original QCX chip (after taking off the firmware sticker) reads:
===
[Atmel logo] 35473D
ATMEGA328P? U
1803WWG
===
Whereas the lettering on my chips I got from eBay say:
===
[Atmel logo]?? 1619
ATMEGA328P-PU
===
Thanks for the offer to help investigate, I'm in Newcastle...? (the other one, Australia)? I am happy to run some more tests though. I can try other laptops, I should have a spare (original Duemilanove) arduino lying around which I can use as a ArduinoISP programmer, could try different USB cables, lower speeds, other settings. Not so much to bore you all to tears, but just in case there's someone curious enough to go on with this I'm more than happy to accommodate. I wouldn't mind getting to the bottom of it.
|
Am 17.06.2018 um 02:52 schrieb post.marcel@...: Gang,
Over the past couple of days Hans and I have been trying to work out what's going on with the ATmega328 chip in my QCX.
.... avrdude: verification error, first mismatch at byte 0x0000
???????? 0x20 != 0x00
avrdude: verification error; content mismatch The Eprom was not flashed. There is a content mismatch in the first byte. avrdude: safemode: Fuses OK (E:07, H:D9, L:62)
avrdude done.? Thank you. The fuses would not prevent to write on the EPROM. See The EESAVE fusebit is unprogrammed, means write to it is allowed. So I would try it again - EEPROM only - without the speed parameter. *After* the EEPROM has been flashed and verified OK you should set the fuses to low:0xF7, high: 0xd1 and extra:0x04 as they are on the original QCX chips. 73 Matthias, DD7NT
|
Post.Marcel,
I don't know if you've tried this yet, but the only way I could successfully flash the chip on my QCX40 was to power the QCX exclusively from the programmer's 5v line (a cheap USBTiny clone). ?When I tried flashing the MCU with the QCX connected to an external source (a 12v battery), avrdude couldn't read the ATMega's ID and I wasn't about to force the firmware flash. ?When I powered the QCX from the USBTiny the ID was properly read and I was able to flash the firmware.
73,
John
AA7US?
|
@John Landry
Thanks for the suggestion. Yeah, I already tried that. Powered the QCX from external 12V and through the 5V line through the ISP programming header (not both at the same time, of course) but neither gave the proper result. I have seen that sometimes make a difference with other projects, but unfortunately in this case it didn't make a difference.
@Matthias Zwoch
Wow, that is something I haven't tried before but looks quite promising. I will give that a go hopfully tonight and find out whether it made a difference. I'll also try different speeds, just in case.
|
I have the same problem and used 3 different programmers and two computers.? Still trying to figure what the issue is.
|
Am 18.06.2018 um 04:48 schrieb post.marcel@...: @John Landry
Thanks for the suggestion. Yeah, I already tried that. Powered the QCX from external 12V and through the 5V line through the ISP programming header (not both at the same time, of course) but neither gave the proper result. I have seen that sometimes make a difference with other projects, but unfortunately in this case it didn't make a difference.
@Matthias Zwoch
Wow, that is something I haven't tried before but looks quite promising. I will give that a go hopfully tonight and find out whether it made a difference. I'll also try different speeds, just in case.
The fuses must be flashed after the EEPROM has been flashed successfull as a last step. Hans protected with this flash configuration the EEPROM for further flashes and the flash memory against reading out his program. The proper clock selection for the QCX is also made with this fuse configration. The hint not to flash via ISP connector is also not bad. Flashing may fail at some point, when other devices as the QCX display must be powered by the programmer too and the voltage provided by the programmer decreases. You could try to flash on an ATMEL developer board or you have to make a small adapter only with the ISP lines. 73 Matthias, DD7NT
|
If you suspect that the problem might be with the programmer in combination with the QCX board then try programming a chip with Han's firmware and eeprom image in some other board. I don't think anything requires it to be programmed in situ.
It sounds like these are just DIP 328's so an arduino UNO would do as a "host".
Dave L. VE3LHO
|
AA7US