I checked that site and I do not think any of the issues are what is wrong. I use a wireless kybd/mouse combo that utilizes one of my USB ports and I am not having any "hang" issues. I had planned on replacing my motherboard/cpu/ram soon any how so when I do that I will reinstall everything. Prior to doing any Windows updates I will test to make sure my Prop BOE works. If it quits working after all the Windows updates then I know that is the issue.
Attachment not found.
I am using Prop Tool. Here is a simple program that works in EEPROM and fails in RAM. Not sure how it would be a brown out using a 12V wall wart. I have tried 3 different ones.
A brown out doesn't always mean a problem with your AC to DC adapter, it could be something else, or even a short. If you can, run this code (you'll need the PST object).
First disconnect everything from the prop pins. Load code below into RAM and let run for a few minutes. If you have a brown out you'll see the word "reboot" in the PST. Do this using a battery power source.
If you get brown outs then you can stop troubleshooting everything else and assume there is something on your Prop board that is bad. If you don't get reboots then it is something with your external circuit.
I doubt that any USB issue especially power, would not be noticed by the host OS of the computer. If it is happening on three boards then there is probably something amiss with your circuit, or power supply.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
pst : "Parallax Serial Terminal"
VAR
Word time
PUB main
pst.Start(115200) 'start PST
waitcnt (clkfreq * 1 + cnt) 'give user time to enable PST
pst.str(string(pst#NL,"REBOOT "))'power/brown out notification
time := 0
repeat
time := time + 1
pst.dec (time)
pst.str (string(" "))
waitcnt (clkfreq + cnt)
I think we've ruled out power supply issues, since his program fails with various supplies, but only when his main PC is connected and only when the program runs from RAM. But then, all programs run from RAM -- even EEPROM programs. Suspecting a reset, that's why I asked if the flashing program, when run from EEPROM, showed any hiccups or hesitations, which would be obvious during a restart, since the Prop's reboot from EEPROM takes awhile. He said no. None of this really adds up, quite frankly.
I think we've ruled out power supply issues, since his program fails with various supplies, but only when his main PC is connected and only when the program runs from RAM. But then, all programs run from RAM -- even EEPROM programs. Suspecting a reset, that's why I asked if the flashing program, when run from EEPROM, showed any hiccups or hesitations, which would be obvious during a restart, since the Prop's reboot from EEPROM takes awhile. He said no. None of this really adds up, quite frankly.
-Phil
Oops, I missed a few details in getting caught up, thanks.
Yea, I know. Which is why I am leaning towards MS updates. They seem to have a way of screwing up one thing when attempting to fix another. If I get a chance later today I will pull out my BS2 USB BOE board to see if I have the same problem.
I'm totally fascinated. I have used FTDI devices like the Prop Plugs and so on for years and never had to install a driver for one. Let alone update one.
I don't know. They have drivers for Linux and the Mac OS also. Those weren't updated though.
Maybe this is why:
All FTDI devices now supported in Ubuntu 11.10, kernel 3.0.0-19
In the Windows world, lots of stuff requires drivers. Since the only FTDI based devices I own are made by Parallax, I only use the version they provide. Windows Update offers no control over how the drivers it installs are setup, usually it's the default settings. If I let it install Nvidia updates, I get a bunch of 3D garbage also, which I have no use for.
If Windows Update updated the FTDI driver, I would reinstall the one that Parallax provides. I don't trust Windows Update in the least and would never allow it on a mission-critical system.
So, I have narrowed it down to something with the USB port(s) for sure. I ran the program with my wall wart and USB cable plugged in. As soon as the program started I unplugged the USB cable and the LED flashed indefinitely. I have uninstalled all USB drivers and only installed the Parallax driver that comes with the Prop Tool. This still did not work.
Well, maybe I'm missing a point here but don't the USB standards include such things as handling serial adapters, human interface devices and so on.
So, as long as your OS is written to handle those standards no drivers need installing for every new chip that comes along that does that.
I assumed that is why I have never had to install a driver into Linux to handle serial adapters.
Or is it so that this whole USB thing is a big failure?
So, I have narrowed it down to something with the USB port(s) for sure. I ran the program with my wall wart and USB cable plugged in. As soon as the program started I unplugged the USB cable and the LED flashed indefinitely. I have uninstalled all USB drivers and only installed the Parallax driver that comes with the Prop Tool. This still did not work.
Interesting, can you try on another computer? That should narrow it down a bit more.
Hmmm. it doesn't sound like the USB driver is the issue, maybe the way the FTDI chip is wired into the board. I am quite wary of how it distributes power to itself.
Personally, I prefer to keep my projects on a PropPlug... as I clearly understand the power distribution.
maybe the way the FTDI chip is wired into the board
I do not think so as it all worked before I had to wipe the system clean due to Windows updates messing up my being able to remote in to client systems through a SonicWall device.
I saw post #18 and assumed something changed since then, sorry. Maybe try forcing a different virtual com port? Sometimes changing the port clears up strange issues with devices.
See post #18. I do not think so as it all worked before I had to wipe the system clean due to Windows updates messing up my being able to remote in to client systems through a SonicWall device.
Arg... so you seem to be seeing Windows make your USB port suck the power out of the Propeller. I wonder if they think these things up at MS or they come by such things via divine intervention.
There is that other OS... Linux.
You could try running your computer in Linux via a LiveCD and see if the change in OS eliminated the hardware aspect of the problem.
I have tried every port I have with the same results. I have a 4 Port USB Hub that also accepts a 5V wall wart. Going to try that as soon as I find a 5V wall wart to see if it makes a difference or not.
EDIT: I also went as far as uninstalling ALL USB devices, restarted in Safe mode, installed the Parallax USB drivers, restarted and I still have the issue.
It works fine on his other computer...with (surprise!) Windows.
You could always install Win 7 32 bit (same as your laptop) and try that, before allowing any updates, but more than likely it's just some random hardware fault.
I will be replacing my MB/CPU/RAM soon so until then I will just unplug the USB cable when running from RAM on the Prop BOE. More time spent on this than I really wanted to. It could very well be a bad cap on the MB. However, it is only affecting my Prop boards and not my kybd/mouse combo which are wireless through a USB port.
Could you please verify the specs for your wireless kybd/mouse combo, to check its consumed current?
How it does compares to the BOE actual power needs, when your programm is running, in the fault-causing setup!
Perhaps we could figure a feeble candle, at the end of the tunnel.
Loopy doesn't that require write access to the live CD?
If you use Puppy Linux, you might need write access to the LiveCD if you want to save sessions to a CD; but other distributions tend to be for demonstration and install purposes.
In any event, the Linux uninstalled demonstration runs in RAM without affecting what is installed or the boot configuration of your hard disk. For UNIX/Linus, the hard disk remains unaffected unless you mount it and direct the Linux to in some way modify it.
Puppy Linux can be used without mounting, and it can be used without writing to CD. But you do have to make an initial LiveCD by burning a downloaded .iso file. This can be done in any OS -- Apple, Linux, or Windows.
If you have a laptop without a CD/DVD player, I believe Puppy Linux has an installer that can migrate the whole to a USB memory stick. So of the other LiveCD distributions don't directly provide this feature.
====
Then, I suspect once you have booted in Puppy Linux, you hae only to plug the Propeller into a USB port to observe the behavior.
If for some reason you might want to communicate with the Propeller, you could use minicom and load the Propeller with any version of Forth as a bench test.
Comments
A brown out doesn't always mean a problem with your AC to DC adapter, it could be something else, or even a short. If you can, run this code (you'll need the PST object).
First disconnect everything from the prop pins. Load code below into RAM and let run for a few minutes. If you have a brown out you'll see the word "reboot" in the PST. Do this using a battery power source.
If you get brown outs then you can stop troubleshooting everything else and assume there is something on your Prop board that is bad. If you don't get reboots then it is something with your external circuit.
I doubt that any USB issue especially power, would not be noticed by the host OS of the computer. If it is happening on three boards then there is probably something amiss with your circuit, or power supply.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ pst : "Parallax Serial Terminal" VAR Word time PUB main pst.Start(115200) 'start PST waitcnt (clkfreq * 1 + cnt) 'give user time to enable PST pst.str(string(pst#NL,"REBOOT "))'power/brown out notification time := 0 repeat time := time + 1 pst.dec (time) pst.str (string(" ")) waitcnt (clkfreq + cnt)Phil, an image really is worth a thousand words sometimes. :nerd:
I think we've ruled out power supply issues, since his program fails with various supplies, but only when his main PC is connected and only when the program runs from RAM. But then, all programs run from RAM -- even EEPROM programs. Suspecting a reset, that's why I asked if the flashing program, when run from EEPROM, showed any hiccups or hesitations, which would be obvious during a restart, since the Prop's reboot from EEPROM takes awhile. He said no. None of this really adds up, quite frankly.
-Phil
Oops, I missed a few details in getting caught up, thanks.
There was an FTDI driver update included in a Windows Update last month.
http://forums.parallax.com/showthread.php/149743-FTDI-driver-update
You might check into whether this could be part of your problem. Personally, I doubt Windows has anything to do with the problem, but you never know.
What is going on?
I don't know. They have drivers for Linux and the Mac OS also. Those weren't updated though.
Maybe this is why:
In the Windows world, lots of stuff requires drivers. Since the only FTDI based devices I own are made by Parallax, I only use the version they provide. Windows Update offers no control over how the drivers it installs are setup, usually it's the default settings. If I let it install Nvidia updates, I get a bunch of 3D garbage also, which I have no use for.
-Phil
So, as long as your OS is written to handle those standards no drivers need installing for every new chip that comes along that does that.
I assumed that is why I have never had to install a driver into Linux to handle serial adapters.
Or is it so that this whole USB thing is a big failure?
Interesting, can you try on another computer? That should narrow it down a bit more.
Personally, I prefer to keep my projects on a PropPlug... as I clearly understand the power distribution.
Arg... so you seem to be seeing Windows make your USB port suck the power out of the Propeller. I wonder if they think these things up at MS or they come by such things via divine intervention.
There is that other OS... Linux.
You could try running your computer in Linux via a LiveCD and see if the change in OS eliminated the hardware aspect of the problem.
EDIT: I also went as far as uninstalling ALL USB devices, restarted in Safe mode, installed the Parallax USB drivers, restarted and I still have the issue.
Try Linux on a Live CD and you will immediately know if you have a hardware or an OS specific issue.
You could always install Win 7 32 bit (same as your laptop) and try that, before allowing any updates, but more than likely it's just some random hardware fault.
Could you please verify the specs for your wireless kybd/mouse combo, to check its consumed current?
How it does compares to the BOE actual power needs, when your programm is running, in the fault-causing setup!
Perhaps we could figure a feeble candle, at the end of the tunnel.
Yanomani
If you use Puppy Linux, you might need write access to the LiveCD if you want to save sessions to a CD; but other distributions tend to be for demonstration and install purposes.
In any event, the Linux uninstalled demonstration runs in RAM without affecting what is installed or the boot configuration of your hard disk. For UNIX/Linus, the hard disk remains unaffected unless you mount it and direct the Linux to in some way modify it.
Puppy Linux can be used without mounting, and it can be used without writing to CD. But you do have to make an initial LiveCD by burning a downloaded .iso file. This can be done in any OS -- Apple, Linux, or Windows.
If you have a laptop without a CD/DVD player, I believe Puppy Linux has an installer that can migrate the whole to a USB memory stick. So of the other LiveCD distributions don't directly provide this feature.
====
Then, I suspect once you have booted in Puppy Linux, you hae only to plug the Propeller into a USB port to observe the behavior.
If for some reason you might want to communicate with the Propeller, you could use minicom and load the Propeller with any version of Forth as a bench test.
Sounds like he would need some way to program the Propeller from Linux.
I wonder what kind of computer this is?