avrdude: Version 6.3, compiled on Mar 15 2016 at 21:26:45
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "./bin/avrdude.conf"
User configuration file is "/Users/junk16/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/cu.usbserial-A900abz5
Using Programmer : avrisp
Overriding Baud Rate : 19200
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x15
AVR Part : ATmega1284P
Chip Erase delay : 55000 us
PAGEL : PD7
BS2 : PA0
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 10 128 0 no 4096 8 0 9000 9000 0xff 0xff
flash 65 10 256 0 yes 131072 256 512 4500 4500 0xff 0xff
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
Programmer Type : STK500
Description : Atmel AVR ISP
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x15
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x15
Hardware Version: 32767
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.05s
avrdude: Device signature = 0x1e9705 (probably m1284p)
avrdude: safemode: hfuse reads as DC
avrdude: safemode: efuse reads as FD
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: reading input file "./Nava_v1_018.hex"
avrdude: writing flash (38692 bytes):
Writing | ################################################## | 100% 60.78s
avrdude: 38692 bytes of flash written
avrdude: verifying flash memory against ./Nava_v1_018.hex:
avrdude: load data flash data from input file ./Nava_v1_018.hex:
avrdude: input file ./Nava_v1_018.hex contains 38692 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 36.46s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0036
0xb2 != 0x72
avrdude: verification error; content mismatch
avrdude: safemode: hfuse reads as DC
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:DC, L:D6)
avrdude done. Thank you.
following video, its record breadboard LED indicator during writing Nava_v1_018.hex.
red led indicate error, its blinking. its same wiring lockbit, any fuse bit, Nava_v1_020.hex and BootNava.hex. https://youtu.be/QKMyHkk6CWg
Re: firmware update problem 1.017 -> 1.0xx
Posted: Jan 7th, '17, 05:17
by pistrix
here's some maybe helpful information i get reported from nick gammon's chip detector sketch...:
Atmega chip detector.
Written by Nick Gammon.
Version 1.19
Compiled on Jan 6 2017 at 23:34:35 with Arduino IDE 101.
Attempting to enter ICSP programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x97 0x05
Processor = ATmega1284P
Flash memory size = 131072 bytes.
LFuse = 0xD6
HFuse = 0xDC
EFuse = 0xFD
Lock byte = 0xCF
Clock calibration = 0x9D
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 2048 bytes starting at 1F800
Re: firmware update problem 1.017 -> 1.0xx
Posted: Jan 7th, '17, 06:14
by junk16
pistrix
thank you for sharing. I also used this sketch.
it seems value of Clock calibration is different from you. other values are same as yours.
I have good (or bad) news.
I can write Nava Boot and 1.020 hex on ATMEGA1284P which were attached on YOCTO.
I strongly suspect this issue cause by Chip.
my theory is the problem chips have had their clock timing reset from full swing oscillator to expect something specific (such as an 8 mhz resonator)
our lock fusebits are stuck at 0x0f which locks the writing of the bootloader memory, it needs to be 0x3f...but it can't be changed because it needs the specific clock timing to be programmed
since there is a 16 mhz oscillator in circuit with the 1284p on the nava, i think it has to be removed and replaced with whatever clock timing it is looking for, so so that it's fuses can be corrected -- or the 1284p has to be programmed on a breadboard, and fed the correct clock timing..after the fuses are corrected then the programming should work.
however i don't know what clock timing my 1284p is looking for..gammon's chip detector says 0x9d?
Re: firmware update problem 1.017 -> 1.0xx
Posted: Jan 8th, '17, 01:25
by junk16
I assume We need to take hvsp to reset fuse bit.
Re: firmware update problem 1.017 -> 1.0xx
Posted: Jan 8th, '17, 05:18
by e-licktronic
pistrix wrote:my theory is the problem chips have had their clock timing reset from full swing oscillator to expect something specific (such as an 8 mhz resonator)
our lock fusebits are stuck at 0x0f which locks the writing of the bootloader memory, it needs to be 0x3f...but it can't be changed because it needs the specific clock timing to be programmed
since there is a 16 mhz oscillator in circuit with the 1284p on the nava, i think it has to be removed and replaced with whatever clock timing it is looking for, so so that it's fuses can be corrected -- or the 1284p has to be programmed on a breadboard, and fed the correct clock timing..after the fuses are corrected then the programming should work.
however i don't know what clock timing my 1284p is looking for..gammon's chip detector says 0x9d?
When AVRdue erase the chip (first command line) all fuses set as default. (lock fuse = 0x3F)
Junk16,
I think Arduino +5V PSU can not draw as much current for all Nava +5v buses. That's why you could burn your µC on the Yocto.
pistrix,
Try to power your Nava via his own PSU and not powered by the Arduino. Don't forget to unplug +5V rail on the ICSP connector.
Best regards,
e-licktornic
Re: firmware update problem 1.017 -> 1.0xx
Posted: Jan 8th, '17, 05:46
by junk16
[EDIT] described Behaviour of chip erase
e-licktronic
I have tried to burn ATMEGA1284P which is included Nava kit, using both Nava main board and Yocto main board.
ATMEGA1284P which was included Nava kit is always fail.
ATMEGA1284P which was included Yocto kit is success every time.
so, I assume ATMEGA1284P which was included Nava kit is something wrong.
I tried to erase chip memory by following command, but its maybe fail on ATMEGA1284P which was included Nava kit,
because LCD display Nava start up.
in case of chip erase of success, LCD do not display anything.
Try to power your Nava via his own PSU and not powered by the Arduino. Don't forget to unplug +5V rail on the ICSP connector.
My results are unchanged..
e-licktronic wrote:When AVRdue erase the chip (first command line) all fuses set as default. (lock fuse = 0x3F)
But avrdude fails the first step...the lock fuse is stuck at 0x0F, which enables "boot loader protection mode 3".
my low fuse is set to 0xd6, which should enable the full-swing oscillator timing and allow me to program the chip, i thought...but i can't change any of the current fuses, or burn the v1_020.hex without avrdude failing verification...
since junk16 confirms another 1284p can be successfully programmed with his arduino, it seems to be the chip not the programmer, or the code. perhaps i'll just order a new 1284p and try to program it from scratch...
Re: firmware update problem 1.017 -> 1.0xx
Posted: Jan 9th, '17, 04:47
by e-licktronic
junk16, pistrix,
You are right it seems that your Nava Atmega1284P doesn't work properly.
