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

Go To Last Post
22 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?

 

 

 

 

 

  • 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

 

 

 

 

 

 

  • 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

 

 

 

 

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!

 

 

 

 

 

 

  • 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

 

 

 

 

 

  • 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.

 

 

 

 

 

 

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