Propeller lost on COM...
Philldapill
Posts: 1,283
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.
Comments
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
I agree with you desilva, the prop is probably going into reset due to some voltage drop...
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)
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.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook
Got an SD card? - PropDOS
A Living Propeller FAQ - The Propeller Wiki
(Got the Knowledge? Got a Moment? Add something today!)
-Phil
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 1/12/2008 1:25:11 PM GMT
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).
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster
DGSwaner
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.
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.
Andy