Since your board is bus-powered, the resistor is unnecessary. (A30, BTW, is not pin 30, but port A30 on the Propeller — pin 39 on the DIP.) The reason it's necessary on self-powered systems is that the FT232R will get powered up through its Rx pin when A30 goes high as the serial I/O object starts. This causes a pulse on the DTR output, which resets the Prop. By keeping A30 high via a stiff pullup, the problem goes away. But that's not your problem, apparently.
If it's USB powered, perhaps all four cogs starting is a spike that exceeds current capability. Try 1 second delay between cognew.
Edit: I was actually wondering this and should have asked earlier. We had a discussion about powering Propellers off of USB, and the conclusion was it's possible, but a busy prop can and does sink more power than a USB port can provide, unless the device is registered, and even then some ports in some cases are questionable.
What you should see is each display come up, and if the current requirements for all of them is within tolerance, all of them working. If not, firing one up should trigger the issue, maybe display 3 or 4.
When running on a low battery, I've seen stuff like this.
IMHO, the buffer overwrite issue is looking not very likely.
Hmm...I will try the delay between them. I did try a one second delay, but I am going to try increasing that to 3-4 seconds. I don't think that is it because wouldn't it happen when I just load to the RAM then?
Is it possible to send a reset command from the computer to reset the prop? It appears that an external reset will also fix this problem? I have confirmed it does it on the breadboard also now, and if I press the reset button (wired between ground and the reset pin) this will reset the prop and cause it to start working. Does this help at all with a work around idea?
EDIT - I also think I have confirmed that all cogs are starting.· After I start each video object I modified it to return a·FALSE if it fails.· After starting each video overlay I check to see that all four have returned a TRUE.· If any return a false, I have it turn an LED on.· When it fails, the LED does not light, so it is appearing that all cogs are starting....
My gut says this is a USB device registration / power issue. Unregistered power draw is not much. I think it's like 50ma. Registered devices can pull maybe 5 times that. I'm kind of fixated on power, because I've seen behavior like that in low power + video scenarios.
I'm getting outside my comfort zone. I do think buffering and general memory issues can be ruled out though. Let's hope your perseverance and others can pull this through. It will be good to know what this is however, so I'll watch with interest.
Hmmm.... I just took a simple approch to checking that.... I remembered I had a USB charger thing out in my car that either takes 12volt in or 120. I keep in in there for charging my cell phone with a USB cable because it was a lot cheeper then a car charger...
Anyways, I went out and got that, plugged my device into it, and it does the same thing. It shows that it has a 500ma out so I think that rules out the current idea? I also tried just putting a large cap (100uf) across the 5v of the USB port to help filter, no luck there either....
I really thought it was some obscure USB thing. Just for the hell of it, maybe try a battery, or quality AC power supply, circumventing the USB power, or have you done that already?
What I'm thinking is to isolate the problem to the code, or the circuit, and I don't think that's happened yet. Once the EEPROM is programmed, it should be possible to power things directly, ignoring the USB power source entirely.
Yea, I think I am going to focus on the code for a little while, but while I am working on that I will power from my bench power supply. I have a fairly good quality Astron power supply that I think will be fine for powering this.
Was just talking with a friend and we think maybe this has been happening from when we first started designing this project. A few months ago I had it over at his house and it was doing things like this but we were thinking it was his tv/old monitor we were using, or a cable problem.
Still at a loose of how it can not work for the first few minutes, then all of a sudden, with no outside interference, take off and start working on its own. The worst kind of problems to track down are ones like this where you hardly know what the problem is, let alone what is causing it.
EDIT -
Is it possible to send a reset command only to the prop via hyperterminal?· Is there a command that causes the FT232RL to pulse its reset pin?
Does your program expect to receive valid sync signals from the LM1881s before it starts outputting to their respective monitors? If so, that may be another avenue to explore and could explain the delay if those signals are not immediately forthcoming when first powered up. I'm thinking that the EEPROM thing is a red herring and that the behavior you observe is more a glitch when the unit powers up and the sync signals are not quite ready.
I have just noticed the last post. If the beasty will run the code properly, after repowering, some of the time then the EEPROM cannot be corrupted. I veare towards the power stability also.
BUT ...
Are there any button inputs that are waving around at high impedance. All sorts happen, then depending where your hands are ..........
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
PhiPi: I am going to look into this. This sounds like the best new idea so far. I do not know too much around his overlay object, but I do know that it will also generate video if no video is detected. However, I still think it uses the LM1881 in part of its feedback loop. Have you looked at the code I attached earlier? The video overlay object I am using is one from Terry @ Hitt Consulting. Would you have ideas on where to start checking for that in my code?
Toby: I will keep digging more into a power issue. Perhaps I am getting some type of a small spike from the USB when I first power it up? I have used two machines for testing, but maybe that is just how USB operates?
There are no buttons or input devices except for the LM1881 ic's. I am using the USB/Serial connection for all the data going into the prop.
Joms said...
... but I do know that it will also generate video if no video is detected.
Well, let me ask you this then: are you providing video inputs to any of your LM1881s when the problem occurs? How is the video input to the '1881s terminated? Can you provide a full schematic of your project?
I attached a schematic of the entire circuit.· Right now I am testing the box with no video input hooked to it.· Somewhere I have a four channel video distribution amp I will start digging out right now and hook video into the four channels.· If all four have the exact same input, will that void this test?
I don't think I am terminating the input as I am relying on the output to be terminated...
I will try the circuit with four video inputs and look at the four outputs and see how it reacts.· I will keep you updated....· Thanks!
This is probably not relevant, but your 1K CSync series resistors are too small. 3.3K would be a better choice to keep within the Props input current maxima.
Do you have a scope? If so, what kind of waveforms, if any, do you see on the CSync lines? Here's an experiment to try: in your top-level program, before you do anything else, set your CSync inputs to outputs via DIRA. Does the problem go away?
Phil, I have noticed that the brownout/reset does not operate correctly if there is too much fault current flowing through the I/O which happens with too small a value current limit resistors and interfacing to voltages higher than 3.3V.
OK, I will try setting those to input and outputs right now. How would a 4.7K resistor work instead? I have a bunch of them handy....
Also, Because of the point Peter brought up, do you think that might be linked to having too small of resistors? I will start changing the programing and the resistor size right now and let you know what I come up with....
Do the resistor change first. 4.7K should be fine. If that doesn't help, do the other experiment that I suggested. (Thanks, Peter. That's a very helpful observation.)
I did a test recently of the effect on timing that the combination of a series input resistor and the Prop's input capacitance has. I always think that the value that are used a lot in Prop circuits is way too low as CMOS does not need to be driven with current except on transitions. With a value of 100K I get less than 250ns or so delay which means most of the time we could just use 100K resistors unless we were handling really fast Mhz signals. 1K is better than nothing but even in my circuits I have Vdd clamps which stop the Prop's supply form being pushed up by fault currents which besides changing switching thresholds also seems to affect the brownout/reset.
My advice, always use 100K if it's an input only or at least 10K.
Well, I went ahead and switched those resistors with 4.7k and tried a reload. The value works ok, but still having the same problem as before. I did try to reload the EEPROM also, but same problem.
I also set the pins to the proper in out, (ie. Pin1 - In, Pin2 - Out, Pin11-In). Still same problem...
What I meant was to set P0, P2, P4, and P6 (which under normal operation would be inputs) to outputs, effectively preventing the detection of syncs. If there is any noise on unused video inputs causing false CSync outputs (and confusing the overlay program) on power-up, this would squelch it.
Why use 24K of bitmaps for a few lines of Text?
Are you using TV and GRAPHICS? Do these each require their own cogs?
I have seen different behavior from different methods of booting before but not like that.
It was because of a loop that started too many cogs to do the same thing, unintentionally.
Its amazing that that program usually worked "right" when it did that.
I have no clue why where it booted from mattered.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.
Coming soon. My open Propeller Project Pages and favorite links index.
The 24K is how the overlay is written. It's a mono 256x192 bitmap, suitable for lots of things besides text. Text only could be a 5th of that, but then would also require a rewrite of the overlay object.
He's got 4 instances of the overlay operating together. Given the rest of the project can fit nicely into the RAM, it's likely not worth the effort to modify the overlay code.
Hmmm...That actually puts it into some type of a weird loop. When I look at it on my scope, the sync pulse actually starts to flash on/off.
I found my video DA and hooked the same video input to all four inputs, and the problem is still there. Is this a valid test because all the video is locked to the same sync because of the DA?
I was reading a few other posts and ran across someone else having a different problem, but wondering if it could be something here... I am searching my entire code, but wondering if I refered to the counter anywhere that I shouldn't have. Im guessing that would cause this problem, but don't see anyplace I made that mistake...
One thing I do when having issues like this is build a copy of the circuit without anything but 8 leds. Program each cog to blink each led. Using up all 8 cogs, then program that into your eeprom and see if it runs. (keeps program)
Try bypassing that transistor/capacitor that is driving the res line and push the res line directly from your rts line through a resistor similar to the tx/rx lines.
(this is the one thing in your circuit that made me uneasy.)
I run a ft2232 ftdi chip that pushes the reset line directly from the rts line.
But my ftdi chip is powered by 3.3v
I don't see why you couldn't do the same thing your doing with the tx/rx lines as with the res line, at least to help remove any possible sources of issues. Bad connections etc. Check that crystal connection also, if you have no crystal connected at all, the prop will still take a program and allow you to program the eeprom. I had a crystal with a bad connected leg, which caused all kinds of funny situations. If using a breadboard MAKE SURE to put a thin coat of fresh solder on every pin of every device you are inserting into the breadboard.
Are you refering to the transitor and cap? If so, they were listed on the drawing for the prop plug. Also, if I remember right, the transitor was in there to invert the reset pin from the FT232 ic.
The only reason for the transistor on RES that I've been able to glean from the forums was "It's a timing issue". The home-made prop plug I built with 3.3v FT232 does not have the trans or cap and it works great. DTR connects directly to RES*
Joms, if I have understood correctly from this long thread (my enghish have some issues) you have a board reproducing 4 Terry OSDs running on 1 propeller. Everything is working after a download but not (or better 1 on 5 times) after a power cycle. After a reset cycle the board is working.
Now, if the above is wrong forget this post.
Otherwise I will try this: 1) apply a bistable switch or jumper to the reset line (to gnd); 2) program the eprom; 3) assert reset; 4) power cycle the board; 5) after ~10 seconds deassert reset
If it works repeat some more times from point 3. If always work then Heater is right about the brownout detector. If the power rail rises to slow sometimes also brownout detectors fail. Perhaps an RC reset delay can help
This consideration came fron this thoughts:
- cannot be current consumption: program running from download or after eeprom boot will use same power
- if sometimes work but most of the times no: this anyway proove that eeprom has been programmed correctly
- from software point of view there is no difference between a power cycle or a reset cycle; from hw POW with a reset you do not need to charge capacitors, voltage level is already stabilized
Comments
Since your board is bus-powered, the resistor is unnecessary. (A30, BTW, is not pin 30, but port A30 on the Propeller — pin 39 on the DIP.) The reason it's necessary on self-powered systems is that the FT232R will get powered up through its Rx pin when A30 goes high as the serial I/O object starts. This causes a pulse on the DTR output, which resets the Prop. By keeping A30 high via a stiff pullup, the problem goes away. But that's not your problem, apparently.
-Phil
Edit: I was actually wondering this and should have asked earlier. We had a discussion about powering Propellers off of USB, and the conclusion was it's possible, but a busy prop can and does sink more power than a USB port can provide, unless the device is registered, and even then some ports in some cases are questionable.
What you should see is each display come up, and if the current requirements for all of them is within tolerance, all of them working. If not, firing one up should trigger the issue, maybe display 3 or 4.
When running on a low battery, I've seen stuff like this.
IMHO, the buffer overwrite issue is looking not very likely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 3/7/2010 8:56:14 PM GMT
Is it possible to send a reset command from the computer to reset the prop? It appears that an external reset will also fix this problem? I have confirmed it does it on the breadboard also now, and if I press the reset button (wired between ground and the reset pin) this will reset the prop and cause it to start working. Does this help at all with a work around idea?
EDIT - I also think I have confirmed that all cogs are starting.· After I start each video object I modified it to return a·FALSE if it fails.· After starting each video overlay I check to see that all four have returned a TRUE.· If any return a false, I have it turn an LED on.· When it fails, the LED does not light, so it is appearing that all cogs are starting....
I'm getting outside my comfort zone. I do think buffering and general memory issues can be ruled out though. Let's hope your perseverance and others can pull this through. It will be good to know what this is however, so I'll watch with interest.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Anyways, I went out and got that, plugged my device into it, and it does the same thing. It shows that it has a 500ma out so I think that rules out the current idea? I also tried just putting a large cap (100uf) across the 5v of the USB port to help filter, no luck there either....
Ideas?
Well Smile!
I really thought it was some obscure USB thing. Just for the hell of it, maybe try a battery, or quality AC power supply, circumventing the USB power, or have you done that already?
What I'm thinking is to isolate the problem to the code, or the circuit, and I don't think that's happened yet. Once the EEPROM is programmed, it should be possible to power things directly, ignoring the USB power source entirely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Was just talking with a friend and we think maybe this has been happening from when we first started designing this project. A few months ago I had it over at his house and it was doing things like this but we were thinking it was his tv/old monitor we were using, or a cable problem.
Still at a loose of how it can not work for the first few minutes, then all of a sudden, with no outside interference, take off and start working on its own. The worst kind of problems to track down are ones like this where you hardly know what the problem is, let alone what is causing it.
EDIT -
Is it possible to send a reset command only to the prop via hyperterminal?· Is there a command that causes the FT232RL to pulse its reset pin?
Post Edited (Joms) : 3/7/2010 11:27:03 PM GMT
-Phil
BUT ...
Are there any button inputs that are waving around at high impedance. All sorts happen, then depending where your hands are ..........
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby: I will keep digging more into a power issue. Perhaps I am getting some type of a small spike from the USB when I first power it up? I have used two machines for testing, but maybe that is just how USB operates?
There are no buttons or input devices except for the LM1881 ic's. I am using the USB/Serial connection for all the data going into the prop.
-Phil
I don't think I am terminating the input as I am relying on the output to be terminated...
I will try the circuit with four video inputs and look at the four outputs and see how it reacts.· I will keep you updated....· Thanks!
Do you have a scope? If so, what kind of waveforms, if any, do you see on the CSync lines? Here's an experiment to try: in your top-level program, before you do anything else, set your CSync inputs to outputs via DIRA. Does the problem go away?
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Also, Because of the point Peter brought up, do you think that might be linked to having too small of resistors? I will start changing the programing and the resistor size right now and let you know what I come up with....
-Phil
My advice, always use 100K if it's an input only or at least 10K.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
I also set the pins to the proper in out, (ie. Pin1 - In, Pin2 - Out, Pin11-In). Still same problem...
-Phil
Are you using TV and GRAPHICS? Do these each require their own cogs?
I have seen different behavior from different methods of booting before but not like that.
It was because of a loop that started too many cogs to do the same thing, unintentionally.
Its amazing that that program usually worked "right" when it did that.
I have no clue why where it booted from mattered.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.
Coming soon. My open Propeller Project Pages and favorite links index.
He's got 4 instances of the overlay operating together. Given the rest of the project can fit nicely into the RAM, it's likely not worth the effort to modify the overlay code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I found my video DA and hooked the same video input to all four inputs, and the problem is still there. Is this a valid test because all the video is locked to the same sync because of the DA?
I was reading a few other posts and ran across someone else having a different problem, but wondering if it could be something here... I am searching my entire code, but wondering if I refered to the counter anywhere that I shouldn't have. Im guessing that would cause this problem, but don't see anyplace I made that mistake...
Try bypassing that transistor/capacitor that is driving the res line and push the res line directly from your rts line through a resistor similar to the tx/rx lines.
(this is the one thing in your circuit that made me uneasy.)
I run a ft2232 ftdi chip that pushes the reset line directly from the rts line.
But my ftdi chip is powered by 3.3v
I don't see why you couldn't do the same thing your doing with the tx/rx lines as with the res line, at least to help remove any possible sources of issues. Bad connections etc. Check that crystal connection also, if you have no crystal connected at all, the prop will still take a program and allow you to program the eeprom. I had a crystal with a bad connected leg, which caused all kinds of funny situations. If using a breadboard MAKE SURE to put a thin coat of fresh solder on every pin of every device you are inserting into the breadboard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-MH
Now, if the above is wrong forget this post.
Otherwise I will try this: 1) apply a bistable switch or jumper to the reset line (to gnd); 2) program the eprom; 3) assert reset; 4) power cycle the board; 5) after ~10 seconds deassert reset
If it works repeat some more times from point 3. If always work then Heater is right about the brownout detector. If the power rail rises to slow sometimes also brownout detectors fail. Perhaps an RC reset delay can help
This consideration came fron this thoughts:
- cannot be current consumption: program running from download or after eeprom boot will use same power
- if sometimes work but most of the times no: this anyway proove that eeprom has been programmed correctly
- from software point of view there is no difference between a power cycle or a reset cycle; from hw POW with a reset you do not need to charge capacitors, voltage level is already stabilized
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search