Well, thought I'd seen it all...
CannibalRobotics
Posts: 535
in Propeller 1
I have three identical custom prop circuit boards for driving NeoPixel's. I'm using the obex driver (Which needed a few edits to work BTW)
I load the software into circuit boards 1 & 2 and they work perfectly. l load it into circuit board 3 and no output at all on the port or the buffer/driver.
This is where it gets real weird.
I run a simple SPIN repeat loop toggling the port on and off and it works identically on all three boards. So,,, hardware is fine.
Is it possible that a prop can run SPIN but not PASM.
All of the props are brand new.
Before I go to the trouble of replacing and tossing what might be a perfectly good SMD prop.
Any ideas?
I'm completely stumped…
Thanks in advance!
I load the software into circuit boards 1 & 2 and they work perfectly. l load it into circuit board 3 and no output at all on the port or the buffer/driver.
This is where it gets real weird.
I run a simple SPIN repeat loop toggling the port on and off and it works identically on all three boards. So,,, hardware is fine.
Is it possible that a prop can run SPIN but not PASM.
All of the props are brand new.
Before I go to the trouble of replacing and tossing what might be a perfectly good SMD prop.
Any ideas?
I'm completely stumped…
Thanks in advance!
Comments
It would be nice if you mentioned what edits needed to be made so the author could fix the object if needed.
In order to run Spin the Prop has to run the interpreter in PASM. So no, a Prop can't run Spin but not PASM.
There are parts of a Prop which can get burned out while leaving the rest of the chip working. The timing PLL circuit is relatively fragile and can be burned out if current flows across the Propeller.
My guess is you have a bad PLL circuit.
What does this "custom" board look like? does it have bypass caps next to each Vdd/Vss pair?
Any easy way to determine if you have a crystal or PLL problem is to have your code output text at 115200 or some other reasonably fast baud. I once had a device that seemed not to be working. It used a socketed crystal. When the crystal was re-seated it came back to life.
Yes, lots of bypass caps adjacent not only prop but around other logic chips as well.
The clock being an issue did occur to me but I figured if it was running in spin then it had a pulse... the PLL had not occurred to me though. I guess I could test that by using a waitcnt(x) or some variation of FHSA/PHSA commands and see if it stalls out or has weird timing. Seems strange though, built all three boards out of same part stock and tested power prior to putting props on board. Used soft power up on all three too? Built enough of these over years to stear around stressing the electronics in production.
I did notice though that this board was drawing only about 5-8mA where I'm used to seeing them at about 18-22mA for a running processor.
Thanks for suggestion, I'll test it and be back with results.
The problem is simple, the statement starting the NeoPixel code/cog is executed prior to the port definition. He had defaulted the port to 0. The code works fine if you're planning on using port 0 because that's what the 'pin' variable defaults to. The variable initiations just need to be moved to the top of the pub.
Also, there needs to be a "command := 1" in the second repeat routine which generates diagonals so they will actually be written to the NeoPixels.
Otherwise the code works great, one just has to be careful about giving it enough time to send a data burst before updating the LED array in the memory.
Jim-
That was it! Just setting up the PLL in the CON section was enough to kill any program activity. Anybody want a slow slightly used prop?
Duane had asked to see the board, a picture is attached.
I wrote an article in Servo about 5-6 years ago on a PWM robot controller. This board is a variation of the receiver in that article. It originally had 16 servo outputs and 6 PWM inputs. I replaced those with 8 open collector high(er) current outputs and a 4 output 5v buffer/driver for the NeoPixels and other 5v logic systems. It still has a 12 bit A to D and the camera/video switch system (unpopulated in the picture). Still has small foot print and 3.3, 5 & 12VDC regulators. The AD section is designed so that voltage dividers can be installed on all of the inputs. The 'ground' side resistor is actually on the back of the board so you can't see it in this pic. There are also a couple more Bypass caps lurking back there where 3.3v comes 'up' to the prop. It's a remarkably useful little board, about 10 of my clients have them running all sorts of stuff.