View Full Version : Propeller lost on COM...

01-12-2008, 06:02 AM
Does anyone else have this problem constantly? When I try to load a program into the prop, everything goes fine; compiles, Loads RAM, SEEMS to verify RAM, then gives the "Propeller Lost on COM X." error? Recently, it would do this about 5 out of 6 times! I'm using the Education Kit, btw, and my 5V regulator seems warm to the touch without any load but an SD Card and a TV adapter.

01-12-2008, 06:13 AM
When you say: "I use the Education Kit" this will give no information to what you have built up...
So you have somthing on a breadboard.

When the regulator gets warm, you have a semi-shortcircuit in the 5V net somewhere.. look for it.. remove suspective parts.. It can even be the 3.3 V regulator

This problem goes hand-in-hand with your description of what happens during loading: The voltage most likely falls below the point of brown-out detection, and the propeller resets.

Post Edited (deSilva) : 1/11/2008 11:25:17 PM GMT

01-12-2008, 06:32 AM
Yeah, that's why I mentioned the warm regulator. As for the Education Kit, I was implying that it is simply on a breadboard - The Protoboard has heatsinks on the regulators. Sorry for the confusion. Now, as for the circuit, like I said, no load except the SD Card and TV Out. No shortcircuits that I can see anywhere... However, I am using a 9V wallwart and the Open Circuit Voltage of it is about 12V. The only thing I can think of is that the 5V reg. is dropping a good bit of voltage...?

I agree with you desilva, the prop is probably going into reset due to some voltage drop...

01-12-2008, 06:43 AM
The 5 V regulator will only warm-up when current in running through it. So where is this current going to? Into the 3.3V regultor? Do you have a mutimeter with which you can measure current? Check after the 5V regulator and after the 3V3 regulator.
12V is a little bit high, but will be no problem when you just draw 100 or 200 mA... 300 mA will indeed warm it-up considerable (=2W)

Mike Green
01-12-2008, 06:45 AM
It can also be due to Windows trying to download updates while trying to send a program to the Propeller. I've had this happen before with intermittant lost connections on a download to the Propeller

01-12-2008, 06:58 AM
Regarding hot regulators. The default regulator on the $10 protoboards seem to want 7V input nominal. I've had the hot regulator problem with any power brick greater than 5V. Tried a different regulator rated with range from 6V to 25V with similar result. I've finally concluded that the heatsink tab is there for the special purpose of dissapating excess heat :)

As far as that connection problem, I've had it too and frequently. I think windows is slow to close the port on one hand since i've had the issue between starting programs. On the other hand it seems that Prop was too busy or just rebooting when the error happened.

Oldbitcollector (Jeff)
01-12-2008, 06:58 AM
Speed of the computer running prop-tool, along with if something else is running at the same time you are programming can cause this type of error. Make sure everything is turned off, as Mike indicated.


New to the Propeller?

Getting started with the Protoboard? - Propeller Cookbook (http://ucontroller.com/Propeller%20Protoboard%20Designs%20for%20the%20Beg inner.pdf)
Got an SD card? - PropDOS (http://www.orrtech.net/propdos/)
A Living Propeller FAQ - The Propeller Wiki (http://propeller.wikispaces.com/)
(Got the Knowledge? Got a Moment? Add something today!)

Phil Pilgrim (PhiPi)
01-12-2008, 07:01 AM
If you're using a PropPlug or some other USB-to-serial converter, check its latency settings using the control panel. What you're reporting can happen if it's set to the sometimes default value of 16. If it is, change the setting to 1.


01-12-2008, 08:28 AM
Yep. Mike, I had something similiar to Windows update going. BitTorrent. I closed it and haven't had the problem(yet) after ~15 loads.

01-12-2008, 03:51 PM
I have the same problem using Prop Dongles, it seems to be interaction with Windows, has always reloaded without incident, does not happen on Mac running Parallels...

01-12-2008, 08:19 PM
This keeps happening to me. I thought I'd damaged the Prop chip on one of my boards yesterday. Tried it again today, on my main PC, and it was just the same. Tried my laptop which didn't work yesterday, and it's OK now. It must be something that is running in the background. I don't have any problems with various other interfaces, like JTAGs for ARM, Xilinx or MSP430, or a Microchip ICD2.


Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/12/2008 1:25:11 PM GMT

Mike Green
01-12-2008, 10:46 PM
I can't speak for the other microprocessors, but the download protocol for the Propeller is sensitive to serial port timing for a number of reasons. In particular, there's a timeout for a long sequence of data exchanged between the Propeller and the PC and the timeout leaves little extra time beyond that needed for the characters to go back and forth. I've used the Propeller Tool on a PowerPC-based Mac using a PC simulator (Guest PC) and Windows XP and could get a successful download 3 out of 4 times at least. When a Windows update was going it, the downloads would always fail due to the additional overhead. Now, on an Intel-based Mac using Parallels Desktop to run Windows under the Mac OS, downloads work all the time (except when Windows Update is running when they'll fail every once in a while).

01-12-2008, 11:24 PM
Phil Pilgrim (PhiPi) said...
If you're using a PropPlug or some other USB-to-serial converter, check its latency settings using the control panel. What you're reporting can happen if it's set to the sometimes default value of 16. If it is, change the setting to 1.


Hi Phil. Thanks for the tip.

My driver's latency was set to 16. I tried at 1 and the com error went away, but the interface audibly "sang" about a 1KHz tone. Setting to 2 was also reliable and I could hear a lower tone. Set to 3 the tones seemed to go away and the com error only happened rarely.

FYI other users if you don't know where to find this:

1. At "Start" click to open "Control Panel"
2. Then find and click to open "System"
3. Then find and click "Hardware" tab
4. Then find and click to open "Device Manager"
5. Then find and click "Ports (COM & LPT)" to show contents under the "+"
6. Then right-click on·"USB Serial Port (COM..)" and click "Properties"
7. Then find and click "Port Settings"
8. Then find and click to open "Advanced"
9. Then change "Latency Timer(msec)" to desired value.
10.·Finally "OK" and close previously opened windows.

01-13-2008, 12:16 AM
The Propeller is sensitive to download timing and seems to have a very short timeout which can cause problems if the transfer rate isn't kept consistent or is interrupted, much like the old days of getting Buffer Underrun when burning CD's when the burner didn't get the fullest attention from the OS.

I personally haven't had many problems at all with my relatively slow PC ( 1GHz Celeron ) when switching applications during downloads, but when writing my own Propeller Bootloader it was quite easy to lose the link if the data didn't flow smoothly and consistently. Anything which interrupts the download process for all but a short time seems likely to cause problems.

01-13-2008, 10:39 AM
I have the same problem on one of my computers, I had a 10' usb extension cabel and then the cord to the propplug. It got to the point where I couldn't program a propeller at all. I got rid of the 10' cable and it helped a lot. this is on an older computer with usb 1.0 and pretty bogged down by apps, I have a laptop that works just fine, older pc with usb 1.0. will all of the same parallax hardware

"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster


03-16-2011, 10:04 PM
Did anyone ever get a definitive fix for this problem from tech support? I've tried changing the USB driver latency timer and it didn't make any difference. I find it hard to believe that I have a bad desktop, and bad Fujitsu laptop, bad FTDI USB adapters a bad professional development protoboard and a bad prop board. Far more likely is that this is an engineering flaw that needs to be addressed. Copying a program over a serial port should be a no-brainer and not dependent on subtle timing issues. Small programs aren't a problem which is why most people don't notice the problem. However, after a certain size, the product becomes unusable.

03-17-2011, 12:47 AM
Copying a program over a serial port should be a no-brainer and not dependent on subtle timing issues.

The thing is though that it's not a simple 'copy the program over', not a typical one byte of code sent as one byte of serial which most other download protocols may use. Each one or zero bit is sent as a 'timed pulse' and those pulses, and the times between them, are time critical. Those pulses are conveyed in serially transmitted bytes but it's not a traditional byte-for-byte transfer.

The problem comes when one byte isn't sent soon enough after the previous, for example if Windows goes and does something else or a driver buffers rather than sends. The Propeller then timesout, resets, download fails, connection lost.

03-18-2011, 08:56 AM
The PropellerTool has these problems since the last big revision of the Serial Loader. If I remember correct Parallax has changed the serial code to a own thread inside Windows to make it faster. But I think they have set the timeout that waits for the Acknowlege from the Propeller too short.
I have found that an older PropellerTool (I use version 1.05) can load a big program without problems, but with version 1.2.6 I get an Error with the same code.
BST also can load this code without problems, so another good reason to move to BST.