Uploading "blink" to external ATMEGA386P-AU with Arduino Uno R3 (beginner, getting started help)

I am new to Arduino but have legacy-era microcontroller experience (from 1970s) and extensive TI MSP430 experience. I am using Windows 10 and Arduino 1.8.16.

My goal is to upload an existing Arduino sketch ("blink" example) to an external ATMEGA386P-AU (TFQP32 package) part (purchased through distribution, was not previously configured with a boot loader), using my Arduino Uno R3 as a ICSP programmer (I'm not at first using the ICSP connector method, I've just wired the ATMEGA386P-AU pins as needed to the Arduino Uno R3 which runs ArduinoISP).

If successful, the result of this effort is to have the ATMEGA386P-AU toggle PD7 (pin 12 on the ATMEGA386P-AU) as if it were LED_BUILTIN (pin 13 on the DIP packaged ATMEGA386P-PU on my Arduino Uno R3.)

I am looking for help on how to troubleshoot this - I am unclear of the role of the Arduino Boot loader in my application, and I am unclear of how the target "board" is specified (I tried Arduino Uno, I did not see a way to tell Arduino that my target as an ATMEL386P part, but that's the base part number also on my Arduino Uno R3). In my application case, I have populated an ICSP (2x3 header) port to appropriate pins on the ATMEGA386P-AU chip, and plan to use the Arduino Uno (as an ISP using ArduinoISP running on the Arduino Uno R3) to upload my application firmware to the external ATMEGA386P-AU once it's in place on the application PCB.

I think at this stage I need to first clarify any concepts I'm getting wrong, then what the steps are involved to achieve my task, then once I am doing the steps properly, verify that I have made the proper electrical connections from the Arduino Uno R3 to my external ATMEGA386P-AU IC.

At the end of the steps I followed (further below), the upload operation resulted in the error message copied below.

Arduino: 1.8.16 (Windows 10), Board: "Arduino Uno"

Sketch uses 924 bytes (2%) of program storage space. Maximum is 32256 bytes.

Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.

avrdude: Yikes! Invalid device signature.

Double check connections and try again, or use -F to override this check.

An error occurred while uploading the sketch

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

How I got to this point:

  1. Verified that the Auduino Uno R3 could have "blink" uploaded directly to it (and I could change the delay and re-upload, seeing new LED blink rate.)

  2. Uploaded ArduinoISP to the same Arduino Uno R3. This appeared to complete without error.

  3. Wired a small adapter from Arduino Uno R3 pins specified by ArduinoISP sketch application:

Arduino Function ATMEGA386P-AU pin(s)
10 RESET 29
11 MOSI 15
12 MISO 16
13 SCK 17
GND GND 3,5,21
+5V +5V 4,6,18
Crystal 7
Crystal 8

The crystal is 20 MHz (this is the CPU speed intended for my final application.)

All other pins on the ATMEGA386P-AU IC are unconnected at this point.

The Arduino application is configured as follows when I try to upload the Blink example (that is, this is how I've configured Arduino software once I have (apparently successfully ) completed the upload of "ArduinoISP" to my Arduino Uno R3:

Tools -> Board -> Arduino Uno
Tools -> Port -> COM3 (where the Arduino Uno R3 connects)
Tools -> Get Board Info returns:

BN: Arduino Uno
VID: 2341
PID: 0043
SN: 9533335303735151C1B1

Tools -> Programmer -> Arduino as ISP

At this juncture, I tried Tools -> Burn Bootloader and got

Arduino: 1.8.16 (Windows 10), Board: "Arduino Uno"

avrdude: Yikes! Invalid device signature.

Double check connections and try again, or use -F to override this check.

Error while burning bootloader.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

I subsequently did:

Sketch -> Upload

and ended up with the error message text cited earlier in this posting.

Thank you very much for any help aiming me in the right getting-started direction!

Hello - have I posted this to the wrong part of the arduino forum?

Has this post been seen (just trying confirm I'm using the forum properly.)


Did you connect a 10MikroFarad capacitor between Reset and GND to the Arduino on which you uploaded the 'ArduinoISP' Skech?
Furthermore: In order for your Atmega (target system) to run at 20MHz, the fuses must be set correctly. The easiest way to do this is to upload a bootloader designed for 20MHz. please make a circuit diagram that shows exactly what you have connected to the Atmege328 and also shows the connections to the Arduino Uno. A photo that shows the structure well also helps to see whether plan and reality match. this is the only way we can help you effectively.

Thanks, Deltaflyer - appreciate the help and am more than happy to provide any further clarification or information you (or anyone) would like to see!

I've attached a diagram of my test set-up:

I am not married to the 20 MHz crystal frequency at this stage - I would just like to demonstrate that i can push code into the SMD part (hence why I chose Blink application.) I've not tried re-configuring the Fuse settings - they reflect the state of the IC as it came from the distributor.

Since my initial posting, I've been able to use AVRDUDESS "detect" function to tell the difference of whether the external CPU is attached:

: avrdude -u -c avrisp -P COM3 -b 19200 -F -p m8
Detected 1e950f = ATmega328P

or if the external CPU is not attached:

: avrdude -u -c avrisp -P COM3 -b 19200 -F -p m8
ERROR: Unknown signature 000000

I exported my copy of Blink (I call blink2, which has the time delays reset to 100 mS) and found two HEX files generated (one with, one without bootloader) - for a stand-alone application like this, do I choose with, or without bootloader? I chose without.

I uploaded the "blink2" version using AVRDUDESS (but did not change the Fuse settings so far); I also retrieved the fuse settings and these appear to have retrieved properly when the external CPU is attached. These are all show in the screen shot of AVRDUDESS below.


Here is a point of real confusion -- when I have the external CPU attached, after uploading BLINK2, the LED ON THE ARDUINO UNO R3 ends up flashing (at the ~10 Hz rate I chose, as I modified the timer values.) The corresponding pin (11) on the SMD part is not toggling (that pin is at 0V).

Does this (blinking LED on the Arduino Uno R3 board when the external CPU is attached via ICSP) instead of toggling the pin on my target CPU) suggest that AVRDUDESS is writing to and reading from the ATMEGA38P-PU DIP part on the Arduino Uno R3 board, instead of the external CPU ATMEGA386P-AU connected via the ICSP pins as shown in the diagram above?

If I remove the external CPU and run the Arduino Uno R3 only (which I think should only have ArduinoISP firmware at this point), the LED on the Uno blinks 3 times at power up (at the same ~10 Hz rate), then stays on steady. This has my REALLY puzzled!

Thanks very much for any further help through this!


If, after you have uploaded the Arduino-ISP to your UNO R3, you do NOT connect the 10 microfarad capacitor from the RESET pin of the UNO R3 to GND, and try to transfer a Skecht to the Atmega, the ARDUINO-ISP program on the UN deleted again. That is why this capacitor is absolutely necessary. And at the RESET PIN of the Atmega328 you absolutely have to attach a 10kOhm resistor to VCC so that the Atmega can run. In addition, a ceramic capacitor with a value of 22pF to GND is required at each connection of the quartz, pin 7 + pin 8, otherwise the quartz will not oscillate.

The LED on the Atmega can only flash if the flashing program has been correctly written into the flash and the processor is configured correctly, i.e. the RESET pin is set to HIGH and the clock oscillator is configured correctly. If on external quartz, the 2 22pF capacitors MUST be at pins 7 + 8.

OK - I'll make the required changes and continue forward. I'll post back with update once I've made these changes

Thanks very much for your help!


You're welcome

1 Like

Hardware changes made! Added 10 uF on UNO Reset to Ground (tantalum), added 47K on target RESET to +5V, added 22 pF to ground 2 places on target pin 7/8 (at crystal.)

Here's an updated diagram of the test set-up:

The capacitor on the Arduino board was installed after I re up-loaded the ArduinoISP application to the board, so my understanding is that the capacitor (RESET to GROUND, 10 uF) will inhibit further changes to the ATMEGA328P-PU DIP package part on the Uno.

To avoid confusion with the flash repetition rate that seems to be in the bootloader (appears to have been 10 Hz, which is by coincidence what I had initially set Blink2 to); I changed blink2 to 4 Hz rate (from 10 Hz.)

Now (with the Uno still ostensibly set as ArduinoISP and the 10 uF capacitor in place between RESET and GROUND on the Uno, I used AVRDUDESS to upload the (modified to 4Hz) version of BLINK to the target device.

After upload completed, the LED on the Uno was flashing at 4 Hz rate, the target's RESET pin (29) is indeed pulled up to +5V, and the intended output PD7 on the SMD part (pin 11) remains at 0V output or floating (can't tell which at this point.)

So, assuming that the capacitor installed on the Uno prevents the CPU there from intercepting any subsequent firmware upload, here's the behavior after uploading the modified Blink:

  1. No target attached, power-up Uno via USB. LED blinks 3 times rapidly, then is on steadily. AVRDUDESS "detect" function reports ERROR: Unknown signature 000000.

  2. Target attached, power-up Uno via USB. LED blinks 3 times rapidly, then starts blinking at 4 Hz rate, continuously. AVRDUDESS "detect" function reports Detected 1e950f = ATmega328P. Pin 11 of target device (PD7) is not generating output voltage pulses as expected.

Given that the Uno's CPU is evidently executing BLINK2 (the 4 Hz version), I do not see how the application ended up there rather than in the target device. I also do not see how AVRDUDESS is still able to treat the Uno as "Atmel AVR ISP" if it's running Blink2 (unless both programs can run concurrently??)

I tried both hex files from the build of Blink2 (with and without bootloader); the result is the same in both cases (the Uno's LED flashes at 4 Hz after it starts up, and Pin 11 of the target remains inactive.

That's as far as I can get at this point - would appreciate another look over my shoulder for sure!


Other post/duplicate DELETED
Please do NOT cross post / duplicate as it wastes peoples time and efforts to have more than one post for a single topic.

Continued cross posting could result in a time out from the forum.

Could you also take a few moments to Learn How To Use The Forum.

Other general help and troubleshooting advice can be found here.
It will help you get the best out of the forum in the future.

Is there a problem with my posting? Please elaborate specifically the problem you cite so I can participate better in the future.

Where a topic is related to one of your other topics or is similar enough to be considered by others as such then that qualifies as CROSS POSTING.
They then report those types of post and depending on the final view of a moderator action is either taken or not.

(ballscrewbob please see below)

(to those that replied with technical advice, thank you!)

I have sufficiently resolved the issues and will be able use the tools as intended.

After reading the Arduino Uno R3 schematic, I found the correct CPU pin (DIP and SMD) as well as PCB for the LED used by BLINK. The LED shares with one of the ICSP pins. I had initially confused the board pin number with the chip pin number. By virtue of the shared pin, the LED illuminates on the Arduino Uno R3 PCB even though the target is externally attached by ICSP (where the Arduino Uno R3 is running ArduinoISP.) There were no instances of code executing in the wrong place, just a mis-identification of the BLINK LED placement in the circuit.

The previously recommended 10 uF capacitor was not necessary and was removed. The Arduino Uno R3 is now set as ISP, serves that function as intended and does not require any modifications to serve as ICSP device.

To "ballscrewbob" (in response to your postings on 10/19/2021 of an administrative matter into this technical topic 916097): Your posts into this thread regarding my incorrect other posting was unfortunate and inappropriate. In forums I moderate, advice and counsel to users is ALWAYS provided individually, NEVER in a thread. Complaints between users are resolved through moderatators, not within threads. I do not know if your action is standard moderation practice in arduino.cc forum, but it is corrosive and discourages participation.

Which means that the advice is not seen by other users who might benefit from it

But this was not a complaint between users so was handled publicly

Really now? Then you are probably the only one who can use an Arduino Uno WITHOUT this capacitor as an ICSP programmer, or anyone else who follows the TESTED PROCEDURES and builds this capacitor because it simply doesn't work without it, are doing something fundamentally wrong.
Without a capacitor, the UNO does a reset and goes into flash mode itself, which means that it writes the sketch, which should actually be written in the target system, in its own bottle memory, provided it is intended for an Atmega328. The only way to prevent this (without the capacitor) would be to disconnect the RESET line to the USB chip on the Uno after uploading the Aurduino ISP Sketch, so that no reset is possible via USB.

Es ist natürlich Möglich, dass Du sehr viel mehr von Elektronic und dem Ablauf des Flaschvorganges mittels USB und Bootloader, sowie ICSP verstehst als ich und jene, die sagen, dass der Kondensator benötigt wird.
Dann habe ich dir natürlich unrecht getan, und ich muss dann wohl den Nano, den ich mir als ISP-Programmer fix ausgestattet habe (so dass ich nicht jedes mal neu aufbauen muss, und ein kompaktes Gerät habe) nochmals zerlegen, und den Kondensator entfernen.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.