8

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.

Robert Harvey
  • 1,056
  • 1
  • 10
  • 22
Dave
  • 3,800
  • 24
  • 41
  • No direct help here, just questions: What drivers are you using under Windows? Under OSX? Are they the ones made by the OEM of your chip? Have you read / understood the USB protocol used for emulating serial communication? (Most are not aware that USB can contain many different protocols.) OSX is Unix at its core, right? What does "lsusb" return when you type it into a OSX console? Did you call out the application used on the Win / Mac boxes? Are they the same? Are they commercial products from PICAXE? From Microchip.com? – st2000 May 29 '16 at 15:10
  • 3
    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. – DoxyLover May 29 '16 at 15:37
  • Thanks for the comments, everyone. The drivers under Windows and OSX are from the OEM of the CH340G. I don't mess with anything at the USB layer or in the protocol itself. I'm using the PICAXE programming tool (from Revolution Education, creator of the PICAXE) to do everything. It just needs a plain old serial port connection and handles the programming protocol (which is proprietary). @DoxyLover thanks for the tip about sending a break. There's a matching function in the FTDI docs, so maybe this is the key. – Dave May 29 '16 at 16:20
  • The set break function was included in the original UARTs used in PCs since the beginning of time. It seems likely that FTDI has fully emulated the UART in their hardware and provided API support to those features in their drivers. The other vendor may be missing that feature somewhere in their MAC supported ecosystem. – Michael Karas May 29 '16 at 16:33
  • 2
    Just for info, what I found regarding generating the break on Windows: http://stackoverflow.com/questions/4585661/sending-serial-break-using-windows-xp-api – dim May 29 '16 at 21:15
  • Nobody would bother to counterfeit cheap crap like the CH340. – CL. May 29 '16 at 21:21
  • 2
    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): http://aaronkondziela.com/2015/04/sending-a-serial-break-to-a-cisco-on-mac-osx/ – dim May 29 '16 at 21:27
  • @CL the CH340G is definitely cheap, but when you're pinching pennies for a kid's educational project, ever dime counts. $0.40 per CH340G vs. $3.50 for the FTDI (more than) equivalent is a big deal! The funny thing is that Prolific has more or less an equivalent part that costs just over $1, and even they have reported counterfeit chips. – Dave Jun 01 '16 at 02:57
  • @dim Thank you for that information! I will definitely look into this some more. The problem now is that WCH's tech support has basically started to ignore every request I've sent since the initial back and forth... which is very unfortunate if your information is correct and if it's something they could easily fix in their driver. – Dave Jun 01 '16 at 02:58
  • Good luck with their support. Unfortunately, this may be where you see why it is so cheap. – dim Jun 01 '16 at 04:47
  • @Dave maybe you should write your own answer now. I don't feel like I have some legitimity to do it, because the main information was provided by DoxyLover, I just followed with a few google searches. But leaving this unanswered does not make sense either. – dim Jun 01 '16 at 08:58
  • Everyone, thank you for your input. I'm okay either way -- you can post an answer and I can accept it, or I can post what I find. I'm not giving up, yet. I am going to keep bugging WCH once I have more concrete info. My current task is to reproduce the problem with their linux driver, then I will attempt to fix it and provide them with source... we shall see... – Dave Jun 02 '16 at 01:51
  • 1
    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. – Olin Lathrop Jun 03 '16 at 22:05
  • 7
    @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? – Dave Jun 03 '16 at 23:52
  • It sounds like your goal is to use the converter in a way that is not really part of ordinary USB-serial conversion, so it's understandable if the vendor is uninterested. In terms of self-help, you might use software-based USB packet capture (last time I had to deal with this Microsoft was offering their own) to see what the windows driver is actually doing in talking to the chip, and compare it to the source of the Linux driver. – Chris Stratton Jun 04 '16 at 00:00
  • @ChrisStratton thank you for the suggestion, but this is probably way past my ability. From the logic analyzer, it really does look like it's the break that the PICAXE relies on to get the programming sequence going. I think I probably have a better chance of getting the linux driver to work, and then presenting my findings to WCH to see if they can apply the change to their OSX driver. I understand your point about the vendor's stance on this. Once they told me that they know loopback works on the chip, they were not interested in hearing anything else from me. We'll see how this goes. – Dave Jun 04 '16 at 03:59
  • Well, good luck. My point was that if you were trying to debug the break functionality in the Linux driver which it sounds like you believe to be faulty, comparing what it does to the packets put on the wire by the windows driver when actually accomplishing this could be the easiest way. Of course you might also track down the latest version of the Linux driver in upstream git and make sure someone hasn't already identified and fixed your apparent issue. – Chris Stratton Jun 04 '16 at 04:02
  • @ChrisStratton I understand. Given whatever my skillset is at this time, I figure that modifying the linux driver so that it behaves properly and results in a logic trace that matches the working one under Windows is my best bet. I believe that I just got the incompatible CH340 driver from github working in the new linux kernel by replacing the deprecated calls as necessary and recompiling. So now I will try to handle the break behavior... keeping my fingers crossed. However, I totally see what you're saying about the USB packet capture, so that will be something I need to learn. :) – Dave Jun 04 '16 at 05:03
  • Any resolution on this @Dave? – rdtsc Jun 23 '16 at 18:10
  • Not yet. I did buy the OSX CH340 driver from the company that supposedly has the break feature working... and it doesn't work. I'm probably going to have to do the USB sniffing, but I've also decided to make a new PCB based on the MCP2200 to see if its OSX driver works properly. – Dave Jun 28 '16 at 00:05

1 Answers1

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.

John
  • 76
  • 3