-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USB "set options" error #101
Comments
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. |
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. |
Version 1.0.1 will be release 5/22/2020. It may have fixed this issue. Please verify. |
Latest release on Parallax website is still 0.11.2. |
The 1.0.1 installers for Windows and MacOS have been deployed to Solo and the Parallax web site. |
The Parallax website has been updated this morning as well. |
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. |
@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. |
Can you try this on solo.parallax.com and see if you have better results? |
On solo.parallax.com now:
Okay, log stuff to follow... |
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? |
With Prop Tool, download succeeds immediately , without delay, after plugging in USB cable. |
Thanks. Let's see what FTDI driver version is attached to that port.
May need to check Programs and Features also, near the bottom, for Windows Driver Package - FTDI CDM... and ...Parallax Inc CDM... version(s). |
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. |
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.
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. |
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? |
Unfortunately not. |
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. |
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. |
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? |
Sorry for missing this response.
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.
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.
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. |
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.
The text was updated successfully, but these errors were encountered: