Shop OBEX P1 Docs P2 Docs Learn Events
New to Propeller, did I damage my P8X32A? — Parallax Forums

New to Propeller, did I damage my P8X32A?

JBlahutJBlahut Posts: 5
edited 2014-07-01 23:56 in Propeller 1
Hi guys,
I've been playing with a propeller P8X32A (the quickstart board you can pick up at Radio Shack) for about a week now, but this morning I fear I damaged my board somehow. I can load up Prop Tool\Examples\Help\Spin Tutorial\Exercise02-1\Output.spin and the expected LED blinks as it should. If I load up Prop Tool\library\_demos\FullDuplexSerial_Test1.spin I'm no longer receiving the expected text over the USB serial connection (I was last night). And if I load up the project I've been working on (described below) I no longer get serial data output on outa[0] (which is labeled pin 1 on this board) or when I've tried swapping it over to outa[1].

I'm building a score board style display by having the propeller send serial data to RGB LED strips configured into 7-segment displays. The LED strips are connected to a 12v wall-wart power supply and the propeller is drawing power over USB from my computer. I've joined the ground from the wall-wart to pin 39 on the propeller's board to provide a common ground. It's not unusual for me to disconnect the power from the LEDs when I'm not testing them (because they're sitting on my desk and it's rather distracting).

My project and all of the examples/demos that I've mentioned run fine in their current state on a different P8X32A board.
How can I further diagnose the problem? Is there an obvious mistake I've made somewhere in connecting a common ground? What could cause the board to fail the full-duplex serial program and my program, but work fine with another simpler program?

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2014-07-01 15:34
    One of the easiest things to damage on the Prop is the PLL circuit. When this doesn't work, serial communication is problematic since the baud isn't correct. The Prop is basically running at RC_FAST without the PLL.

    If this happened to my board, I'd replace the chip.
  • JBlahutJBlahut Posts: 5
    edited 2014-07-01 15:37
    Here's a quick program based on one of the spin tutorial programs (chosen at random) that runs fine -- I get the expected serial output and the LEDs blink as expected. I have no idea why serial output would function in this test program, but fail in my program and both of the full-duplex serial test programs. It's worth noting that this program runs fine even while the board is wired up to my LEDs (to me, this suggests a short or other wiring fault is unlikely).
    {{Output.spin

    Toggles two pins, one after another.}}

    obj
    serial : "FullDuplexSerial"

    PUB Main
    serial.Start(31, 30, 00, 9_600)
    waitcnt(cnt + 10_000)

    dira[17] := 1

    'write some serial startup text
    serial.Dec(0)
    serial.Str(STRING(" Startup."))
    serial.Tx($0D) 'new line

    repeat
    Toggle(16, 3_000_000, 10) 'Toggle P16 ten times, 1/4 s each
    Toggle(17, 2_000_000, 20) 'Toggle P17 twenty times, 1/6 s each
    serial.Str(STRING("Loop."))
    serial.Tx($0D) 'new line


    PUB Toggle(Pin, Delay, Count)
    {{Toggle Pin, Count times with Delay clock cycles in between.}}

    dira[Pin]~~ 'Set I/O pin to output direction
    repeat Count 'Repeat for Count iterations
    !outa[Pin] ' Toggle I/O Pin
    waitcnt(Delay + cnt) ' Wait for Delay cycles
  • PublisonPublison Posts: 12,366
    edited 2014-07-01 15:55
    JBlahut wrote: »
    Here's a quick program based on one of the spin tutorial programs (chosen at random) that runs fine -- I get the expected serial output and the LEDs blink as expected. I have no idea why serial output would function in this test program, but fail in my program and both of the full-duplex serial test programs. It's worth noting that this program runs fine even while the board is wired up to my LEDs (to me, this suggests a short or other wiring fault is unlikely).

    Do you have this block in your code?
    CON _clkmode = xtal1 + pll16x
    _clkfreq = 80_000_000

    or
    CON _clkmode = xtal1 + pll16x
    _xinfreq = 5_000_000 'Set to standard clock mode and frequency (80 MHz)


    With out that in the CON section Serial I/O does not work because of the timing required.
  • JBlahutJBlahut Posts: 5
    edited 2014-07-01 16:10
    Duane, thanks for the speedy reply! I suspect you're right. I changed the clkmode in the test program from my previous post and it failed. Sounds like I need to clean up the power from the wall wart with a filter. I did a quick search for PLL protection and didn't see anyone mention specifically having problems with the USB connection on this board. The schematic shows some caps to filter along side the regulator, am I right to think that's enough for the USB power source?
  • JBlahutJBlahut Posts: 5
    edited 2014-07-01 16:13
    Publison, the test code in my second post seems to run just fine (and properly outputs serial data over the USB connection) without any adjustments to the clkmode. As I just mentioned to Duane, adding in some code to adjust the clkmode causes that program to fail.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-07-01 17:30
    I don't think a filter will help, it has to do with the grounds and if the ground current of the load is flowing through the Prop pins then it's a big problem. A photo or two will certainly help in this regards. The main thing is to make sure that the ground from the wallwart is connected at the load and then a ground from there goes back to the Prop so that at no time does the ground current for the display flow through the Prop board, just the signal current. So the signal ground from the display/wallwart should be connected to the ground on the Prop that's closest to the Prop's regulator ground. This should not really be a problem on a well laid out PCB but who knows.

    Another thing to watch out for is mains leakage current if it happens to be a switching wallwart since these PSUs have a small cap from the neutral to the output ground that's responsible for that little bite these PSUs can give you. If you plug in a USB serial into your PC which is earthed somewhere then ground current will flow through the Prop. This also is bad bad bad. Either find a different wallwart that has an earth or don't have an earth anywhere in your circuit or externally.

    BTW, once the PLL is damaged, it's damaged, the safeguards mentioned are to prevent this happening,
  • JBlahutJBlahut Posts: 5
    edited 2014-07-01 19:11
    Peter, I hadn't thought of that at all: I'm essentially connecting a 2 prong wall wart with the 3 prong switching power supply in my PC (through the USB connection). You're right, no amount of filtering the wall wart will keep the two grounds similar.

    So I'm looking at two options now: I can isolate the LED circuit entirely by putting an opto-isolator between the prop's serial data output and the LED strip's data input and then abandon the shared ground connection entirely. Or I can abandon the wall wart and run the LEDs off the PC's power supply (which should provide a common ground to both the LEDs and the prop). Are there any pitfalls in these solutions that I'm missing?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-07-01 19:32
    JBlahut wrote: »
    Peter, I hadn't thought of that at all: I'm essentially connecting a 2 prong wall wart with the 3 prong switching power supply in my PC (through the USB connection). You're right, no amount of filtering the wall wart will keep the two grounds similar.

    So I'm looking at two options now: I can isolate the LED circuit entirely by putting an opto-isolator between the prop's serial data output and the LED strip's data input and then abandon the shared ground connection entirely. Or I can abandon the wall wart and run the LEDs off the PC's power supply (which should provide a common ground to both the LEDs and the prop). Are there any pitfalls in these solutions that I'm missing?

    Since it is single wire 9600 baud serial you can just use a simple opto-isolator as that is your best bet. The Prop TXD connects to the cathode and you should have a 150R or so in there to limit the drive current and have the output wired with a pullup on the collector of around 3K3 (depends on opto). You still need to replace the Prop though.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-07-01 23:56
    When just starting out, there is a tendency to jump to the conclusion that you have damaged the Propeller physically... when the reality is that either your code, your computer configuration, or your power supply are not correct.

    It seems that the source of your problem this time around was code. Changing from the default settings can shut out serial communications.

    You can just provide power from a 7.2V Lithium cell power place to eliminate concerns about AC mains.
    I find it more pleasant to use a battery pack and not have power wires running off to an AC socket. Too many wires going everywhere tend to snag on things unexpectedly.

    When in doubt, consider all three.

    A. Code configuration
    B. Power Source
    C. IDE installation
Sign In or Register to comment.