1

I'd like to mention that the device I'm talking about in this question works fine using avrdude on a linux machine, the issue appears to be with the OSX driver for the CH340g

I've installed the latest CH34xx driver from www.wch.cn

The device appears to be recognised as /dev/tty.wchusbserial1420

I can connect to the device using avrdude and enter terminal mode, or try to upload, however working with the device seems very erratic.

When i enter terminal mode (using avrdude -t) the tx and rx lights flash indicating the device is connected and working, I get feedback from the UI

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

and if I type 'dump flash' or some command during the connection stage (while tx and rx are flashing) and hit enter as soon as the prompt appears, the command will execute, giving output like this:

avrdude> dump flash

0000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

however very shortly after the prompt appears, the 'L' light comes back on. From this point no command gives any output except

avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

This gives me the impression that something happens after avrdude connects, which is resetting the connection, and taking the device out of the avrdude: AVR device initialized and ready to accept instructions state.

I can't upload to the device for a similar looking reason, the output from attempting to upload is:

avrdude: Version 6.0.1, compiled on Apr 14 2015 at 16:30:25
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/Applications/Arduino.app/Contents/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/Ollie/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/tty.wchusbserial1420
         Using Programmer              : arduino
         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                       : 2000
         StabDelay                     : 10
         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     1     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256    10    25 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 : Arduino
         Description     : Arduino
         Hardware Version: 3
         Firmware Version: 4.4
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: safemode: Fuses OK (H:00, E:00, L:00)

avrdude done.  Thank you.

As you can see - the issue is not that the driver isn't installed or that avrdude can't see the device, but simply that the connection seems to die as soon as it is established.

I've been unable to find any reference to a similar error using google, and i've tried all the obvious stuff (re-installing drivers, different version of the driver etc)

Ollie Hirst
  • 592
  • 2
  • 6
  • 14
  • It could be caused be a damaged Arduino. I've had a similar issue once where I could program the Arduino if I linked it to another one, but not through its own serial interface. But I don't remember the details. Given the specificity of your question, you might get better answers on http://arduino.stackexchange.com/. It might even be off-topic for Stack Overflow. – GolezTrol Apr 09 '16 at 05:52
  • Thanks for the reply! - I initially thought the same, but I think the device must be working as on a few different linux machines, it works fine, i can connect to it using avrdude or the Arduino IDE and upload sketches or use terminal mode without the 'L' light coming back on – Ollie Hirst Apr 09 '16 at 05:56
  • does it use an FTDI chip for USB/Serial communication? If so is it a legit FTDI chip? –  Apr 12 '16 at 02:41
  • I'm having a similar problem with my custom PCB. The CH340G driver loads fine, I can see the serial port, but it conks out on me after sending several bytes of data, at any baud rate. I wonder if it needs to have other pins connected on my PCB. Under windows, I can use it just fine without any of the flow control pins routed. Have you tried it under Windows yet? – Dave Apr 16 '16 at 03:18
  • That is exactly what is happening, I used ubuntu (14.04) and it detected it and worked fine using Arduino ide. It seems to be an issue with the ch340g driver – Ollie Hirst Apr 18 '16 at 03:23
  • 1. Is the output of `dump flash` valid? I would expect `jmps` instead of `nops` at the beginning of flash. 2. What's wrong with the second output? **I can't see any message about writing to flash, performing erase cycle (it can be disabled) neither do I see any error message.** Sorry for resurrecting old question, but it's strange that no-one noticed this 'oddities'. – Aleksander Z. Aug 20 '16 at 15:32

1 Answers1

3

You may have a hardware issue. On OSX it may not be resetting in a proper way, so bootloader not started and you receive "programmer is not responding" error. To fix you need improve your hardware by changing reset circuit. With CH340 reset is driven by RTS and DTR pins.

This also mean that you may try to look at your serial port settings and enable flow control.

  • Do you know if it's a problem for the RTS and DTR pins to be floating? All of the schematics I have seen so far online don't use them. But I wonder if that's what's causing my problem where the driver stops receiving / transmitting data after several characters. – Dave Apr 16 '16 at 03:18
  • What pins of ch340 are used for driving reset? And what MCU? – Vladimir Tsykunov Apr 16 '16 at 04:58
  • I'm using a PICAXE processor. The only pins I have connected to the CH340G are TX and RX. Everything else is either floating, or connected to components only needed by the CH340G, like the crystal and caps. There isn't a reset. They have a special protocol where they handshake on the TX/RX lines to get the chip programmed. – Dave Apr 16 '16 at 07:13
  • I have no experience with your processor. This topic marked as Arduino so i suppose you have a bootloader already burnt. This is how it works on standard boards, suc as Mega, Uno etc. You need attach RTS and CTS through capacitor of 0.1uF to reset pin of the MCU. Look at this page as a starting point http://jarick.com.ua/%D0%B2%D1%81%D0%B5-%D0%BE%D1%81%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5/25-%D1%81%D1%85%D0%B5%D0%BC%D0%B0-%D0%BA%D0%BB%D0%BE%D0%BD%D0%B0-arduino-uno-r3-%D0%BD%D0%B0-atmega328-%D0%B8-ch340g.html – Vladimir Tsykunov Apr 16 '16 at 09:54
  • Thanks, yeah, I know I'm really in the wrong place, but due to the absence of any information related to my problem online, I am really grasping at straws here. Thanks for the link! – Dave Apr 17 '16 at 03:21
  • By the way, the bounty auto applied to this answer, however this does not answer the question. I stated right at the beginning of my original question: I'd like to mention that the device I'm talking about in this question works fine using avrdude on a linux machine, the issue appears to be with the OSX driver for the CH340g – Ollie Hirst Apr 30 '16 at 13:40
  • Anyway driver controls hardware behaviour. And in the case when bootloader started from reset, its duration is important characteristics. From my experience i know that good reset has length of 10-100 ms, sometimes reset time may have value of 10-30us, and this is not enough. It maybe caused by low-level driver, absence of hardware control or mistakes in hardware reset circuits. You may try to measure reset duration with oscilloscope – Vladimir Tsykunov Apr 30 '16 at 13:56
  • This is most helpful - I shall investigate the reset duration with my DSO138 – Ollie Hirst Apr 30 '16 at 14:00
  • Yes, try it. I was developing custom arduino-compatible board with ft232 driver. And spend two days fighting with programming. After i discovered that reset was lasting for only 10us, i simply changed capacitors and board begin working properly. This is for windows. – Vladimir Tsykunov Apr 30 '16 at 14:03