I made a custom PICAXE-based PCB that integrates all of the components needed to program the microcontroller. I assumed everything was fine because I could use it to program under Windows just fine. However, under Mac OSX I was unable to program it. Oh, and I am using the WCH CH340G USB-RS232 chip to reduce costs, as the FTDI FT232RQ is over 7x the price, and I don't need all of its features.

I was thoroughly convinced that there was something electrically wrong with my design that caused the CH340G to misbehave under OSX... I had modified my board so I could perform a loopback test under Coolterm, and transmission would freeze up every several characters. Clearly, something was messed up, and I thought that this was a bug in the CH340G OSX driver. WCH technical support assured me that it wasn't, and that it could be a counterfeit chip. During this witch hunt, I picked up an off-the-shelf USB-RS232 converter based on the same chip, and it worked flawlessly. So much for a "driver bug" causing my headache!

I then built up another unit with the minimum amount of components required to perform the loopback test (i.e. no PICAXE), and I was able to get it to the point where the loopback test was reliable and no longer froze. Therefore, I likely do have something going on with the circuit that caused the freeze, but for now, I could continue on by wiring my PCB to a breadboard and using the DIP variety for external components to complete the programming circuit.

Now on to the meat of my question...

I used two test setups - 1) my PCB wired to a breadboard with the PICAXE, and 2) a breadboard with the PICAXE and the OTS USB-RS232 converter. I connected each to my Windows laptop and wired up the signals that I thought were most relevant to my Saleae Logic 8 Pro. I captured the signals when programming under Windows, and then moved the USB cable over to my iMac and captured the signals again. Here's what I ended up seeing:

PICAXE programming working under Windows

enter image description here

So the obvious difference here is that the "Serial In" signal is not going logic high when the programming process starts. This is mandatory because that's how the PICAXE programming protocol works (or at least, that's what it looks like). You have to assert the TX line over RS232, which puts the PICAXE into a mode where it transmits a square wave, followed by bits that identify the chip type.

It seems pretty clear from the logic analyzer capture that the CH340G driver under OSX isn't allowed to assert its TX pin, but the Windows version can. In trying to gather as much information as possible so I can plead with WCH to help me out with this problem, I am trying to understand how it is even possible to assert TX at all. In the Windows world, I believe everything ends up as a WIN32API call. I looked at the FTDI driver documentation just as a frame of reference, and I can see that it has functions for setting the state of the DTR and RTS, for example, but not a way to set the state of TX. On the Windows API side, you write data out of TX by calling WriteFile. There isn't a way that I know of that allows you to just say "hold TX low" or "hold TX high".

Can anyone explain how this might be achieved on either Windows or OSX, so that I can continue with my investigation and debugging? There must be a way to do it that I'm missing, or proof that there really is something missing in WCH's driver. After all, I do have the PICAXE AXE027 programming cable as well, and it is able to program the chips when running under OSX. If you know which functions are used under Windows and/or OSX to achieve logic-level control over the TX line, that would also be extremely helpful!

I didn't know about the break feature. It seems like this could be what the WCH driver is missing under OSX.

In my ongoing quest to figure out how to make this chip work, I loaded Ubuntu 16.04 LTS, which has the WCH driver built-in (at least, I think it's from WCH). I ran the programming tool under Ubuntu and it also doesn't work. The WCH source does not compile under 16.04 due to the difference in kernel version. I tried to load the version I built on 12.04, but it won't load. I can't test under 12.04 because Chrome isn't supported under that OS anymore.

  • 3
    \$\begingroup\$ The way you would normally set a long "assert" on the transmit from a UART is to "send a break" which, on a PC, would be done using a system call (I don't know what on Windows). I don't know of any way to do this with a normal serial port write, however. \$\endgroup\$
    – DoxyLover
    Commented May 29, 2016 at 15:37
  • 2
    \$\begingroup\$ Just for info, what I found regarding generating the break on Windows: stackoverflow.com/questions/4585661/… \$\endgroup\$
    – dim
    Commented May 29, 2016 at 21:15
  • 2
    \$\begingroup\$ Under Mac OS X, the call is tcsendbreak. But it seems its availability indeed depends on the driver, and some cheap USB-to-serial adapters don't implement it. Another example of someone who fought with this as well (but with a pl2303 chip): aaronkondziela.com/2015/04/… \$\endgroup\$
    – dim
    Commented May 29, 2016 at 21:27
  • 1
    \$\begingroup\$ The title made this sound like it could be a good question, but this is way too long. I did read the first paragraph, but that was all time-wasting introductory fluff, so stopped there. Surely you can distill your question down to three paragraphs. Until then, moving on. \$\endgroup\$ Commented Jun 3, 2016 at 22:05
  • 7
    \$\begingroup\$ @OlinLathrop I realize that you're hot stuff in this area, but man you are sure outwardly rude in your comments. Do you work with actual people, or sit behind a screen all day? \$\endgroup\$
    – Dave
    Commented Jun 3, 2016 at 23:52

1 Answer 1


You send a break to assert the TX pin, but some poorly implemented drivers/chipsets can't do this for long periods of time (longer than a character or two).

In the win32api you use SetCommBreak() and ClearCommBreak() to assert and release the TX pin.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.