If you read the thread Beau mentioned, you'll see that the problem is that the FTDI chip on the Prop Plug gets its power from the USB bus. If there's no USB bus power available, it can "steal" a little bit of power from the idle transmit line from the Prop since idle is a +3.3V signal. The little bit of power is enough to generate a false reset, but not enough for the FTDI chip to work properly. The fix is to not initialize the serial I/O routines unless there's a PC connected. You can do that by testing the receive line from the FTDI chip. If it's high (idle), the FTDI chip is operating and there's a PC attached. If it's low, there's either no PC attached or there's a PC, but it's ignoring the Prop (no virtual serial port open).
Actually, you don't check every time you send data. You check once during program initialization and either skip initializing whatever serial driver you're using (like FullDuplexSerial) or not. During your program, you have to avoid calling your serial driver because it won't be working properly or you'll need to modify the driver to ignore transmit / receive calls if the driver is not initialized. If the driver is not initialized, the I/O pins to the FTDI chip will both be inputs and the FTDI chip will be unpowered.
When you post code more than a few lines, please post it as a file attachment to your message, not cut and paste into the message.
As an alternative to any program changes, you can simply add 4.7K pull-ups to the Prop's P30 and P31 pins. These will provide adequate, constant parasitic power to the FTDI chip to keep it from reset cycling. 'Not the best solution, perhaps, but it works reliably.
This worked, how can I mark as solved ? or can I ?
I think you just edit the first post.
Its funny that you had a 10 second error, because I happen to try to repeat it and found a program that was transmitting on all FTDI serial ports every 10 seconds at 115200 baud.
I use a hash calculator program to get my processor and graphics cpu hot.. (for benchmarking and overclocking etc)
It turns out that one of the "miners" called cgminer has code in it that wrecklessly opens all FTDI ports and transmits on them.
Its a program that is trying to find a device called "bitforce". (its a fpga hashing cpu) to mine digital hashes. https://github.com/ckolivas/cgminer/blob/master/driver-bitforce.c
This code is included in almost all "miners" and so most computers that run a miner program most likely have this FTDI port access every 10 seconds
It will transmit "ZGX" at 115200 baud every 10 seconds on all FTDI ports.
Zetsu
Posts: 186
Comments
Post your code as an attachment so we can better help you in your situation.
More than likely, the problem is something similar to what the link below describes. It's difficult tell without looking at your code.
http://forums.parallax.com/showthread.php?135067-Serial-Quirk&p=1043169&viewfull=1#post1043169
When you post code more than a few lines, please post it as a file attachment to your message, not cut and paste into the message.
-Phil
I think you just edit the first post.
Its funny that you had a 10 second error, because I happen to try to repeat it and found a program that was transmitting on all FTDI serial ports every 10 seconds at 115200 baud.
I use a hash calculator program to get my processor and graphics cpu hot.. (for benchmarking and overclocking etc)
It turns out that one of the "miners" called cgminer has code in it that wrecklessly opens all FTDI ports and transmits on them.
Its a program that is trying to find a device called "bitforce". (its a fpga hashing cpu) to mine digital hashes.
https://github.com/ckolivas/cgminer/blob/master/driver-bitforce.c
This code is included in almost all "miners" and so most computers that run a miner program most likely have this FTDI port access every 10 seconds
It will transmit "ZGX" at 115200 baud every 10 seconds on all FTDI ports.