Mega2560/CH340G, bootloader woes, avrdude timeout [SOLVED with solution]

Using Arduino Microcontrollers
1

(Topic changed to better described the problem and let others know it got fixed.)

Hi all!
I just ebayed what was called "NEW ATmega2560-16AU CH340G MEGA 2560 R3 Board" and am having some troubles with it. (I suspect it being a clone since it doesn't have the six-pin header near the USB port, only a six-pin ICSP header next to the main Atmel chip.)

When I first got it, I uploaded the 'Blink' sketch just to test it. That worked well. After that, I can't upload sketches anymore!

However, if I connect an USBasp to the ICSP header and choose 'Burn Bootloader' from the Arduino IDE, then that seems to always succeed, and the next time I plug in the Arduino via the USB port, again I can program and upload ONE sketch - it refuses to accept new sketches after that.

I can seemingly repeat this over and over.. re-burning the bootloader and then being able to upload a single sketch through the CH340G chip/USB port. (It doesn't matter if it's the same sketch that just worked, that I try to upload again - it's only the first time I upload that will work, all subsequent tries gives 'timeout' from avrdude.)

Any help on this, please? Is there a particular bootloader binary I should put on this board that will work better than what's in my Arduino IDE? (Arduino 1.6.6/Linux 32-bit, if that helps.)

The baffling part is, how come the first upload works without problems but after that I'm "locked out" even though I'm using all the same settings? :confused:

Board Arduino Mega, Processor Mega 2560, Programmer AVRISP mkII, avrdude says this while programming the first sketch:
Using Port : /dev/ttyUSB0
Using Programmer : wiring
Overriding Baud Rate : 115200
AVR Part : ATmega2560
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
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 :

Something just hit me - can it be so evil that the Mega2560 chip also has the bootloader on it, and when I upload my first sketch, I also overwrite the bootloader?? That would certainly explain why it won't respond to further upload attempts, since the Blink example code doesn't include a fresh bootloader.. :stuck_out_tongue: But if that's the case, how do I keep from erasing the bootloader when uploading new sketches? Or should I resign to just upload via the ICSP port and skip "the easy way" of upload-and-testing through the USB port?

2

Yes it is a clone.

Arduino boards (LCC and SRL) use an ATMega 16U2 for USB/UART converter.
Your board use a CH340G for this function.
At my point of vue you will have less problem with CH340G than with 16U2.

If you are with Windows you have to install good driver. If ,like me, you are on Linux you have nothing to do : all work automaticaly.

3

The problem isn't connecting to the CH340G chip - it shows up as a new /dev/ttyUSB unit when I plug it in, even if I already have programmed a sketch and can't program the Mega again.

The problem seems to be, after some thinking, that in uploading a sketch I overwrite the bootloader on the main Mega chip.

On Arduinos with a separate chip as a bootloader (like the Uno), that's no problem as I don't overwrite the little 16U2 chip that handles 'uploading new sketches to the 328', but if it's the case here that the Mega handles everything on the board, including its own programming, then the CH340G serial chip is, from a programming point of view, useless to me once the Mega's bootloader has been overwritten.

4

But you need a Programmer connected to the ICSP header to overwrite the bootloader. I don't think you can do it from the serial port, with CH340 or 16U2 connected to Rx/Tx.

5

Your USBasp will not work to burn the bootloader into the correct memory location. You need to use another Arduino such as another Mega2560 or an Uno or Nano as an ISP programmer. Then you will be able to burn the bootloader and it will work.

In the future you may be able to upgrade your USBasp to work with >128K flash processors. There has been discussion on the forum about the fact USBasp needs to have some special firmware and/or upgraded version of avrdude installed to replace the IDE's version, in order to work properly with larger processors. Some members of the forum are working on new firmware.

6

Hmrr.. the USBasp I'm using shows up as USB vendor/id
"16c0:05dc Van Ooijen Technische Informatica shared ID for use with libusb"
and the only chip on it is an Atmel ATMEGA8L.

As for overwriting the bootloader on the Mega, I'm confused by the replies now - what do you mean by "will not work to burn the bootloader into the correct memory location"? Does it 'just' upload the new bootloader as a regular sketch? Because when I have the USBasp connected to the ICSP header and choose "Burn Bootloader" via "Programmer: USBasp" in the Arduino IDE, it does some magic with avrdude and uploads code to the Mega2560 - since after having done Burn Bootloader, I can send up a new sketch to the Mega2560 via the USB connector on the Mega board itself.

It's just after having uploaded one sketch that this sketch is all that will run, no new code can be uploaded via the built-in USB port, I have to redo 'Burn Bootloader' via the ICSP header.
It was like that when I received the Mega board, which is why I started poking at the ICSP header itself.. should I then suspect that the bootloader it was delivered with also was programmed in the same faulty manner, and that's why it misbehaved on my first tries? (Before I started poking with the USBasp and all that.)

Hm, well. In either case, and please comment on this with which USBasp-product I should use to make the Mega bootloader survive sketch-uploading, I've got a new USBasp in the mail already. Hopefully it's a newer one. (I just wanted a 6-pin ribbon cable, and the new USBasp comes as part of that package.)

(Or I could just take your advice and use an Uno I have lying around here to try bootloader-burning with.)

7

I recommend using the Uno. Use the USBasp for smaller AVR processors.

8

I have now tried Nick Gammon's Uno-programmer, from

with code and pinouts. I've put the programmer sketch on the Uno, connected the two, and when I started the Uno up it said in its serial output that it found a Mega2560, asked me to type 'G' to program, which I did, and the Uno then programmed a bootloader onto the Mega board. (And reported successful.)

From there, I could then connect the Mega board directly via USB and upload one sketch, but again, when I tried to send the second sketch up I just keep getting

avrdude: stk500v2_ReceiveMessage(): timeout

and the Mega board keeps running the Blink sketch from the first upload. So.. the Uno approach gave me the same result as the USBasp attempt. Thoughts?

9

My thoughts are there must be something wrong with the auto reset circuitry on the board. Perhaps I am mistaken about the USBasp. (Always a first time. :slight_smile:

DTR from the CH340G is supposed to go through a .1uF capacitor to the reset pin of the processor to reset it at beginning of upload. You could try pressing reset when you click upload and release it when the IDE changes from compiling to uploading.

10

Well I'll be damned. Holding down reset and letting go 'just at the right time', though it takes a little trial and error, did in fact work. :o

Now it's as easy as clicking reset until it starts to program - and then not click reset again or the avrdude verify hangs and I have to wait for that to timeout (or kill the process).

But you're my hero. :slight_smile: So, the short of it may be that I should be looking for a capacitor to replace near the CH340G chip?

11

Well I'm not the hero for many since I said disparaging things about the USBasp! I'll have to pay for that!

That auto reset circuitry, hmmm... There could be several things causing problems with that. You don't have a RESET-EN jumper pad that you cut the trace on at some point in the past, do you? I would make a logic probe out of an LED and 500 ohm to 1K resistor. Connect the resistor to GND, the other end of resistor to cathode of LED, then poke with the anode of the LED. Practice on the Uno. When you connect to the USB-to-serial chip DTR line, the LED should normally be glowing. When you open serial monitor or while you are uploading a program, the LED should go out. Then move the probe to the other side of the capacitor which is connected to the reset line of the processor. You should see the LED normally glowing almost all the time. When you open the serial monitor or initiate an upload, the LED should wink at you. On mine it winks out twice in quick succession. This is showing you the reset happening at the beginning of the upload process, so the bootloader will start. Switch to the Mega and poke around and find the problem.

12

dmjlambert:
My thoughts are there must be something wrong with the auto reset circuitry on the board.

Correct!

With no sketch loaded (because "burn bootloader" erases everything), the memory is blank and the bootloader cycles continuously looking for an upload, so does not need to be reset. Once a sketch is loaded, the bootloader completes and starts up the sketch, and has to be reset to prepare it for an upload.

Check that some crazy designer has not placed a capacitor from RESET to ground.

13

A Blink sketch is loaded, and the DTR-to-GND LED is off. It blinks briefly when I manage to hit reset to upload a sketch. Since avrdude both writes and verifies, I'll just assume that it blinks more than once, but because the tiny sketch takes such a short time to upload, I only notice it as one LED blink.

During normal run, the LED is off.

Now switching to have the LED go RESET-to-GND.. what the holy hell. Yeah, the LED goes out when I press RESET, ... of course. But just having the resistor and LED connected (I'm using the ICSP pins for GND and /RST), uploads work flawlessly every time!

Suspicion: Paul__B is on the right track here, in that RESET doesn't get pulled sufficiently low by the CH340G. By adding the resistor and LED, acting as a pull-down, now the chip manages to drive (or sink) the RESET line low enough to let avrdude come in and flash. (Or conversely, if I got my signals mixed up, the LED sucking off a little voltage raises RST enough from ground.. anyway.)

So while I'm not impressed with the board design now, now at least I have a usable workaround. Making the resistor-and-LED a permanent part of the ICSP GND-RST pins.

14

dmjlambert:
Well I'm not the hero for many since I said disparaging things about the USBasp! I'll have to pay for that!

CURR!!! the time to pay is at hand! EN GUARDE!

lol. seriously, you are correct that some usbasp have the m2560 bug. so does the "official" fischl firmware which also suffers from the "raw chip" problem. to their credit chinese uspasp work ok with new chips. but what should be mentioned is images to correct both issues have been available for a long time: USBasp Update Warning - Microcontrollers - Arduino Forum. no need to wait.

regarding the op problem the only time i saw something similar was caused by bad power supply. if in this case it really is due to faulty reset circuit it should be possible to simply remove suspect components and add known good ones. .1uf from ch340 to m2560 with 10k pullup on the m2560 side. does require some delicate soldering. generally adding pull down is a bandaid fix but whatever works.

15

I'll have to settle for a fix I can implement.. seeing how comparatively small these components are (even at 2 by 4mm) I don't have the fine motor skills to patch that properly. :confused:
But for others who have better equipment and hands, all the better! ... Or get an official Mega board and not a Chinese clone even if it says it's 'fully compatible'. :wink:

16

personally ive had good luck with chinese clones. literally hundreds of arduino clones purchased for work and school w/o problems. of course somebody has to be the one to get stuck when the music stops.

i am sure the official ones undergo better qc/qa. the question is it worth the 3x-5x markup. for me it is not. my main reason for buying at least one original is mostly token of support for the inventors.

17

Snout, so you are saying the uploading works ok and you suspect it is because you have that probe LED and resistor hooked up to reset and that is providing a little bit of pull down?

Snout:
A Blink sketch is loaded, and the DTR-to-GND LED is off. It blinks briefly when I manage to hit reset to upload a sketch.

The part I don't quite get is why the LED connected to DTR would be off and then turn on briefly during upload. I was expecting the opposite, that it would normally be on and only go off when upload was happening.

18

Correct. When the probe-resistor-LED is connected between GND and RST on the ICSP header pins, uploading new sketches work without a hitch, every time. So the debug probe (#define DEBUG!) actually solved my problem. And the explanation that comes closest to mind, to me, is that this connection provides the little extra pull-down required for a reset to occur.

(In the first measuring, I connected the 'probe' anode to pin 13 of the CH340G, which I believe is DTR, according to a google images search for 'CH340G pinout'.)

Though the pinout picture named that leg 'DTR#'. Maybe the # means 'inverted'? I haven't read the datasheet, but if it is, then an upside-down response would be correct.

19

I agree perhaps RESET doesn't get pulled sufficiently low by the CH340G, and the slight pull down helps. There could be the reset pullup resistor is something stronger than 10K that is in the typical reset circuit. Or manufacturers have been known to make mistakes and perhaps the pullup resistor spot was populated with a capacitor or something else. And the capacitor between DTR and reset could be failing or the wrong value (should be 0.1uF). In some designs, parallel to the pullup resistor there is a diode, and that prevents the voltage on the reset pin from spiking above 5V during serial disconnection.

Yes, DTR#, I think it is pin 13 of CH340G, and I think # means active low. So when serial is connected, such as during programming or when the serial monitor is open, the DTR signal should be low. When disconnected it should be high.

The capacitor turns the DTR signal, which goes low and stays low during the serial connection, into a momentary pulse low, to reset the processor and start the bootloader.

If you don't want to get into removing and replacing components, I understand. I think it is a fine patch to just add a pull down resistor on the reset pin. Some may find it a hokey thing to do. You probably don't need the LED, just a 10K to 15K resistor if the pull up resistor is 10K.

20

You need to check the markings on the 0.1 µF capacitor (104) and pull-up resistor (103). Sounds like one or the other is wrong. If the capacitor is too small (such as 0.01 µF - "103"), just parallel the correct value.