AXEpad works with Keyspan adapter in Parallels but not OS X

I have a Keyspan USA-19HS USB-serial adapter that I am using with a Snap Micro I circuit kit from Elenco Electronics. The kit contains a Picaxe 8M microcontroller and a simple cable that has a 9-pin serial connector on one end (which I plug into the Keyspan unit) and three snap wires on the other end (ground, signal in, signal out). I don't think the cable has any active electronics in it.

I am running a Macbook Pro with an Intel Core 2 Duo processor and OS X 10.6.4. I also have Parallels, and have loaded both the Windows XP and Mac drivers for the Keyspan adapter.

The short of it is that everything works fine in Windows XP under Parallels--i.e., I can successfully program the microcontroller--but it doesn't fully work under OS X. In particular, the test button in MacAXEpad will cause 5 volts and zero volts to appear on the signal in lead (Tx from the Keypad, I assume), and the MacAXEpad software will go through all of the correct steps through the downloading of the code, but throws a verification error. Here's the transcript:

PICAXE-08M Enhanced Compiler. Version 1.2
Copyright (c) 1996-2010 Revolution Education Ltd
All rights reserved.
www.picaxe.co.uk

Compiled successfully.
Memory used = 18 out of 256 bytes.

Searching for hardware on /dev/tty.KeySerial1.
Downloading program.

[at this point the error box comes up with:
Download for PICAXE-08M on Failed
Error:
Verification error - 0x00 transmitted but nothing received at byte 0]



If I leave the setup unchanged and start up Parallels, the Windows version of AXEpad works fine and the code is fully loaded on the microcontroller. I have done this repeatedly and it always works. I have rebooted the Mac several times but that doesn't change the result.

I also have put a Mac terminal window into terminal mode with the command "screen /dev/tty.KeySerial1 9600" and put a logic probe on the Tx wire. Each time I type a character, the probe shows a positive signal pulse. But if I short the Tx and Rx leads together, there is no signal coming back to the terminal windo.

So it would seem that there is no response coming in on the Rx line in OS X but there is in Windows.

Any ideas as to why the Mac version won't work?

It does sound like an issue with OSX, the Keyspan drivers under OSX or configuration. If it works fine under Parallels then there's no obvious reason that it shouldn't work under OSX. The loopback test using "screen /dev/tty.KeySerial1 9600" does indeed suggest the setup is working, stuff is going out, but not being received back.

What is odd is that it seems the compiler finds the 08M ( "Downloading program" ) and must have received an 08M download confirmation via RX but then it fails later on.

What is the result of going into the Options menu, selecting Mode tab, and clicking on the Firmware button with both the 08M connected and powered and not ?

If you are using batteries for your 08M hardware try with fresh batteries as they may start off appearing to have enough "oomph" but that can drop as downloading proceeds.

MacAxePad not as capable with serial as Windows versions

I also have tried MacAxePad side by side with Programming Editor, with both Keyspan and FTDI USB<>Serial adapters.
Programming never fails in the latter, always in the former, with some sort of verification error thrown.
Loopback tests work. Firmware check works, with multiple PICAXE flavors. Terminal works. Only programming doesn't work, and it flunks on either the first or the second byte (zeroth and first). Usually "0x00 transmitted but 0xFFFFFFFF received at byte 0." The length of the supposedly received byte seems telling to me, that there is a bug in MacAxePad.

Welcome to the PICAXE forum.

It does seem there is some issue with a Keyspan connection though what that is is hard to say. AXEpad and compilers will all be executing slightly different code and calling different system libraries and device drivers when run under Parallels or natively. AXEpad and compilers are built from a common code base but have to rely on different code and libraries depending on the environment in which they execute.

On the reported error and apparent size of the reported byte that's not a bug within MacAXEpad. AXEpad actually passes downloads over to the compilers, that's neither here nor there, but also isn't indicative of a bug in the compiler. What's being seen is the value as returned by the underlying software libraries when a failure is detected and is most likely an artefact of how that value is reported; the msb of the byte looks to be sign extended across 32-bits. Neither AXEpad nor the compilers have direct access to what lower level functions received, only what they report back and for diagnostics it's usually best to report what was returned rather than modify that which may lose useful information in diagnosing a problem. It may be that, though sending and receiving bytes, these bytes are passed to underlying code as 32-bit numbers; the report showing how what was received differs from what was sent.

The Programming Editor, AXEpad and the compilers don't directly control any serial ports or download cables; like most programs they simply pass what they want to send to the libraries which in turn pass that to the OS which in turn passes to the device driver which sends it out, with received data being passed the other way through the same chain and layers until that arrives back. Programming Editor, AXEpad and compilers do the same no matter what they are communicating with and what works for one download cable should therefore work with any other. Something between the compilers and the device is presenting a problem when it comes to the Keyspan device but it is not clear what that is and is and not within our sphere of control. Given that AXE027 works it would seem that the libraries and OS are working as expected and the problem lies with the Keyspan drivers though it could be any combination of factors.