Can't create serial port (MacOS) [SOLVED]


#41

So I modified tinyprog/init.py get_ports() to just dump everything usb.core.find() can give out, and it did not list 1d50:6130 at all.

I plugged in a FTDI board I had and it’s product ID did show up after I disconnected the tiny bx. Also, the FTDI board shows up as device class 0x0 (Unspecified).

Does osx need a kext/driver for this board in order to do anything with it as a “Communications Device”? I have never programmed anything for USB before so I certainly don’t know.


#42

You’re close, but that’s not quite the issue. Modify the following lines from tinyprog/__init__.py:

    # MacOS is not playing nicely with the serial drivers for the bootloader
    if platform.system() != "Darwin":
        # get serial ports first
        ports += [SerialPort(p[0]) for p in comports() if device_id in p[2].lower()]

Change it to:

    # MacOS is not playing nicely with the serial drivers for the bootloader
    if True:
        # get serial ports first
        ports += [SerialPort(p[0]) for p in comports() if device_id in p[2].lower()]

There’s a specific version of MacOS that changed this behavior. Earlier versions attach the correct driver, later versions refuse to attach the driver. I need to track down the exact version and automatically do this.


#43

So what versions MacOS do work with tinyprog? El Capitan (10.11.6) doesn’t seem to work with tinyprog 1.0.17 either. I was able to use Vmware+Windows7+tinyprog and that does work, but is very slow on my 10+ year old iMac.


#44

If it doesn’t work without any command line options then use the —pyserial option. I’m still trying to figure out exactly which versions of MacOS require pyserial and which ones require libusb.


#45

So I tried getting some debug info out of libusb with:

export LIBUSB_DEBUG=4
tinyprog -l

And there was much debug output. The interesting line was:

[73049344.000000] [00000a0b] libusb: warning [darwin_cache_device_descriptor] could not retrieve device descriptor 1d50:6130: transaction timed out (e0004051). skipping device

After some googling, e0004051 looks like it’s a “Bulk Read Error”.

Is there any other suggestions on getting tinyprog to see the BX board under OSX El Capitan?


#46

Did you try running with “tinyprog -l —pyserial”?


#47

That --pyserial doesn’t work either.

The only thing that worked was using Windows 7 instead. The board shows up right away and it can be programmed, so I do have a work around.


#48

Hi @lukevalenty. Using libusb is a great idea, but I prefer to solve serial interface issues in MacOS because there are other boards also using serial interfaces.

I found this installer for MacOS: https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver. @eglinz could you try installing this driver and executing “tinyprog -l --pyserial”? The Arduino community uses this installer to setup serial drivers on https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver/blob/master/CH34x_Install_V1.3.pkg. If this works for you I’ll include it in the apio drivers command. Thanks.

Update: also found https://github.com/mgp25/USB-Serial-Drivers-macOS


Atom. Error: board TinyFPGA-BX not available
#49

I just installed the serial driver via brew and the BX board is now showing up under OSX El Capitan when using “tinyprog -l --pyserial”. I haven’t tried to load anything on the board yet.


#50

Great news! Let me know how it goes once you try to load something.


#51

Hi Folks,
I’m also having a lot of trouble getting the TInyFPGA board working on MacOS.
The underlying problem seems to be that the “tinyprog” program just can’t
see the board.
I’ve tried most of the ideas posted here (and thanks for all that!).

My setup:

MacOS 10.11.5 (El Capitan)
Python 3.6.3
tinyprog-1.0.21

board plugged into USB: TinyFPGA BX
the red LED looks like it is breathing. (that’s good I assume)

I pretty much get the same output from tinyprog for each variation (–libusb or --pyserial):
It just can’t find the board.

$ tinyprog --pyserial -l

TinyProg CLI
------------
Using device id 1d50:6130
No port was specified and no active bootloaders found.
Activate bootloader by pressing the reset button.

I noticed that the Serial app doesn’t see the tinyFPGA board at all.
It sees an Arduino Uno just fine.
But, when I hold the reset button, Serial shows some kind of CDC device,
that vanishes as soon as I let go.

I’m really stuck here.
Does anyone have this board working with a similar Mac?

-Rolf


#52

Have you tried it on a Windows machine yet? Let’s rule out the board or the computer as an issue.


#53

Hi Luke,
Thanks for stepping in.
I met with Tim A. at the Hackaday event this weekend, and we tried another
“BX” board to see if that helped. It did not.

Here’s the output from tinyprog (see below).
(Note: I added some better debugging to a print stmt, but changed nothing else)

I don’t know what else to try at the moment!
-R

===
$ tinyprog -l

TinyProg CLI
------------
Using device id 1d50:6130
Only one board with active bootloader, using it.
Boards with active bootloaders:

opcode 0xab, type of data is <class ‘bytes’>, len 0
opcode 0x9f, type of data is <class ‘bytes’>, len 0
opcode 0xab, type of data is <class ‘bytes’>, len 0
opcode 0x48, type of data is <class ‘bytes’>, len 1
opcode 0x48, type of data is <class ‘bytes’>, len 1
opcode 0x48, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
opcode 0xb, type of data is <class ‘bytes’>, len 1
Traceback (most recent call last):
File “/Users/Admin/.virtualenvs/fpga/bin/tinyprog”, line 11, in
sys.exit(main())
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/tinyprog/main.py”, line 296, in main
p = TinyProg(port)
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/tinyprog/init.py”, line 227, in init
self.meta = TinyMeta(self)
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/tinyprog/init.py”, line 141, in init
self.root = self._read_metadata()
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/tinyprog/init.py”, line 170, in _read_metadata
[self._parse_json(self.prog.read(int(math.pow(2, p) - (4 * 1024)), (4 * 1024)).replace(b"\x00", b"").replace(b"\xff", b"")) for p in [17, 18, 19, 20, 21, 22, 23, 24]]
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/tinyprog/init.py”, line 170, in
[self._parse_json(self.prog.read(int(math.pow(2, p) - (4 * 1024)), (4 * 1024)).replace(b"\x00", b"").replace(b"\xff", b"")) for p in [17, 18, 19, 20, 21, 22, 23, 24]]
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/tinyprog/init.py”, line 277, in read
data += self.cmd(0x0b, addr, b’\x00’, read_len=read_length)
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/tinyprog/init.py”, line 245, in cmd
return self.ser.read(read_len)
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/tinyprog/init.py”, line 100, in read
data = self.IN.read(length)
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/usb/core.py”, line 402, in read
return self.device.read(self, size_or_buffer, timeout)
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/usb/core.py”, line 988, in read
self.__get_timeout(timeout))
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/usb/backend/libusb1.py”, line 833, in bulk_read
timeout)
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/usb/backend/libusb1.py”, line 936, in __read
_check(retval)
File “/Users/Admin/.virtualenvs/fpga/lib/python3.6/site-packages/usb/backend/libusb1.py”, line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 84] Overflow


#54

Sorry, no idea why discourse is using a large font there! -R


#55

We managed to solve it.
Thanks for the help.
-R


#56

What was the solution?


#57

Hi @RolfW, I’d love to know what the problem and solution was. Would you be able to share that here?


#58

Just a heads up: I tried all the suggestions here, but I haven’t seen any signs of the tinyfpga on my MacBook (fully up to date). I’ve tried three versions of tinyprog, including the last mentioned beta.

(Funny how USB problems seems to be the bane of all my FPGA dev kits; it was why I dropped the XuLA. FWIW, I have had most consistent success with Altera’s USB Blaster.)


#59

Ok, can you post the following information?

  • Which MacBook model?
  • Which version of MacOS?
  • Are you using any hubs?
  • Have you tried USB cables verified to work with other devices?

#60

Away from home, but a 2017 MacBook Pro w/Touch,
running 10.14 (latest OS, latest version),
no hubs, but it is using a USB-C/A adapter,
short cable that I have used with other FPGA boards.

I’ll prod it more tonight or if you’ll be in Milpitas Friday, I’ll bring my gear.