USB "set options" error

[phil-pilgrim]

I get the below-illustrated error quite often. It happens with a Propeller Activity Board whenever I power it off and back on -- once in a while at other times, too. The USB is still connected and recognized by Solo and my PC (Win 7). I have to unplug the USB connector, wait for the port to disappear from the Solo menu, plug it back in again, and wait some more for it to reappear. I do not have a similar issue with the Propeller Tool, for example.

[PropGit]

Thank you, @phil-pilgrim. I've been trying to find the source of this problem and your details help me track it down. Prior to your report, I was not able to determine anything that makes it happen deterministically. I'll try your tests and report back here.

[PropGit]

Actually, this is a problem that seems fully involving BlocklyProp Launcher and not Solo directly, so I'm transferring the issue from Solo to the Launcher repository.

[PropGit]

Version 1.0.1 will be release 5/22/2020. It may have fixed this issue. Please verify.

[phil-pilgrim]

Latest release on Parallax website is still 0.11.2.

[zfi]

The 1.0.1 installers for Windows and MacOS have been deployed to Solo and the Parallax web site.

[PropGit]

The Parallax website has been updated this morning as well.

[phil-pilgrim]

I'm sorry to report, but I still get the same error. Moreover, even when it "works," I sometimes have to wait seven or eight seconds after I see Download... for the actual downloading to begin. Also, if I try to download with the USB cable plugged into the Activity Board, but with the power turned off, I get the Cannot set port options error, instead of "No Propeller found." Finally, downloading never works after the first time the USB cable is connected. This is what I see:

The second attempt works, though, unless I get the Cannot set port options error.

Just to verify:

Again, running Chrome on Win7.

[zfi]

@phil-pilgrim: Are you running this on solo.parallax.com or blockly.parallax.com? We have tested both sites extensively and have not seen the issue you are noting after the 1.0.1 Launcher release.

[phil-pilgrim]

https://phil-pilgrim.github.io/solo/blocklyc.html

[zfi]

Can you try this on solo.parallax.com and see if you have better results?

[PropGit]

I just did 25 successful downloads from your site.

This may be a hardware/timing difference I can't duplicate.

Please click on the Launcher's gear icon and check Verbose Logging, then do a download and past a screenshot. Here's mine from a download via your Solo site:

[phil-pilgrim]

On solo.parallax.com now:

1. With the USB cable plugged in, and with the Activity Board power off, I don't get any error; it just hangs after Download...

2. After unplugging the USB cable, turning on the AB, then plugging in the USB cable, and waiting for the port number to appear in the drop-down menu, a download hangs for awhile before I get the Cannot find port error.

3. Second time I got a successful download, but only after waiting a minute or more for it to begin.

4. Third and subsequent times, same thing. During the wait, there is no activity indicated by the AB's USB LEDs. Also, COM101 remains displayed in the drop-down menu.

Okay, log stuff to follow...

[PropGit]

The verbose logging starting before you plug in the USB port may help us too. I've seen some systems make the port available, but then preempt more CPU time for any software that tries to open it for a while (presumably because the kernel is still configuring something). Along that note, if you attempt a download with Propeller Tool right after plugging the USB cable back in, does it download immediately?

[phil-pilgrim]

With AB off and USB plugged in:

After turning on AB with USB still plugged in:

Second attempt with AB still on:

Unplug USB, then plug it back in:

I got no successful downloads during this test sequence.

[phil-pilgrim]

With Prop Tool, download succeeds immediately , without delay, after plugging in USB cable.

[PropGit]

Thanks.

Let's see what FTDI driver version is attached to that port.

• Plug the AB in via USB
• Open up Windows Device Manager
• Expand Ports (COM & LPT)
• Double-click the "USB Serial Port (COM101)" item
• Select the Driver tab
• Screenshot.

May need to check Programs and Features also, near the bottom, for Windows Driver Package - FTDI CDM... and ...Parallax Inc CDM... version(s).

[PropGit]

With Prop Tool, download succeeds immediately , without delay, after plugging in USB cable.

That's interesting. I'm out of ideas at the moment. I'll check back when something occurs to me or if you have an update. Thank you very much for trying this out.

[phil-pilgrim]

[PropGit]

That version should be fine, though in my case I'm using 2.12.28. We haven't wrapped that one yet for customers because we haven't known of any problems really requiring it. FTDI hasn't been very clear about what changes were included since then. You can get their executable installer here if you want to try it: https://www.ftdichip.com/Drivers/CDM/CDM21228_Setup.zip

However, before you do such a thing, please try the attached version of BlocklyProp Launcher (v1.0.2). I've added a log of a chrome error (if there is one) that should appear before the "Can not set port... options" error you're getting.

BPL_v1.0.2.zip

• Close your current BP Launcher
• Extract the archive into a new (empty) folder
• Navigate Chrome to chrome://extensions
• Turn on Developer Mode (upper-right)
• Click Load Unpacked and point it at the folder where you extracted the archive
• Open a new tab and click the Apps button or navigate to chrome://apps and find the BP Launcher and run it

Make sure it shows v1.0.2 at the bottom of it's window when it runs.

Try the same tests you did before that resulted in the "Can not set port... options" message, then take a screenshot of the log view in BlocklyProp Launcher.

[phil-pilgrim]

Done:

[PropGit]

Thanks. That proves that there's no error condition I'm missing at that point in the code, but it doesn't clearly lead me to a solution... I still don't know why it fails on your computer.

Do you have another Win7 computer you can try this on?

[phil-pilgrim]

Do you have another Win7 computer you can try this on?

Unfortunately not.

[phil-pilgrim]

Just an update: I installed the 2.12.28 FTDI driver, but nothing under BPLauncher 1.0.1 has changed.

BTW, before rerunning the tests, I was getting a persistent message that Solo could not find the launcher. Reinstalling the launcher fixed that problem.

[PropGit]

Thanks @phil-pilgrim. I have another idea; perhaps something in the stream is causing a communication error, such as an undetected stop bit. The serial API used in the app tends to "pause" the port when this happens and Launcher has to unpause it. When the port is "paused" there's not much that can be done with the port through the API. I think it's already unpausing, but perhaps it needs to unpause at a different point in the stream.

If your project is transmitting any data during runtime, this is a possibility. It should be reasonably detectable by starting fresh (in a state where the download is likely to be successful) switching to another project that perhaps just blinks LEDs or actuates a motor instead of sending serial data over the USB connection, then attempt multiple downloads of that non-serial project (and others like it) to see if the "set options" error happens any more. Then, if no "set options" error, download your current (serial communicating) project multiple times to see if there are any errors.

[phil-pilgrim]

If your project is transmitting any data during runtime, this is a possibility.

It's not transmitting anything.

I know this was an occasional issue with PropTool, but I haven't seen it in years. Jeff Martin might be your best resource to get this sorted. In any event, asserting DTR should put an end to any transmission from the Prop, unless you wait too long, and the EEPROM program starts up again.

Did I read something somewhere about uploading a bootloader ahead of the actual program? If so, why not just use the the serial protocol built in to the Prop's ROM loader?

[PropGit]

Sorry for missing this response.

I know this was an occasional issue with PropTool, but I haven't seen it in years. Jeff Martin might be your best resource to get this sorted.

PropGit = Jeff Martin :-)

Yes, I remember the occasional issue with PropTool. Still chasing this one you've found in BP Launcher. Another customer has same issue now and noted some additional possible clues, which brought me back to this thread.

asserting DTR should put an end to any transmission from the Prop, unless you wait too long, and the EEPROM program starts up again.

Right, asserting DTR will put an end to transmission, but the can't set options error is because the OS is refusing to control DTR at that moment... also, there could be serial data received (but not exposed by the kernel to the app layer yet) prior to a successful DTR. Makes like fun.

Did I read something somewhere about uploading a bootloader ahead of the actual program? If so, why not just use the the serial protocol built in to the Prop's ROM loader?

Yes, to achieve a much faster download (and one capable of surviving many unexpected delays in the serial stream that are imposed by new OS releases, computer hardware issues, and/or network traffic (if programming over IP; wired or wireless), I wrote a very small boot loader that can communicate at many baud rates and is fine waiting up to 2.5 seconds or so between packets. We use the ROM built-in boot loader to load this small fast boot loader which switches to using the on-board crystal as it's time base, then the host system cranks up the baud rate to 921600 and delivers the user application in a packetized fashion; it's very swift.

The problem we're seeing in this issue isn't directly related to the fast boot loader, but rather seems related to the way the Chrome engine interfaces to the Windows serial API. That's my theory, anyway.