cannot upload code through the Arduino IDE to the ATMEGA328P U-TH

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

Hi,

I've been strugling with this issue for quite some time now, so lets see if someone from the forum can help.

I have a working PCB with ATMEGA328P. I used to download the optiboot_atmega328.hex boatloader in the ATMEGA 328P-AU (tqfp 32 package) and then upload sketches via the Arduino IDE. This worked well!

Now (and I've tried 3 different resellers) the -AU seems to be replaced by the U-TH suffix.
For instance I ordered these from Farnell:https://nl.farnell.com/microchip...

Farnell answers in a reply: right now this chip seems to be replaced by a chip with another inscription with U-TH on the end. (see photo).
I've contacted the chip manufacturer but they didn't respond.

Problem: with this chip variant (if it is a variant? I can't find out) the bootloader optiboot_atmega328.hex still goes in ok, but the uploads from sketches from the Arduino IDE won't work anymore.
Verbose messages are:

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x3a
....

 

Recently I have ordered an Arduino nano-mini which uses the same AU chip from the picture as reference. When it came in, I saw it is also using the same U-TH suffix. This board does upload the the bootloader optiboot_atmega328.hex as Arduino IDE sketches well.

 

Now it looks to me there is a hardware problem but I can't find out a functional difference between the nano-micro board and my own board. And because on the nano board the the bootloader optiboot_atmega328.hex bootloader works fine, this also shouldn't be the problem.

I also tried multiple upload cables (I'm using USB FTDI cables).

Since my hardware did work fine with the -AU versions, I could really use some advice!

See attached schematics.

 

Question:
Does someone knows how to solve this issue?

Is another bootloader or hardware modification necessary?

Thanks

Attachment(s): 

Last Edited: Mon. Sep 16, 2019 - 09:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The new chip should work exactly the same as the old one.

I presume that it is mounted on exactly the same pcb as the previous one i.e. with good 16MHz xtal.

 

Always use the Arduino IDE to "Burn Bootloader".

This ensures that the fuses and lock bits are set correctly.

 

We are all human.   If you install the bootloader manually,   you often forget the fuses and lock bits.

 

Try again.  Please let us know how you get on.

 

David.

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

Hi, thanks for the reply.

Yes, the PCB layout is the same. I just replaced the XTAL and 22nF caps by some brand new ones but that didn't help.

You triggered me regarding the Xtal. I used a scope and did see a difference in the signal.

Measuring at the Xtal pins doesn't seem to give a nice sinus...

Still trying to figure out why...

It should already start to oscillate at 16Mhz when just applying power on the chip right?

 

 

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

Nothing will oscillate with 22nF. You should use 22pF.
You should see 16MHz on XTAL2 pin with a x10 scope probe.
..
I would just "Burn Bootloader" again with an external programmer.
If there is a problem copy-paste the error report to your message.
.
David.

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

I am using 22pF, I mistyped.

I can upload the optiboot bootloader with external programmer, this all works ok.

Does uploading the bootloader requiring the external oscillator?

Last Edited: Mon. Sep 16, 2019 - 12:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

spoetnic wrote:
Does uploading the bootl oader requiring the external oscillator?

Not to UPLoad, but like any other program that expects specific timing, it must have the osc configuration it is expecting.

There are several boot loaders to choose from, ones that expect external xtal (at a specified frequency) or expect to use the internal RC(again at a specified frequency)

Have you chosen the correct one for your application / board?

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

I'm using an external programmer. I can read the device's signature and voltage. Both OK.

ISP clock : 125kHz

I can upload the bootloader without a problem.

 

What is the correct setting I matched the fuses of the new proc. similar to the old one, but still I can't upload through the Arduino IDE...sad

What can this be...a fuse problem? 

 

I tried several options for the fuses: LOW.SUT_CKSEL, but now I have an additional problem. I can't access it anymore with the external programmer.

Probably set some wrong fuses. Any suggestions besides replacing the chip?

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

do you have the 0.1uf cap from dtr to the reset pin connected?  It's used to kick the micro into bootloader mode.

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

what do you mean? dtr I know from serial (RS232) port, but we're using USB-FTDI for uploading from the Arduino board ( https://components101.com/cables/ftdi-cable-usb-to-rs232-converter )

And SPI from the external programmer (MOSI, MISO, CLK)

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

Write down the actual steps. e.g.

 

1. connect external programmer to ISP header.

2. run Arduino IDE

3. select Uno

4. run Tools->Burn Bootloader

5. ...

 

If you number the steps it is easy to say where it goes wrong.

 

You should always be able to run (1) to (4)

 

The Bootloader starts when the board gets a "Reset" pulse.   Either from a DTR capacitor or by you pressing the Reset button.

 

David.

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

spoetnic wrote:
but we're using USB-FTDI for uploading from the Arduino board

Sorry the Arduino Pro-mini calls the RTS pin on your cable DTR my mistake. 

Wire a 100nf cap from RTS to reset, avrdude uses this pin to trigger a reset to enter the bootloader when you try to upload code.

With out this cap, you have to time a manual reset "just right" to get a load to work.

See the schematic for the pro-micro as an example of a M328 wired for external ttl-usb serial cable connections.

https://www.google.com/url?sa=t&...

 

Jim

edit, wrong pro-mini link

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Mon. Sep 16, 2019 - 08:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Thanks but I already have this 100nF reset cap between the RST of the cable and the chip (pin 29). I also tried to replace it, but that didn't help.

 

Right now I have another problem since the bootloader cannot be uploaded anymore by the external programmer after testing various fuse settings.

 

If I click on 'Device signature' I get this message. 

 

This should always work right, regardless of the fuse settings?

 

 

 

After re-soldering a new chip to my custom board I still have the same issue as before with uploading with the Arduino IDE.

Step by step:

 

 

 

 

1): connecting external loader to Atmel studio and upload bootloader optiboot_atmega328.hex over ISP connector (MISO,MOSI,SCLK).

This works (even without X-tal)

2): upload blink sketch over USB-FTDI connector (the converter is working on other application)

This is not working! 

After maybe 30s it goes into errors:

 

I also tried other 16Mhz Xtals, but no improvement. Also I do not measure a proper sinus at the Xtal inputs. This might very well be related, but I don't know what is the cause...maybe fuse settings?

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

Seriously.   I advised you to use "Burn Bootloader"

 

If you choose to install manually with AS7.0 we need to see that you programmed Fuses and Lockbits.

 

God gave you the Arduino IDE.   You should use it.

IDE v1.8.9 contains Programmer entries for JTAGICE3

 

David.

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

spoetnic wrote:
This should always work right, regardless of the fuse settings?

NO, the chip must have power, and a working clock source for that to work!

Improper fuse setting will brick the chip, see tutorial section here for how to recover!

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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


spoetnic wrote:

Since my hardware did work fine with the -AU versions, I could really use some advice!

See attached schematics.

I have no experience about Arduino, maybe not related to your problem but there is an issue with your schematic

You do know 100nF bypass cap is supposed to be between Vcc and Gnd of MCU as close as possible to MCU

I can't figure out why 100 uH is in series from Vcc to MCU , is it ferriet bead?

 

Majid

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

Oke, lets try.

Hereby the messages while using the atmel ICE3 for "burn bootloader" on the prestine Arduino IDE:

 

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\Marc Friedheim\Desktop\arduino-1.8.9\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : jtag3isp
avrdude: usbhid_open(): No device found
avrdude: Found CMSIS-DAP compliant device, using EDBG protocol
         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 : JTAG3_ISP
         Description     : Atmel AVR JTAGICE3 in ISP mode
         Vtarget         : 4.6 V
         SCK period      : 125.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: WARNING: invalid value for unused bits in fuse "lock", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xff instead of 0x3f (double check with your datasheet first).
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xFD"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.09s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xFD:
avrdude: load data efuse data from input file 0xFD:
avrdude: input file 0xFD contains 1 bytes
avrdude: reading on-chip efuse data:

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

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xDE"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.09s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDE:
avrdude: load data hfuse data from input file 0xDE:
avrdude: input file 0xDE contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):

Writing | avrdude: Short read, read only 0 out of 512 bytes
avrdude: jtag3_edbg_recv(): Inconsistent fragment number; expect 1, got 0
avrdude: stk500v2_jtag3_recv(): error in jtagmkII_recv()
################################################## | 100% 0.31s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | avrdude: Short read, read only 0 out of 512 bytes
avrdude: jtag3_edbg_send(): Unexpected response 0x00, 0x00
avrdude: stk500v2_command(): command failed
avrdude: stk500isp_read_byte(): timeout/error communicating with programmer
avr_read(): error reading address 0x0000
    read operation not supported for memory "lfuse"
avrdude: failed to read all of lfuse memory, rc=-2
avrdude: jtag3_edbg_recv(): Inconsistent fragment number; expect 1, got 0
avrdude: stk500v2_jtag3_recv(): error in jtagmkII_recv()
avrdude: Short read, read only 0 out of 512 bytes
avrdude: jtag3_edbg_send(): Unexpected response 0x00, 0x00
avrdude: Short read, read only 0 out of 512 bytes
avrdude: jtag3_edbg_recv(): Unexpected response 0x11
avrdude: Short read, read only 0 out of 512 bytes
avrdude: jtag3_edbg_send(): Unexpected response 0x00, 0x00
avrdude: Short read, read only 0 out of 512 bytes
avrdude: jtag3_edbg_recv(): Unexpected response 0x11
avrdude: Short read, read only 0 out of 512 bytes
avrdude: jtag3_edbg_signoff(): failed to read from serial port (0)

avrdude done.  Thank you.

Error while burning bootloader.
 

 

 

After this, no communication possible anymore, also not via AS7....great....

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

Yes thanks but I have a decoupling capacitor of 100nF close by and over power. 

A similar PCB worked before, so this makes it odd...

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

Remove the 1M resistor across the xtal, it is not needed with AVR's.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

 

Hi Jim, done that but the fuse settings seems wrong after last "burn bootloader" attempt from Arduino IDE.

 

Can't get the device's signature anymore.

Also I noticed this text during the Arduino IDE "load bootloader" ritual:  avrdude: Device signature = 0x1e950f (probably m328p)

 

what does this mean?

Last Edited: Tue. Sep 17, 2019 - 02:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

spoetnic wrote:

I tried several options for the fuses: LOW.SUT_CKSEL, but now I have an additional problem. I can't access it anymore with the external programmer.

Probably set some wrong fuses. Any suggestions besides replacing the chip?

spoetnic wrote:
Device signature = 0x1e950f (probably m328p)

That is the correct signature for the M328, so all good there, but now it can not be read, so most likely the xtal is not running.

Check for shorts, opens and if that 1M resistor is there, remove it. 

Once the clock is running, you will be able to read the signature again. 

Jim

 

if all else fails, you can inject a clock signal from an external device, such as an arduino to recover the fuse settings and return to internal RC.

But it sounds like something is preventing the xtal from running.

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Tue. Sep 17, 2019 - 03:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I have a problem with atemega328P U-TH, I can't burn arduino bootloader to the chipset, in the end I found the solution, burn bootloader and upload sketch.
I use atmega328p U-TH with crystal 16Mhz, two capacitors 22pf, 10k resistor between pin 29 (reset) and Vcc (5V), 0.1uf capacitor between pin 20 (AREF) and GND to burn bootloader I m using arduino nano with atmega328p chipset its work perfectly, I will share a video on YouTube for the solution.
Thanks

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

Glad you got it working, please note the AVCC and AGND pins must also be connected to power and both sets of power pins need a 100nf Bypass cap to GND.

 

jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Hi,

This is my first post here ;-)

I am facing the same situation: I am using an OLIMEX programmer (STK500) to upload the hex files directly onto my boards (so as to say, I do not use bootloaders). It works like a charm on FIO boards, same on breadboarded ATMEGA328P-PU (DIL) clocked at 8 or 16 Mhz. The same procedure failed while uploading on custom boards. After many attempts, I found that the chip I got from mouser was a ATEMAG328P-U TH although I ordered an ATMEGA328P-AU for sure. I decided to transplant a chip from a Nano board (chip stamped ATMEGA328P-AU) onto my custom board. This surgical operation was successful: my custom board works fine with the "nano processor". I placed a claim to mouser with pictures. They agreed to refund me and to check their stocks. As they announced that the checking could take time, I placed an order to Farnell. Gasp, I got ATMEGA328P-U TH which do not work either.

I really do not know what's wrong with these ATMEGA328P-U TH. Is the pinout different ? Should I place an order to Microchip directly? I am really confused.

 

Next is the feedback I get while uploading to an ATMEGA328P-U TH
 

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\dlongueville\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : COM5
         Using Programmer              : stk500
         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 : STK500V2
         Description     : Atmel STK500
         Programmer Model: STK500
         Hardware Version: 2
         Firmware Version Master : 2.10
         Topcard         : Unknown
         Vtarget         : 3.2 V
         SCK period      : 2.2 us
         Varef           : 3.2 V
         Oscillator      : 60.433 kHz

avrdude: stk500v2_command(): warning: Command timed out
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

 

And this was I get while uploading to an ATMEGA328P-AU

 

 

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\dlongueville\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : COM5
         Using Programmer              : stk500
         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 : STK500V2
         Description     : Atmel STK500
         Programmer Model: STK500
         Hardware Version: 2
         Firmware Version Master : 2.10
         Topcard         : Unknown
         Vtarget         : 3.3 V
         SCK period      : 2.2 us
         Varef           : 3.2 V
         Oscillator      : 60.433 kHz

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)
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 "C:\Users\DLONGU~1\AppData\Local\Temp\arduino_build_878589/blink.ino.hex"
avrdude: writing flash (488 bytes):

Writing | ################################################## | 100% 0.09s

avrdude: 488 bytes of flash written
avrdude: verifying flash memory against C:\Users\DLONGU~1\AppData\Local\Temp\arduino_build_878589/blink.ino.hex:
avrdude: load data flash data from input file C:\Users\DLONGU~1\AppData\Local\Temp\arduino_build_878589/blink.ino.hex:
avrdude: input file C:\Users\DLONGU~1\AppData\Local\Temp\arduino_build_878589/blink.ino.hex contains 488 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.08s

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

Last Edited: Wed. Jan 6, 2021 - 07:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

plaintronix wrote:

Next is the feedback I get while uploading to an ATMEGA328P-U TH
avrdude: stk500v2_command(): warning: Command timed out
avrdude: initialization failed, rc=-1

plaintronix wrote:

And this was I get while uploading to an ATMEGA328P-AU

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)

 

Your first AVR has no clock.   Which is probably because the fuses are set for a crystal and you have not provided a crystal.

 

The second AVR is fine.   Please read the fuse values and report back.   I suspect that it is running off the Internal 8MHz RC

 

Yes,  I know that all AVRs should come from the factory with fuses set for Internal 8MHz RC but sometimes they have been set differently.

 

Provide an external clock to XTAL1 pin on the first AVR.   Program the fuses to Internal 8MHz RC

Try again but without the external clock.

 

David.

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

Some suppliers will ship factory fresh M328's, internal R/C osc, clock 1/8 fuse, etc., while others will ship Arduino ready M328's that have the bootloader installed, and require an external xtal/caps in order to run. Check carefully which type you order!

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Thanks for your inputs.

Taking into account the fuses questions, this what I did to make 100% sure about the hardware:

I soldered a fresh ATMEGA328P-U TH on a PCB adapter, wired it onto a breadboard (including a 8 MHz crystal) powered by a lab power supply (3.3V).

Before running the tests, I exercised the programmer on a Nano board using some avrdude commands: running fine

I performed the same tests on the ATMEGA328P-U TH: failure. No communication. I checked the wiring twice: no change. Same report while reading the fuses:

 

avrdude -c stk500 -p m328p -P COM5 -b 19200 -v -F

 

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\dlongueville\Documents\Arduino\tools\avrdude\avrdude.conf"

         Using Port                    : COM5
         Using Programmer              : stk500
         Overriding Baud Rate          : 19200
         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 : STK500V2
         Description     : Atmel STK500
         Programmer Model: STK500
         Hardware Version: 2
         Firmware Version Master : 2.10
         Topcard         : Unknown
         Vtarget         : 3.3 V
         SCK period      : 2.2 us
         Varef           : 3.3 V
         Oscillator      : 60.433 kHz

avrdude: stk500v2_command(): warning: Command timed out
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000 (retrying)
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATmega328P is 1E 95 0F

avrdude done.  Thank you.

 

Same averdude command applied to the nano gives:

 

 

avrdude -c stk500 -p m328p -P COM5 -b 19200 -v -F

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\dlongueville\Documents\Arduino\tools\avrdude\avrdude.conf"

         Using Port                    : COM5
         Using Programmer              : stk500
         Overriding Baud Rate          : 19200
         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 : STK500V2
         Description     : Atmel STK500
         Programmer Model: STK500
         Hardware Version: 2
         Firmware Version Master : 2.10
         Topcard         : Unknown
         Vtarget         : 3.2 V
         SCK period      : 2.2 us
         Varef           : 3.2 V
         Oscillator      : 60.433 kHz

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as FD

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:DA, L:FF)

avrdude done.  Thank you.

 

I cannot stand it... good grief !

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

It's time you showed some pics of your setup! 

Your doing something wrong, power not being applied to all vcc/avcc pins and all gnd pins, no decoupling caps,  fuse settings mistake, etc....

Show us your setup.

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

plaintronix wrote:
I am using an OLIMEX programmer (STK500) to upload the hex files directly onto my boards

We can only guess that Olimex behaves like the genuine Atmel STK500

 

plaintronix wrote:

avrdude -c stk500 -p m328p -P COM5 -b 19200 -v -F

Never use -F

The genuine STK500 will work at 115200 baud by default.   19200 baud is supported but it will be very SLOW.

 

plaintronix wrote:

avrdude: safemode: Fuses OK (E:FD, H:DA, L:FF)

Yes,  the Arduino Nano has fuses set for a XTAL / Resonator.   And so do all the other Arduino boards that use an AVR.

 

plaintronix wrote:
I soldered a fresh ATMEGA328P-U TH on a PCB adapter, wired it onto a breadboard (including a 8 MHz crystal) powered by a lab power supply (3.3V).

As Jim has suggested,  we need to see that you have connected all the correct pins.

 

My "guess" was that your AVR had fuses set for a crystal instead of 8MHz RC.   If your schematic is correct,  the programmer would work for both situations.

 

Other fuse settings are possible but VERY unlikely from the factory.

However a user might have programmed "External Clock" by mistake.   Please understand that -F can result in anything happening.

 

David.

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


plaintronix wrote:
I am using an OLIMEX programmer (STK500)

This: https://www.olimex.com/Products/AVR/Programmers/AVR-ISP500/ ?

 

 

Have you contacted Olimex?

 

There's a 'Support' email link at the bottom of the page, or:

 

https://www.olimex.com/forum/

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't have an Olimex programmer but many people do.

I would be pretty confident that Olimex programmers implement STK500 commands correctly.

 

It is much more likely to be a broken or misplaced wire(s).

Or an unfortunate consequence of using -F

 

I know that I mis-programmed the clock fuses in the days of LPT programmers.

I suspect that several older members have done something similar.

Modern programmers are less prone to glitches (unless you use -F)

 

David.

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

 

I have this Olimax programmer, so much faster then my dragon when programming.

Works just like the original mkII, but has the option of supplying target power.

What is the avrdude command to just read the signature of the chip?

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Wed. Jan 6, 2021 - 07:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
in the days of LPT programmers.

It seems they still have some: https://www.olimex.com/Products/AVR/Programmers/AVR-PG2B/

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

plaintronix wrote:

I am using an OLIMEX programmer (STK500)

 

This: https://www.olimex.com/Products/AVR/Programmers/AVR-ISP500/ ?

 

 

 

Yes

awneil wrote:

 

Have you contacted Olimex?

 

 

No.

 

The programmer works with all sorts of boards (Uno, FIO, Mini, chineese UNO, etc.). Why should I bother so much abut the programmer ??? Any hint ?

 

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

I removed the -F argument from my avrdude commands: same failure

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

I'm out, OP is ignoring requests for pics!

Good luck with your setup!

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Inject some kind of clock into the XTAL1 pin of the ones that won't talk. I have a post in the Tutorial Forum about locked AVR that gives a number of ways to generate such a clock (the CLKO pin of a working 328 is one of the simplest)

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

 

I am afraid that a simple picture from the assembly will not be very useful. I took the time to sketch the schematics:

And here is a picture of this assembly

 

 

 

 

 

Last Edited: Wed. Jan 6, 2021 - 10:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't see any bypass caps? Seems everyone knows about needing caps for the crystal, but bypass caps get conveniently ignored.

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

The Adapter soldering "looks" ok.

There are no bypass capacitors e.g. 100nF ceramic.

Electrolytic capacitors are not suitable.

 

We can't see the crystal wires, ...

Breadboards are not very reliable.  Especially with thin wires.

 

I would use a "safe" clock signal e.g. an 8MHz square wave from another AVR e.g. an Arduino using a Timer in CTC mode.

The Arduino could provide the power too.   e.g. 5V

 

Crystals might be bad.   Breadboard connections might be bad.

I am always suspicious of wires poked into ribbon cables.

ISP should use a proper soldered 3x2 ISP header (or 5x2 header if you prefer)

I am confident that your Olimex is fine.

 

David.

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

We are talking about breadboarding here, featuring parasitic capacitors all around the board mainly in the crystal area. Also remember that this assembly is fed by a lab power supply and short wires. My experience is that inappropriate use of capacitors (location and values) may be worse than none or few. Anyway, I followed your advice and I placed a couple of 0.1 µF ceramic capacitors next to the 100µF and one as close as possible from the MCU.

The test still fails. 

For your records I am performing the tests in parallel with a breadboarded ATMEGA328P-PU (DIL) so that I have been able to swap components (eg crystal, capacitors) in order to reject probable causes.

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


Kartman wrote:
I can't see any bypass caps? 

are they supposed to be here:

not terribly effective on the ends of "long" wires + breadboard connections ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


david.prentice wrote:

We can't see the crystal wires, ...

 

Here they are ! The crystal connections are tight!

 

 

 

david.prentice wrote:

Breadboards are not very reliable.  Especially with thin wires.

 

You are right. That's the reason why I am using 0.6 mm plated wires which feature the largest gauge compatible with most breadboards.

 

david.prentice wrote:

I would use a "safe" clock signal e.g. an 8MHz square wave from another AVR e.g. an Arduino using a Timer in CTC mode.

The Arduino could provide the power too.   e.g. 5V

 

Remember, I am performing these tests in parallel with a breadboarded ATEMEGA328P-PU; this other configuration works like a charm

 

david.prentice wrote:

I am always suspicious of wires poked into ribbon cables.

I am in full agreement: Here are terminals that You could not see.

 

 

 

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

 

awneil wrote:

Kartman wrote:

I can't see any bypass caps? 

 

are they supposed to be here:

not terribly effective on the ends of "long" wires + breadboard connections ...

 

Again, and again, we are talking about quick and dirty prototypes, not ultimate performances. I am afraid that you mistake me for rookie because this is my post here... Although I understand that information is required for helping appropriately, some common sense applies too.

 

Next is a picture of the "final" layout of the MCU area

 

which as obviously nothing to do with the prototypes. I hope this point is now sorted out...

 

 

Last Edited: Wed. Jan 6, 2021 - 11:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

My "guess" was that your AVR had fuses set for a crystal instead of 8MHz RC.   If your schematic is correct,  the programmer would work for both situations.

 

Other fuse settings are possible but VERY unlikely from the factory.

However a user might have programmed "External Clock" by mistake.   Please understand that -F can result in anything happening.

Please realise that sh*t happens.   If the fuses are not Xtal or RC then an External Clock is required.

 

plaintronix wrote:
My experience is that inappropriate use of capacitors (location and values) may be worse than none or few. Anyway, I followed your advice and I placed a couple of 0.1 µF ceramic capacitors next to the 100µF and one as close as possible from the MCU.

That sounds a little Trumpian.   

For someone who seems to have some experience it is an unusual comment.

 

Yes,   your Xtal and 3x2 arrangement looks reliable.    For the sake of connecting an external clock signal you will not get too far.   External clock wins against anything other than RC.   And RC can never go wrong.

 

There are other possibilities.    RSTDISBL fuse is more trouble than it is worth.   Chuck the chip.

DWEN fuse is solvable.  

Neither RSTDISBL or DWEN will ever come from the factory.   But they can come from -F

 

David.

Last Edited: Wed. Jan 6, 2021 - 11:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

I'm out, OP is ignoring requests for pics!

Good luck with your setup!

 

Jim

 

 

Would a moderator let me know the rules which apply to the delays in answering to picture requests ?

Would a moderator let me know if not providing a picture within 4 hours after a request is synonym in this forum of "ignoring requests" ?

Would a moderator let me know if this is standard policy to be so rude to a new comer ?

 

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

No one is being rude.

 

Some topics can be cleared up within minutes.    But not everyone can reply immediately.

Just say so.   e.g. say you are busy and will post photos later.

 

Incidentally I am allergic to cameras.   I just don't seem able to take any non-blurry photos.

 

David.

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

david.prentice wrote:

That sounds a little Trumpian.   

For someone who seems to have some experience it is an unusual comment.

 

I will be happy to discuss this topic in private ;-)