Strange situation while burning blinking LED program to atmega168pa via usbasp

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all. This is a beginner question, and sorry for the English if it's bad. I'm in a strange situation, for me at least. I'm trying to burn blinking a LED program to my atmega168pa-pu using usbasp.

 

The program is in the book AVR Programming: Learning to Write Software for Hardware.

 

Source and the makefile can be found at https://github.com/hexagon5un/AV....

 

I've changed the PROGRAMMER_TYPE definition in the makefile to usbasp.

 

Here's the situation.

 

 

When I run avrdude -c usbasp -p m168p sometimes it gives me:

 

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e940b (probably m168p)

avrdude: safemode: Verify error - unable to read efuse properly. Programmer may not be reliable.
avrdude: safemode: lfuse changed! Was 62, and is now fe
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: hfuse changed! Was df, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: efuse changed! Was f9, and is now fe
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:F9, H:DF, L:62)

avrdude done.  Thank you.

 

Sometimes this:

 

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e940b (probably m168p)

avrdude: safemode: Fuses OK (E:F9, H:DF, L:62)

avrdude done.  Thank you.

 

And sometimes that:

 

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e2802
avrdude: Expected signature for ATmega168P is 1E 94 0B
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

 

This seems random. Can you please point out why could this be happenning ?

 

The real problem occurs when trying to burn to the avr.

 

If I connect negative pin of the capacitor to the 8th (GND) pin of the avr, as in the image above, and run make flash, it sometimes gives me:

 

avr-gcc -Os -g -std=gnu99 -Wall -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums  -ffunction-sections -fdata-sections  -DF_CPU=1000000UL   -DBAUD=9600UL -I. -I../../AVR-Programming-Library -mmcu=atmega168p -c -o blinkLED.o blinkLED.c
avr-gcc -Wl,-Map,blinkLED.map  -Wl,--gc-sections  -mmcu=atmega168p blinkLED.o ../../AVR-Programming-Library/USART.o  -o blinkLED.elf
avr-objcopy -j .text -j .data -O ihex blinkLED.elf blinkLED.hex
avrdude -c usbasp -p atmega168p  -U flash:w:blinkLED.hex

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e940b (probably m168p)
avrdude: safemode: Verify error - unable to read efuse properly. Programmer may not be reliable.
avrdude: safemode: To protect your AVR the programming will be aborted

avrdude done.  Thank you.

Makefile:130: recipe for target 'flash' failed
make: *** [flash] Error 1

 

And sometimes:

 

avr-gcc -Os -g -std=gnu99 -Wall -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums  -ffunction-sections -fdata-sections  -DF_CPU=1000000UL   -DBAUD=9600UL -I. -I../../AVR-Programming-Library -mmcu=atmega168p -c -o blinkLED.o blinkLED.c
avr-gcc -Wl,-Map,blinkLED.map  -Wl,--gc-sections  -mmcu=atmega168p blinkLED.o ../../AVR-Programming-Library/USART.o  -o blinkLED.elf
avr-objcopy -j .text -j .data -O ihex blinkLED.elf blinkLED.hex
avrdude -c usbasp -p atmega168p  -U flash:w:blinkLED.hex

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e940b (probably m168p)
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: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "blinkLED.hex"
avrdude: input file blinkLED.hex auto detected as Intel Hex
avrdude: writing flash (178 bytes):

Writing | ################################################## | 100% 0.25s

avrdude: 178 bytes of flash written
avrdude: verifying flash memory against blinkLED.hex:
avrdude: load data flash data from input file blinkLED.hex:
avrdude: input file blinkLED.hex auto detected as Intel Hex
avrdude: input file blinkLED.hex contains 178 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.13s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x00 != 0x0c
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was 62, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: hfuse changed! Was df, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: efuse changed! Was f9, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:F9, H:DF, L:62)

avrdude done.  Thank you.

Makefile:130: recipe for target 'flash' failed
make: *** [flash] Error 1

 

But never uploads the program to the chip.

 

The strange part is, if I connect the negative pin of the capacitor to the 9th pin (XTAL1) of the avr, like the image below, it burns successfully, and the LED starts to blink.

 

 

avr-gcc -Os -g -std=gnu99 -Wall -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums  -ffunction-sections -fdata-sections  -DF_CPU=1000000UL   -DBAUD=9600UL -I. -I../../AVR-Programming-Library -mmcu=atmega168p -c -o blinkLED.o blinkLED.c
avr-gcc -Wl,-Map,blinkLED.map  -Wl,--gc-sections  -mmcu=atmega168p blinkLED.o ../../AVR-Programming-Library/USART.o  -o blinkLED.elf
avr-objcopy -j .text -j .data -O ihex blinkLED.elf blinkLED.hex
avrdude -c usbasp -p atmega168p  -U flash:w:blinkLED.hex

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e940b (probably m168p)
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: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "blinkLED.hex"
avrdude: input file blinkLED.hex auto detected as Intel Hex
avrdude: writing flash (178 bytes):

Writing | ################################################## | 100% 0.25s

avrdude: 178 bytes of flash written
avrdude: verifying flash memory against blinkLED.hex:
avrdude: load data flash data from input file blinkLED.hex:
avrdude: input file blinkLED.hex auto detected as Intel Hex
avrdude: input file blinkLED.hex contains 178 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.13s

avrdude: verifying ...
avrdude: 178 bytes of flash verified

avrdude: safemode: Fuses OK (E:F9, H:DF, L:62)

avrdude done.  Thank you.

 

Isn't the ground supposed be connected to the 8th pin ? Can it be connected to the 9th pin ? By the way, an image of the programmer is below. Thank you.

 

 

 

 

 

 

This topic has a solution.
Last Edited: Mon. Apr 16, 2018 - 02:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The '168 has two GND pins and two VCC pins. Both need to be connected.

Your decoupling (blue) capacitor needs to be a lot closer to the chips pins, like plugged into the breadboard right next to the pins.

Both sets of GND and VCC need their own capacitor.

 

Make those changes and then come back to us.

 

 

Also, although you say things seems random, I can't help but notice that the first thing AVRDUDE says, every tine , is...

 

Quote:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.

 

Sounds like you ought to sort that out as well by slowing down the clock AVRDUDE uses to program the chip.

"This forum helps those that help themselves."

"How have you proved that your chip is running at xxMHz?" - Me

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You'd save yourself a lot of grief if you paid $5 for:

 

https://www.ebay.co.uk/itm/UNO-R...

 

 

or similar - if you want one sooner then order locally and pay the extra.

 

The Arduino is a 328 on a neatly laid out on a professionally made board with a programming system built in - you don't need dodgy programming connections or wobbly breadboard links. It just works.

 

(oh and nothing ties you to the Arduino software system - the very code you trying to use above should just work (as long as you pick the right pin for the LED))

Last Edited: Mon. Apr 16, 2018 - 10:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

The '168 has two GND pins and two VCC pins. Both need to be connected.

Your decoupling (blue) capacitor needs to be a lot closer to the chips pins, like plugged into the breadboard right next to the pins.

Both sets of GND and VCC need their own capacitor.

 

Make those changes and then come back to us.

 

 

Also, although you say things seems random, I can't help but notice that the first thing AVRDUDE says, every tine , is...

 

Quote:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.

 

Sounds like you ought to sort that out as well by slowing down the clock AVRDUDE uses to program the chip.

 

Okay, I connected both VCC and GNDs and placed capacitors right before them. Still the same. I can't lower the programmer's clock, however. I tried high values for the bitrate option of avrdude, no change. I tried bridging clock jumper of the programmer, nothing changes.

 

Again, if I remove jumpers connected to AVCC and GND on pins 20 and 22 and connect GND to pin 9, it successfully uploads.

 

How can I lower programmer clock ? Maybe I should use another programmer.

 

clawson wrote:

You'd save yourself a lot of grief if you paid $5 for:

 

https://www.ebay.co.uk/itm/UNO-R...

 

or similar - if you want one sooner then order locally and pay the extra.

 

The Arduino is a 328 on a neatly laid out on a professionally made board with a programming system built in - you don't need dodgy programming connections or wobbly breadboard links. It just works.

 

(oh and nothing ties you to the Arduino software system - the very code you trying to use above should just work (as long as you pick the right pin for the LED))

 

Yeah I have an arduino uno. I think I should use this as a programmer.

 

The reason I chose not to program arduino is to get my hands dirty and get accustomed to troubleshooting.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where are you getting your power supply from?

"This forum helps those that help themselves."

"How have you proved that your chip is running at xxMHz?" - Me

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ardblk wrote:
The reason I chose not to program arduino is to get my hands dirty
As I say an Arduino board does not necessarily mean the Arudino IDE (and library code). The fact is that you can just treat it as a well made 328 development board and program it "raw". The only bit of "Arduino" you really retain is the fact that it continues to use the bootloader and is programmed from the PC by avrdude (but all that can be done in complete isolation from the Arduino IDE).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

Where are you getting your power supply from?

 

I get VCC and GND from the programmer. Don't think power is the problem, the current reaches to the rightmost LED as in the first photo.

 

clawson wrote:

ardblk wrote:
The reason I chose not to program arduino is to get my hands dirty
As I say an Arduino board does not necessarily mean the Arudino IDE (and library code). The fact is that you can just treat it as a well made 328 development board and program it "raw". The only bit of "Arduino" you really retain is the fact that it continues to use the bootloader and is programmed from the PC by avrdude (but all that can be done in complete isolation from the Arduino IDE).

 

I'll try that too, thank you.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ardblk wrote:

I get VCC and GND from the programmer. Don't think power is the problem, the current reaches to the rightmost LED as in the first photo.

 

Are you sure? Not all USBASP programmers supply power without a link being made (JP3 if copied from the original). Can you check that 5V appears on pin 2 of the 10-way when it is not connected to your breadboard.

"This forum helps those that help themselves."

"How have you proved that your chip is running at xxMHz?" - Me

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

ardblk wrote:

I get VCC and GND from the programmer. Don't think power is the problem, the current reaches to the rightmost LED as in the first photo.

 

Are you sure? Not all USBASP programmers supply power without a link being made (JP3 if copied from the original). Can you check that 5V appears on pin 2 of the 10-way when it is not connected to your breadboard.

 

That was the problem. I connected external power supply, ywrobot mb v2, connected VCC and GND to pins 7 and 8 and also pins 20 and 22. Now it works like a charm.

 

Tried many times and no inconsistent messages from avrdude :)

 

Thank you very much.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ardblk wrote:

Thank you very much.

 

No problem. Have fun.

"This forum helps those that help themselves."

"How have you proved that your chip is running at xxMHz?" - Me

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't help but notice that the first thing AVRDUDE says, every tine , is...

>> avrdude: warning: cannot set sck period. please check for usbasp firmware update.

Unfortunately, that's "normal" for a lot of the VUSB-based "USBASP" programmers.  Fortunately, they seem to usually be slow enough that it doesn't matter.