arduino 328p wont upload code. error avrdud: stk500_getsync(): not in sync: reap=0xe0

[peter zwag]

My DIL ATMEGA 328P wont upload code.
the atmega328p is minimal setup. crystal, 2 caps, reset cap & 10k resistor + led & resistor.
The serial output works fine as a sketch is loaded (via isp) the transmits serial.

Im not convinced the reset works, but regardless I have tired many times manually pressing reset button (at right point of upload) - and it still fails.

I have two different variants of 328p, and both fail
A nano always works!
I am using a ftdi serial convertor that I think has non genuine ftdi chip.


I also put the 328p chips in a duemilanove, and it fails via external ftdi chip and its own usb port. (I had previously assumed the internal usb chip was faulty, but now im not sure on this)

Any ideas? There is lots written on the web, but nothing worked.
returned error is "error avrdud: stk500_getsync(): not in sync: reap=0xe0"

[Joshua Mesilane]

Erase the chip via ISP and re load the boot loader and try again.

----

VK3XJM

0416 039 082

http://www.zindello.com.au/

jo...@zindello.com.au

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to connected-community-h...@googlegroups.com.
To post to this group, send email to connected-commu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/067ec829-ef8d-4ea3-a170-4fe119b8798a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[peter zwag]

thanks for the comment. Tried it on two chips and made no difference

--
You received this message because you are subscribed to a topic in the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/connected-community-hackerspace/CuqNTpNNVnQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to connected-community-h...@googlegroups.com.

To post to this group, send email to connected-commu...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/A5488A77-355E-473C-B24A-BB00B413DCA6%40zindello.com.au.

For more options, visit https://groups.google.com/d/optout.

--

Thanks
Peter Zwag
pe...@zwag.id.au

[Darren Freeman]

On Fri, 2015-02-06 at 15:59 -0800, peter zwag wrote:
> Im not convinced the reset works, but regardless I have tired many
> times manually pressing reset button (at right point of upload) - and
> it still fails.

It can be hard to guess where the right point is, but if you've tried
multiple times, I would hope you'd get it to work at least once :)

You can have something like eight seconds between reset and start of
upload, so I would err on being generous with the delay so that you
don't have reset held when it starts.

Is the crystal frequency identical to the one set in the active board
definition? If not, this happens. The bit rate of the serial connection
is derived from the crystal.

> I also put the 328p chips in a duemilanove, and it fails via external
> ftdi chip and its own usb port. (I had previously assumed the internal
> usb chip was faulty, but now im not sure on this)

It sounds like you have inadvertently not uploaded (or trashed!) the
standard Arduino boot-loader along with the code that works. Can you
check that there is a delay between power on or reset, and the start of
your code executing? If it's always pretty much instant, then it's not
waiting for an upload.

I'm not sure whether it always uploads the boot-loader when programming
via ICSP. It's possible that the boot-loader is unprogrammed and yet
your code starts okay.

Have fun,
Darren

[Darren Freeman]

On Fri, 2015-02-06 at 15:59 -0800, peter zwag wrote:

> My DIL ATMEGA 328P wont upload code.

It's definitely a 328P and not a 328 without the P?

[Zac Faragher]

If you're using Arduino V1.0 to flash the firmware, I recall that there was a problem with the Serial buffer size (either in the firmware or the environment itself) that caused me to have a similar problem. Updating the IDE fixed it.

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to connected-community-h...@googlegroups.com.

To post to this group, send an email to connected-commu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/1423269330.11993.20.camel%40freemaninstruments.com.

[peter zwag]

Its 328p-pu  1436 & the other is 328p-pu 1417 (element14)

I know the boot loader is fine, and it fails to upload regardless of where I manually do a reset

Im using 1.06 ide, but have tried 1.05 and the nightly build

--
You received this message because you are subscribed to a topic in the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/connected-community-hackerspace/CuqNTpNNVnQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to connected-community-h...@googlegroups.com.

To post to this group, send an email to connected-commu...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/1423269425.11993.21.camel%40freemaninstruments.com.

For more options, visit https://groups.google.com/d/optout.

[Darren Freeman]

On Sat, 2015-02-07 at 12:15 +1100, peter zwag wrote:
> I know the boot loader is fine, and it fails to upload regardless of
> where I manually do a reset

And yet you say that you tested these chips in a known good board and
they still won't upload.

Either the boot-loader is not fine, or the chips themselves are not
fine.

Or perhaps the "known good" boards are not fine. How sure are you that
they're fine? Has this version of software successfully uploaded the
same code to these known good boards?

Any chance that you killed the serial I/O pins on these chips? Have you
tried running some code that tests both reading and writing to serial?
(On the known good boards, upload via ICSP.)

Have fun,
Darren

[peter zwag]

Hi Darren

I have two difference sources of chips, and all had the same issue.

The nanos work however.

I may have to beg buy or borrow a working duemilanove - if i can get a dil version still

The serial read was a great idea. I tried and found serial read works fine

--
You received this message because you are subscribed to a topic in the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/connected-community-hackerspace/CuqNTpNNVnQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to connected-community-h...@googlegroups.com.
To post to this group, send an email to connected-commu...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/1423272442.11993.26.camel%40freemaninstruments.com.

For more options, visit https://groups.google.com/d/optout.

[Luke Weston]

OK, so you've got your new ATmega328P chips from a credible
distributor who won't sell you a housebrick with ATmega328P painted on
it. And they should be ATmega328P - with a P - by the way.

The easiest way to proceed, for an Arduino-compatible end result, is
to take some sort of Arduino-equivalent board with a 28-DIP socket,
Uno or whatever, remove the existing chip, put the new chip in (make
sure the orientation is right), connect an ISP programmer to the ISP
header (make sure the connector orientation is right) and program the
chip with an Arduino bootloader using the "burn bootloader" option in
the Arduino IDE. This is much easier for beginners than getting the
command-line parameters for avrdude right. The only thing you'll need
to check in the Arduino IDE is that you've selected the appropriate
programmer type that you're using. (What is it?) The target board type
can just be selected as Arduino Uno.

Using an Arduino-equivalent board to hold the chip during programming
means that all the wiring between the ISP programmer port and the chip
is known to be right, and you've got power and a decoupling capacitor
and a crystal provided, so you don't have to wire anything up, and
there's no uncertainty.

If you're using a USBASP compatible programmer, such as the
Freetronics one, then the first time you program virgin chips, because
of the way the oscillator fuse is set up, you'll need to plug in the
"Slow Clock" jumper on the programmer. This only has to be done once
the first time the chip is programmed, and for later iterations it
will be much faster.
If the chips fail to program, then you can report back more details
about what programmer you're using, and what happens, etc.

Now, re-flash the bootloader on all the chips you've already got.
Once the bootloader is programmed, you can test uploading code via the
USB serial port, using the pre-made Arduino-compatible target board
used to flash the bootloader. Again, this removes uncertainty in how
things are wired up.

If that works, put the chip on a breadboard, and connect +5V and
ground from an FTDI cable (or similar USB virtual serial port device)
to the AVR chip, and ensure that all the chip's Vcc and ground pins
are connected together, and put a 0.1uF decoupling capacitor between
one of the power pins and ground, close to the chip.

Connect TXD coming out of the FTDI cable to PD0 (RXD, pin 2) on the
chip, and connect RXD on the FTDI cable to PD1 (TXD, pin 3). (Check
these aren't swapped.) Put your 16 MHz crystal on the crystal pins
(ensure it's 16 MHz) and put the crystal load capacitors (say 18pF)
between each of the crystal pins and ground, next to the crystal. Put
a pull-up resistor (say 10k) between PC6 (reset, pin 1) and +5V, and
connect a 0.1uF capacitor in series between this pin and the nRTS pin
on the FTDI cable. If power is supplied externally, not from the FTDI
cable, then ensure that it's working and appropriately regulated.

Now, with the FTDI cable plugged into your PC, the virtual serial port
will be a different one than it was before, so select the right one,
and you can upload Arduino sketches.

If that works, if you want to, you can try connecting the ISP
programmer to the 6 appropriate pins on the AVR on the breadboard -
Vcc, ground, nRESET, MISO, MOSI, SCK - and burning the bootloader to a
chip on the breadboard.

Note that if your target AVR board has hardware attached to the AVR
then this may interfere with programming - if another UART device is
connected to the AVR this will need to be appropriately isolated, or
disconnected, when uploading Arduino sketches over the serial port. If
SPI peripheral devices or other hardware is attached to the AVR's SPI
pins, or reset pin, then this may interfere with programming if
they're keeping the pins driven or pulled to an inappropriate state
that the programmer can't overcome. If there's a problem with a
standard SPI peripheral and disconnecting it isn't practical, and the
nCS line is controlled by the AVR, putting pull-up resistors on the
nCS lines to keep them definitely de-asserted on the SPI bus during
AVR programming can fix that problem. So try disconnecting extra
hardware from your target board if practical - but if this is a
problem you will know about it, since programming will work fine using
an Arduino but fail on your target board.

> --
> You received this message because you are subscribed to the Google Groups
> "Connected Community HackerSpace" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to connected-community-h...@googlegroups.com.
> To post to this group, send email to

> connected-commu...@googlegroups.com.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/connected-community-hackerspace/067ec829-ef8d-4ea3-a170-4fe119b8798a%40googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.



--

This email is intended only for the personal and confidential use of
the human(s) named above. If intercepted by an extraterrestrial
civilization, all opinions expressed in this email are my own and do
not necessarily reflect the opinion of mankind as a whole.

[peter zwag]

Hi Luke
thats a decent reply thank you.

In short ive got my chips (from element14 & smiery)
My 328 's in a duemilanov  have the same issue.

As im a a loss to fix the issue, I ordered a new duemilanov. That gives me the ability to test it once it arrives,
then put my chips in the new duem. * diagnose from there.

my usbasb doesnt have a slow clock jumper. Right now Im using a nano as ISP

I assume this isnt an issue, as isp programing always works

Peter

You received this message because you are subscribed to a topic in the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/connected-community-hackerspace/CuqNTpNNVnQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to connected-community-h...@googlegroups.com.
To post to this group, send an email to connected-commu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/CAEPooQHdVBGfOcDScwdwC3tMcSZGtn7UG8YgoGWg%2BFcWpK1PzA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks
Peter Zwag
pe...@zwag.id.au

[peter zwag]

Well the plot thickens.
My new UNO arrived today. Upload works fine via usb

put in another 328p. serial test works fine.

upload fails. same error.

put in a brand new 328 (From smiery). burnt bootloader.

load blink + serial output via isp

blink works now on com port

upload of blink via usb  fails "avrdude: stk500_getsync(): not in sync: resp=0x00"

It would make me think I have a bad batch of smiery 328p, but element14 328p had the same issue

Im still in the dark.

Comments welcome.

[Anthony Briggs]

Hi Peter,

So your program is working on the chip but you can't upload a new program to it and you can upload onto other chips/boards?

If that's the case, it sounds to me like you're overwriting the bootloader when you're loading the blink program via the ISP (the "load blink + serial output via isp" step). If you burn the bootloader again, and upload via USB instead of the ISP, does that work?

If you put the original 328p that came with your UNO today back into the board, does that still work?

Anthony

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to connected-community-h...@googlegroups.com.
To post to this group, send email to connected-commu...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/CAGrAmVkV%3DgBCHrkbMTAgn301aRbwSc6DJLcm9PRTZQ3CP%3Dpm_w%40mail.gmail.com.

[Andy Gelme]

On 2015-02-10 14:31 , peter zwag wrote:
> Comments welcome.

Use avrdude to look at the fuses for both a working 328P and a
non-working 328P.
Check if there is any differences.

--
-O- cheers = /\ /\/ /) `/ =
--O -- http://www.geekscape.org --
OOO -- an...@geekscape.org -- http://twitter.com/geekscape --

[Anthony Briggs]

If you're burning a bootloader using the Arduino IDE (Peter says he's using 1.06), it should have already set the fuses: http://arduino.cc/en/Hacking/Bootloader

--
You received this message because you are subscribed to the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to connected-community-h...@googlegroups.com.

To post to this group, send an email to connected-commu...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/54D98EF2.7040401%40geekscape.org.

[peter zwag]

Hi Anthony

Chocolate fish to you!

upload vis isp seems to overwrite the boot loader. I had no idea that was the case at all times.

The matter is now RESOLVED. Thanks to all who contributed

--
You received this message because you are subscribed to a topic in the Google Groups "Connected Community HackerSpace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/connected-community-hackerspace/CuqNTpNNVnQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to connected-community-h...@googlegroups.com.

To post to this group, send email to connected-commu...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/connected-community-hackerspace/CAO4-38_u_DsZQkzpTC8XEsYn5VTYxuHqaqjT%3DmqZF%2Bt3sLOpRA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Anthony Briggs]

Pretty sure other people had pointed you in the right direction previously (reflashing the bootloader was in every reply). It just needed another go around / a slightly different take.

The lesson, I guess, is that if you're having trouble, try not to do 'weird' stuff, keep it as simple and vanilla as possible - it's much easier to troubleshoot.

Also, isolate, isolate, isolate! :)

Anthony

On 10 February 2015 at 16:14, peter zwag <pe...@zwag.id.au> wrote:

Hi Anthony

Chocolate fish to you!

upload vis isp seems to overwrite the boot loader. I had no idea that was the case at all times.

The matter is now RESOLVED. Thanks to all who contributed

On Tue, Feb 10, 2015 at 3:10 PM, Anthony Briggs <anthony...@gmail.com> wrote:

Hi Peter,

So your program is working on the chip but you can't upload a new program to it and you can upload onto other chips/boards?

If that's the case, it sounds to me like you're overwriting the bootloader when you're loading the blink program via the ISP (the "load blink + serial output via isp" step). If you burn the bootloader again, and upload via USB instead of the ISP, does that work?

If you put the original 328p that came with your UNO today back into the board, does that still work?

Anthony

On 10 February 2015 at 14:31, peter zwag <pe...@zwag.id.au> wrote:

Well the plot thickens.
My new UNO arrived today. Upload works fine via usb

put in another 328p. serial test works fine.

upload fails. same error.

put in a brand new 328 (From smiery). burnt bootloader.

load blink + serial output via isp

blink works now on com port

upload of blink via usb  fails "avrdude: stk500_getsync(): not in sync: resp=0x00"

It would make me think I have a bad batch of smiery 328p, but element14 328p had the same issue

Im still in the dark.

Comments welcome.

--

--

[peter zwag]

Im now trying to change the speed of the boot loader to be slower.

its running 57600.

Im having coms issues due to long cable leads, and some other issues inc no upload over a rf link (slow).

I tried burning a arduino bt (19200) boot loader, but it only worked at 115200

To clarify, I am not just trying to run coms at <57600, but code uploads
I also know how to use avrdud to upload at different speeds.

any comments, are welcome.