TUMPA MAC driver

This site is best viewed in a modern browser with JavaScript enabled.

mitchell486

I have attempted to use the MAC FTDI (v2.3) driver on the TUMPAv2. I am currently on OS X 10.11.2 (15C50), which is El Capitan. MacBook Pro, not hackintosh. I have followed the TAIO wiki on installing and starting the .kext. I originally followed the TIAO wiki guide, then couldn't get the .kext started because it was then "unsigned". I found out from the support team at FTDI that it is "unsigned" as soon as I added the PID for TUMPA.
So I removed the driver and reinstalled, I then tried starting the original driver (non-modified) from FTDI and it started without issue. The TUMPA was not recognized and there were no /dev/* changes. In fact, I found only one message regarding FTDI where it was being mounted to disk2s1. This was a non-readable or traversable directory. I couldn't use minicom to use that /dev/disk2s1 either.
I then tried to follow the guide again and added the PID manually. Once the .kext was unsigned, I had to manually turn off Mac System Integrity Protection. Once that was completed, I was able to load the unsigned .kext. I loaded it and I was still unable to locate any /dev/* changes. I also saw no messages in dmesg, /var/log/*, or anywhere on the system that would be expected. The light is on for the TUMPA and I've used it previously on my linux machine, so I know it's functional.
I have emailed both FTDI and asked for the PID to be added, on behalf of TIAO. I also have a ticket open with TIAO help, which I believe is through diygadget.com.
Does anyone have any troubleshooting steps that might assist with getting this to work on my MAC? Thank you in advance for any help.

mitchell486

UPDATE: I have tried with AppleUSBFTDI, VCP FTDI Driver, and the D2XX Driver from FTDI. None have worked in recognizing the TUMPA. I have modified and tested the VCP FTDI, no change. I have verified the MAC fully sees the device via "ioreg" and it does, I just can't use it. I have verified the board works fine with a Linux laptop. Does anyone have any direction I could start in testing to see if I can get this working?
I emailed csbooth.com support (diygadget support for TIAO), and their reply was:

Hi, I am sorry for the issue you are having.
We don't have any drivers for Mac.
However one thing you could do is to revert the PID back to FTDI default. You can use FT-Prog on windows to flash the VID/PID to 0403/6010, so it will be recolonized as FT2232H.
Please let me know how it goes.
thanks

Does anyone know if this is a viable solution for the TUMPA and can I harm it by doing this? Any assistance would be greatly appreciated. Does anyone knows of a good IRC channel to possibly reach out to? Thanks.

[deleted]

Please feel free to contact TIAO corp. for all kind of questions, suggestions or complaints.:
http://www.csbooth.com/
You can also join OpenOCD community where you can find engineer/expert opinions. They also have an IRC channel:
http://openocd.org/discussion/
Thanks!

mitchell486

Hi Volkan-k,
I have reached out in the IRC channel for Open OCD a few times over the last week, but with no responses. I'm not sure anyone is active in there at the moment. Probably reasonable considering the end of year and holidays coming soon. Either way, I was going to post on their forums shortly to see if anyone has had any experience with El Capitan and the TUMPA.
My other train of thought was to try to learn how kernel extensions and drivers work in Mac and OS X, to see if I could possibly modify the FTDI driver to get this TUMPA to work. My next task will be to read on how those work and then dig into the actual .kext from FTDI to see if I can modify it properly. I will try to report back once I've learned more.
PS - If anyone is curious, it is getting recognized by the OS for all intents and purposes, but it's not initiating the driver when recognized. I can provide screenshots and output from ioreg with the device being fully recognized. Please let me me know if anyone is interested in seeing these outputs.
Mitch

mitchell486

Hello everybody!
I have since gotten this working. A major part in due to PaulFertser on the OpenOCD IRC channel! He really is a very helpful resource. He helped me get OpenOCD installed and walked me through getting it working for JTAG. Then I could confirm that that the JTAG portion was at least connected and working using libusb. The last remaining part was not necessarily Paul's wheelhouse, but he did suggest a blog post that helped point me in the right direction.
To get this working, I had to combine both steps from the tiaowiki.com install TUMPA on a Mac, and this blog post. http://www.mommosoft.com/blog/2014/10/24/ftdi-chip-and-os-x-10-10/. The combination was editing the Info.plist in the steps from the wiki, but in the blog post, he lists the "bcdDevice" id as being a critical list. When looking in the Info.plist, I did notice that it was on all <key> entries... I figured that must have been my missing item, because the TIAO wiki does not list the "bdcDevice" in it's entries.
So to make sure everyone follows along, I installed OpenOCD. Tested it with JTAG via the following command:

openocd interface/ftdi/tumpa.cfg -c "adapter_khz 10" -c "transport select jtag"

I was then able to see this have a blank output with no errors and I believe it was waiting for input from a JTAG device. Then after talking a bit more, Paul noted that if I were going to be troubleshooting any Wifi Routers or anything, I would need the serial/RS232/TTL debugging portion to be working. Then he pointed me to that article, which I had seen before, but never noted the missing "bcdDevice" id field. I then followed the wiki steps and did:

sudo nano /Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist

I then did a CTRL+W and searched for 1792, which is the bcdDevice ID for FT2232H chips. (I believe that is just the bcdDevice ID for all FT2232H chips, not 100% positive on that though.)
I then entered the two new following keys.

    <key>FT2232H-TIAO-0</key>
    <dict>
        <key>CFBundleIdentifier</key>
        <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
        <key>IOClass</key>
        <string>FTDIUSBSerialDriver</string>
        <key>IOProviderClass</key>
        <string>IOUSBInterface</string>
        <key>bConfigurationValue</key>
        <integer>1</integer>
        <key>bInterfaceNumber</key>
        <integer>0</integer>
        <key>bcdDevice</key>
        <integer>1792</integer>
        <key>idProduct</key>
        <integer>35480</integer>
        <key>idVendor</key>
        <integer>1027</integer>
    </dict>
    <key>FT2232H-TIAO-1</key>
    <dict>
        <key>CFBundleIdentifier</key>
        <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
        <key>IOClass</key>
        <string>FTDIUSBSerialDriver</string>
        <key>IOProviderClass</key>
        <string>IOUSBInterface</string>
        <key>bConfigurationValue</key>
        <integer>1</integer>
        <key>bInterfaceNumber</key>
        <integer>1</integer>
        <key>bcdDevice</key>
        <integer>1792</integer>
        <key>idProduct</key>
        <integer>35480</integer>
        <key>idVendor</key>
        <integer>1027</integer>
    </dict>

I then did a full reboot, plugged in the TUMPA, I then loaded the kext via:

sudo kextload /Library/Extensions/FTDIUSBSerialDriver.kext

PLEASE NOTE: My board was already in TTL/Serial loopback mode from testing on a linux box, if you need to put yours in loopback mode. Please see the article I have posted at http://www.tiaowiki.com/forums/index.php/topic,4254.0.html.
I was then able to do

ls -l /dev/cu*

and see multiple cu.usbserial-TIM0394 devices. In this output, I had both an A and a B device. Then with my TUMPA in RS232/TTL/Serial Loopback mode, I did multiple tests to verify that it was working. I tried both "/dev/cu.usbserial-TIM0394A" and "/dev/cu.usbserial-TIM0394B". Neither worked. I then tried "/dev/tty.usbserial-TIM0394A". It did not work, no matter what settings I used in minicom. I then tested it with "/dev/tty.usbserial-TIM0394B", 9600 8N1, and Software/Hardware Flow Control = Off. I was able to successfully verify that the TUMPA was working on El Capitan OS X 10.11.2 (15C50).
The last thing I did was make sure to save my minicom config via "CTRL+A, O, "Serial port setup", A = /dev/tty.usbserial-TIM0394B, save setup as 'tumpa', exit". Once I had saved this file, I just run

sudo minicom tumpa

and it opens with the proper device. I even went a bit further and edited my .bash_profile to contain

alias tumpa='sudo minicom tumpa'

so that all I have to do is type 'tumpa' in my terminal to start minicom with that config file.
I'm not sure if everyone will have the same results, but again, ONLY /dev/tty.usberial-TIM0394B worked for me on the TUMPA in Serial/RS232/TTL loopback mode.
EDIT: I realized the reason for only seeing the B channel, after reading the documentation, it clearly states that the A channel are used with JTAG and topside SPI. Then channel B is used for all TTL/RS232 and bottomside SPI.
Please Note Again: I did have to follow proper procedure to disable SIP on El Capitan due to the FTDI driver becoming unsigned once I modified it with my entries... I am not going to link to an article on this process, there are many articles that cover this on Google.
Along with posting this on this forum, I will be outlining this process in my blog as well. http://pipedoutput.blogspot.com. If you have any questions or any feedback, please feel free to message me on this forum or on my site. Thank you! I hope this has been helpful!

[deleted]

mitchell486 wrote: Then with my TUMPA in RS232/TTL/Serial Loopback mode, I did multiple tests to verify that it was working. I tried both "/dev/cu.usbserial-TIM0394A" and "/dev/cu.usbserial-TIM0394B". Neither worked. I then tried "/dev/tty.usbserial-TIM0394A". It did not work, no matter what settings I used in minicom. I then tested it with "/dev/tty.usbserial-TIM0394B", 9600 8N1, and Software/Hardware Flow Control = Off. I was able to successfully verify that the TUMPA was working on El Capitan OS X 10.11.2 (15C50).

You had to disable flow control because for proper loopback test, you need to short;

Receive (RX) Data pin with Transmit (TX) Data pin
Request To Send (RTS) pin with Clear To Send (CTS) pin
Data Set Ready (DSR) and Data Terminal Ready (DTR) pins with Received Line Signal Detector (Data Carrier Detect)

using jumper wires etc.

http://www.ni.com/tutorial/3450/en/ wrote:A more advanced loopback test that allows hardware flow control will need more pins connected to allow the flow control signals to be properly passed. For RS-232, the CTS and RTS pins must be connected along with the DTR and DSR pins.

see also: http://airborn.com.au/serial/rs232.html
you can also purchase Loopback test plugs there.

mitchell486

Yes, volkan-k is correct. I misspoke in my last post.
I only had my TUMPA in TTL loopback. If you would like to test RS232 Loopback, please follow his directions! Thanks, volkan-k!