Re: [avr-chat] Can't program an ATMEGA48 using avrispmkII
"Eddie Dawydiuk" <[EMAIL PROTECTED]> wrote: > avrdude: AVR device initialized and ready to accept instructions > > Reading | ## | 100% 0.02s > > avrdude: Device signature = 0xff The default ISP speed of the AVRISP mkII as shipped appears to be somewhat random. I've seen parts that are terribly slow as shipped. Maybe yours is just too fast? I'm not sure whether the stk500v2 driver backend (which is also used for the AVRISP mkII) does really honor the -B option. Sure, it should (and if it doesn't, please file a bug report). But then, the AVRISP mkII remembers the last ISP speed that had been configured in its EEPROM, so what you can always do is: avrdude -p m48 -P usb -c avrispmkII -tuF Then, enter "sck 10", a 10 µs SCK period ought to be sufficient for almost any situations (except an AVR running from the 128 kHz RC oscillator), and leave AVRDUDE's terminal mode again. Try to connect again after the AVRISP's ISP frequency has been changed. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-chat mailing list AVR-chat@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-chat
Re: [avr-chat] Can't program an ATMEGA48 using avrispmkII
Hello, Of course the 'correct' values for the fuses did not reflect this. I've mentioned on several occasions to the VP's of Atmel that come here that I think it should be impossible to disable the SPI interface from the SPI interface. I agree. The devices were 'recovered' in the parallel programmer because it will erase the entire flash space before erasing all the fuse bits to factory condition. Unfortunatley were using a surface mount part, I'm hoping I can determine if the reset pin has been disabled or if the lock bits are set... Of course, if the lock bits get set wrong, I think you're out of luck. Thanks for the info, thats what I was afraid of. I'm going to have our tech lift the reset pin to see if the pullup is still present... Does anyone know if there is a way to tell if the lock bits are set? //Eddie Todd Batzler Senior Staff Engineer Miller Electric Mfg Co 1635 W Spencer St Appleton, WI 54914- USA Phone: 920 735 4230 Fax: 920 735-4488 email: [EMAIL PROTECTED] "Eddie Dawydiuk" <[EMAIL PROTECTED]> 10/10/2006 6:43 PM >>> Hell all, I am new to list, I've searched google as well as this mailing list to find a solution to my problem but so far I have been unable to. During development I use AVR studio to program my development board. I am now integrating the programming of the AVR into our production framework. I installed avrdude version 5.1, initially I was able to program my device using avrdude. Recently I have found several boards are in a state in which I can not program them using avrdude. The initial failure condition is the signature is not properly read. e.g. [EMAIL PROTECTED]:root]#avrdude -p m48 -P usb -c avrispmkII -U flash:w:/var/ts-production/bitstreams/tsbat3.hex avrdude: stk500v2_recv_mk2: error in USB receive avrdude: AVR device initialized and ready to accept instructions Reading | ## | 100% 0.02s avrdude: Device signature = 0xff avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check. avrdude done. Thank you. [EMAIL PROTECTED]:root]# Although if I add the -F option the next failure condition is a failure when writing to flash memory. [EMAIL PROTECTED]:root]#avrdude -p m48 -P usb -c avrispmkII -U flash:w:/var/ts-production/bitstreams/tsbat3.hex -F avrdude: stk500v2_recv_mk2: error in USB receive avrdude: AVR device initialized and ready to accept instructions Reading | ## | 100% 0.02s avrdude: Device signature = 0xff avrdude: Yikes! Invalid device signature. 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 "/var/ts-production/bitstreams/tsbat3.hex" avrdude: input file /var/ts-production/bitstreams/tsbat3.hex auto detected as Intel Hex avrdude: writing flash (3594 bytes): Writing | # | 1% 0.02savrdude: stk500v2_paged_write: write command failed with 129 Writing | ## | 100% 0.06s avrdude: failed to write flash memory, rc=-1 avrdude: safemode: Fuses OK avrdude done. Thank you. I ran into this several times earlier and I was able to get the boards into a state where I could program them by using AVR studio and modifying the ISP frequency. After doing so I found avrdude could properly program the boards. I've tried to use the -B flag to modify the ISP frequency from avrdude although this doesn't seem to help. Even worse yet AVR studio no longer seems to work. The command I have been using that lead to this problem is listed below. avrdude -p m48 -P usb -c avrispmkII -v -e -F -u -B 100\ -U flash:w:bitstearm.hex \ -U lfuse:w:0x0E:m \ -U hfuse:w:0xDF:m \ -U efuse:w:0x01:m One thing to note, I have a known working board that has only been programmed with AVR studio and I can still program this board with AVR studio. The other three boards I tried to program with avrdude are all in this same state where I can't program them. Could someone provide any insight, any troubleshooting suggestions? Is there any more information I could provide that would be helpful? //Eddie ___ AVR-chat mailing list AVR-chat@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-chat ___ AVR-chat mailing list AVR-chat@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-chat ___ AVR-chat mailing list AVR-chat@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-chat
Re: [avr-chat] Can't program an ATMEGA48 using avrispmkII
We've had production/manufacturing issues related to ISP programming of Atmel parts, although I've no direct experience with mega48's. This was tracked down to the ISP programming cable draped over a switching power supply. The noise from this supply (presumably) caused the incorrect fuses to be programmed into the part. Unfortunately Atmel designed the part so you can disable the spi from the spi in a couple of ways by setting the 'wrong' fuses. Analysis of the devices when placed in a parallel programming mode (in an STK500) showed that on some parts the RESET pin was disabled (required for ISP) and the SPIEN bit was set, disabling the SPI interface. Of course the 'correct' values for the fuses did not reflect this. I've mentioned on several occasions to the VP's of Atmel that come here that I think it should be impossible to disable the SPI interface from the SPI interface. The devices were 'recovered' in the parallel programmer because it will erase the entire flash space before erasing all the fuse bits to factory condition. Of course, if the lock bits get set wrong, I think you're out of luck. Hope this helps. Todd Batzler Senior Staff Engineer Miller Electric Mfg Co 1635 W Spencer St Appleton, WI 54914- USA Phone: 920 735 4230 Fax: 920 735-4488 email: [EMAIL PROTECTED] >>> "Eddie Dawydiuk" <[EMAIL PROTECTED]> 10/10/2006 6:43 PM >>> Hell all, I am new to list, I've searched google as well as this mailing list to find a solution to my problem but so far I have been unable to. During development I use AVR studio to program my development board. I am now integrating the programming of the AVR into our production framework. I installed avrdude version 5.1, initially I was able to program my device using avrdude. Recently I have found several boards are in a state in which I can not program them using avrdude. The initial failure condition is the signature is not properly read. e.g. [EMAIL PROTECTED]:root]#avrdude -p m48 -P usb -c avrispmkII -U flash:w:/var/ts-production/bitstreams/tsbat3.hex avrdude: stk500v2_recv_mk2: error in USB receive avrdude: AVR device initialized and ready to accept instructions Reading | ## | 100% 0.02s avrdude: Device signature = 0xff avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check. avrdude done. Thank you. [EMAIL PROTECTED]:root]# Although if I add the -F option the next failure condition is a failure when writing to flash memory. [EMAIL PROTECTED]:root]#avrdude -p m48 -P usb -c avrispmkII -U flash:w:/var/ts-production/bitstreams/tsbat3.hex -F avrdude: stk500v2_recv_mk2: error in USB receive avrdude: AVR device initialized and ready to accept instructions Reading | ## | 100% 0.02s avrdude: Device signature = 0xff avrdude: Yikes! Invalid device signature. 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 "/var/ts-production/bitstreams/tsbat3.hex" avrdude: input file /var/ts-production/bitstreams/tsbat3.hex auto detected as Intel Hex avrdude: writing flash (3594 bytes): Writing | # | 1% 0.02savrdude: stk500v2_paged_write: write command failed with 129 Writing | ## | 100% 0.06s avrdude: failed to write flash memory, rc=-1 avrdude: safemode: Fuses OK avrdude done. Thank you. I ran into this several times earlier and I was able to get the boards into a state where I could program them by using AVR studio and modifying the ISP frequency. After doing so I found avrdude could properly program the boards. I've tried to use the -B flag to modify the ISP frequency from avrdude although this doesn't seem to help. Even worse yet AVR studio no longer seems to work. The command I have been using that lead to this problem is listed below. avrdude -p m48 -P usb -c avrispmkII -v -e -F -u -B 100\ -U flash:w:bitstearm.hex \ -U lfuse:w:0x0E:m \ -U hfuse:w:0xDF:m \ -U efuse:w:0x01:m One thing to note, I have a known working board that has only been programmed with AVR studio and I can still program this board with AVR studio. The other three boards I tried to program with avrdude are all in this same state where I can't program them. Could someone provide any insight, any troubleshooting suggestions? Is there any more information I could provide that would be helpful? //Eddie ___ AVR-chat mailing list AVR-chat@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-chat ___ AVR-chat mailing list AVR-chat@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-chat
