PropLoader hangs when specifying a /dev/tty port, instead of /dev/cu port, on a Mac.

[vampjaz]

[EDITED by PropGit - Issue title renamed; it was first thought to be a problem with opening a file (and hanging) but later seemed to be a problem due to specifying a tty port instead of a cu port on the Mac]

I'm on a Mac, trying to load some code on to my Quickstart Board, and I'm having a very strange error. When I'm in the spin-standard-library repository that I cloned to test out the demos, I can compile (using OpenSpin) all the files fine and upload them over serial to my Prop. However, if I copy the files anywhere else on my computer, PropLoader will just say "Opening file 'temp.binary'" and hang forever.

The weird thing is that when I copy any other spin or binary files into the Spin Standard Library directory, they can upload fine. When the process hangs, it doesn't use any CPU, it just resets the prop and prints that message. I sampled the execution after it did this:

Sampling process 43491 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling proploader (pid 43491) every 1 millisecond
Process:         proploader [43491]
Path:            /Users/dev/Documents/Programming/git/PropLoader/proploader
Load Address:    0x101963000
Identifier:      proploader
Version:         0
Code Type:       X86-64
Parent Process:  bash [36574]

Date/Time:       2017-03-25 09:28:50.553 -0600
Launch Time:     2017-03-25 09:25:17.509 -0600
OS Version:      Mac OS X 10.12.3 (16D32)
Report Version:  7
Analysis Tool:   /usr/bin/sample
----

Call graph:
    2743 Thread_484463   DispatchQueue_1: com.apple.main-thread  (serial)
      2743 start  (in libdyld.dylib) + 1  [0x7fff9e590255]
        2743 main  (in proploader) + 7830  [0x101965dd6]
          2743 Loader::fastLoadImage(unsigned char const*, int, LoadType)  (in proploader) + 353  [0x101969571]
            2743 SerialPropConnection::loadImage(unsigned char const*, int, unsigned char*, int)  (in proploader) + 81  [0x10196bc31]
              2743 SerialPropConnection::loadImage(unsigned char const*, int, LoadType)  (in proploader) + 262  [0x10196bd96]
                2743 SerialPropConnection::sendData(unsigned char const*, int)  (in proploader) + 83  [0x10196b553]
                  2743 SendSerialData  (in proploader) + 39  [0x101974457]
                    2743 write  (in libsystem_kernel.dylib) + 10  [0x7fff9e6c087a]

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):
        write  (in libsystem_kernel.dylib)        2743

Any ideas? The proploader binary is in /Users/dev/Documents/Programming/git/PropLoader/proploader and is symlinked to /usr/local/bin/. The only directory that seems to work when uploading is /Users/dev/Documents/Programming/git/spin-standard-library and its subfolders.

[PropGit]

Thanks for all the info! I don't know why that would happen, but you've given us plenty to try to duplicate it on our side. We'll try it out and see if we can get to the bottom of it.

[vampjaz]

Now I can't get it to upload at all after restarting. Another note, it does error if the prop is unplugged:

Opening file 'Graphics_Demo.binary'
ERROR: Unable to connect to port /dev/tty.usbserial-AH00OPJZ

[vampjaz]

$ proploader -v
PropLoader v1.0-24 (2017-01-05 10:00:59 g40ee527)

[vampjaz]

Update: I tried using the other serial port and it worked:

$ openspin Graphics_test.spin -o temp.binary && proploader -p /dev/tty.usbserial-AH00OPJZ temp.binary
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2016 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.80 Compiled on Mar 12 2017 15:40:19
Compiling...
Graphics_test.spin
|-display.tv.spin
|-display.tv.graphics.spin
Done.
Program size is 4668 bytes
Opening file 'temp.binary'
^C

$ openspin Graphics_test.spin -o temp.binary && proploader -p /dev/cu.usbserial-AH00OPJZ temp.binary
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2016 Parallax Inc. DBA Parallax Semiconductor.
Version 1.00.80 Compiled on Mar 12 2017 15:40:19
Compiling...
Graphics_test.spin
|-display.tv.spin
|-display.tv.graphics.spin
Done.
Program size is 4668 bytes
Opening file 'temp.binary'
Downloading file to port /dev/cu.usbserial-AH00OPJZ
4668 bytes remaining             
3644 bytes remaining             
2620 bytes remaining             
1596 bytes remaining             
572 bytes remaining             
4668 bytes sent                  
Verifying RAM
Download successful!

I had been using the /dev/tty.usbserial-XXXXX port and it worked for some of the time. When I switched to the /dev/cu.usbserial-XXXXX port, it started working again. Could be a problem with the FTDI drivers?

[PropGit]

Yes, it could be a driver issue.

Is one port a USB 3.0 and others USB 2.0?

To see what driver is connected to the port when the board is connected...

• Open a Terminal window
• Enter: kextstat | grep FTDI
  • If all is well, it will report a line of information with the driver listed in reverse-domain form (com.FTDI.driver.FTDIUSBSerialDriver).
  • Otherwise, it's probably using the Apple driver or no driver at all.

[vampjaz]

Both ports on my laptop are USB 3; and it looks like the FTDI driver loads. Side node:

$ proploader -P
/dev/cu.usbserial-AH00OPJZ

The CU port is the only one listed...

[PropGit]

Oh! I'm sorry, I somehow missed that! The /dev/cu.usbserial ports is all we use and I assumed you had used -P option to determine what port to use. The "cu.usbserial" port should continue to work great for you; sorry for the confusion and trouble.

@dbetz - [See thread above] I think we specifically filter out the /dev/tty. ports from the list returned by -P option, right? If so, based on this interaction, we should add a special error message that leads the user in the right direction if they end up requesting a /dev/tty. port when communicating. What do you think?

[dbetz]

Probably a good idea.