Shop OBEX P1 Docs P2 Docs Learn Events
Need Some Help — Parallax Forums

Need Some Help

GeofPriceGeofPrice Posts: 16
edited 2013-02-06 03:12 in Propeller 1
Hi All:

I am new to developing stuff with propeller chips, but I'm on my second project now. This application I'm having trouble with reads inputs from a Linx Technologies wireless decoder controller which is controlled by a 5 button key fob. Either of two keys on the key fob turns on/off the receiver/decoder and toggles P24 and P25 on a Propstick. P0 on the Propstick outputs to a Pololu 18v7 motor controller, and the motor controller runs a relatively small motor. Also, a set of 4 dip switches can be used to adjust on/off period for the motor. The wireless is intended to kill all juice to the motor.Schematic is attached.

I developed a Spin program that works perfectly. It reads the four dip switches, sets the on/off times, toggles the motor correctly, and the key fob kills/restores all power on command. So after all the debugging is done and I am satisfied with the program. I upload the program to EEPROM. Now, as long as the USB is connected to the external computer, everything woks perfectly. I can power down with the main power switch (USB power is still applied through the computer), and power back up and the EEPROM program loads and life is great. Then I turn everything off, disconnect the USB, and turn it back on. Now, nothing works. The motor comes up with about 20% power when it should be 100%. I don't have a scope, but I suspect that P0 is oscillating rapidly, because when I try to read the voltage P0 is putting out with a voltmeter, the motor kills while P0 reads about 0.35v. Also, even though the decoder will toggle P24 and P25 just fine, there is no response that makes it through to P0 via the program. The 4 dip switches also have no effect on P0 through the program. However, even in this strange state, if I plug back in the USB, everything comes back to normal, and everything works again, even without rebooting the propeller.

Can anyone tell me what might be going on here? Why would the USB need to be connected to the Propstick for this to work? I can upload the program if someone wants to see it, but this seems to be a hardware problem to me.
RoboDuck.jpg
800 x 948 - 82K

Comments

  • kwinnkwinn Posts: 8,697
    edited 2013-02-05 17:35
    Try reloading the program to eeprom.

    Other possibilities are that the program is expecting some input from the prop plug or is being reset by the /res line.
  • GeofPriceGeofPrice Posts: 16
    edited 2013-02-05 17:39
    But I can plug/unplug the USB and without reloading any program, the project works when plugged in to the USB (even "comes back to life" if it has been unplugged form the USB) and doesn't work when not plugged in to the USB.
  • kwinnkwinn Posts: 8,697
    edited 2013-02-05 18:01
    Yes, this is why I think it is related to one of the 3 lines going from the prop plug to the prop. Actually that is 5 inputs. What voltage do you have going to Vin when the USB is not connected. It should be 5 to 9 VDC.
  • SRLMSRLM Posts: 5,045
    edited 2013-02-05 18:02
    I think kwinn may be alluding to the FTDI reset bug (link). You can see if this is the case by having it turn on a light for 1 second at the beginning of the program, and see if the light stays on or flashes when not plugged in (which would indicate constant resets).
  • GeofPriceGeofPrice Posts: 16
    edited 2013-02-05 18:03
    Can you expand on that thought a bit? Having what "turn on a light for 1 second"? Which output? The link you gave mostly discusses the propeller chip with the removable USB. The Propstick has all the USB circuitry, EEPROM, crystal, propeller chip, ect. built on a single 40-pin mini board. I can't add circuitry between the chip and USB lines.

    The Pololu motor controller has a 5v regulated supply that provides power to the Propstick.
  • kwinnkwinn Posts: 8,697
    edited 2013-02-05 18:27
    GeofPrice wrote: »
    ......

    The Pololu motor controller has a 5v regulated supply that provides power to the Propstick.

    This may also be a cause for the problem. When a motor starts it draws a heavy current which may cause a reset. Can you post a schematic for the controller?
  • TtailspinTtailspin Posts: 1,326
    edited 2013-02-05 18:32
    So after all the debugging is done and I am satisfied with the program. I upload the program to EEPROM.
    Did you eliminate all calls to the parallax serial terminal communications?
  • GeofPriceGeofPrice Posts: 16
    edited 2013-02-05 18:38
    I don't think they publish a schematic for the motor controller. The manual is here:

    http://www.pololu.com/docs/0J44/all

    T
    he program does have serial communications. I will eliminate those and see.
  • kwinnkwinn Posts: 8,697
    edited 2013-02-05 18:55
    This portion of section 3.5 outlines what I am thinking may be the problem. Check it out. An alternative may be to provide an external +5V to Vin and see if the problem goes away.

    "Yellow Status LED
    This LED helps you visually identify the state of the device, which can be useful when the controller is not connected to the Control Center. On start-up, the status LED briefly flashes a pattern indicating the source of the last reset (see the Reset Flags variable in Section 6.4 for more information):

    8 blinks over the first two seconds after start-up indicates that the external RST pin was driven low to reset the controller.
    3 blinks over the first two seconds after start-up indicates that the controller last reset because logic power got too low (power was disconnected or the controller browned out).
    Rapid flickering for the first two seconds after start-up indicates that the controller was reset by a software fault or by a firmware upgrade.
    This startup behavior can help you detect if your Simple Motor Controller is browning out and resetting unexpectedly (as can happen if your input voltage drops due to high power demands or electrical noise)."
  • GeofPriceGeofPrice Posts: 16
    edited 2013-02-05 19:10
    Eliminating serial communications has solved the problem. I am still going to be looking into this further so I can make sure it doesn't;t stump me again. Thanks for your help.
  • TtailspinTtailspin Posts: 1,326
    edited 2013-02-05 19:26
    The propeller was waiting for your computer to respond, and it never will without the cable... :)
  • GeofPriceGeofPrice Posts: 16
    edited 2013-02-05 19:30
    No, it was a one-way communication. I'm betting on the serial reset problem causing the effects.
  • SRLMSRLM Posts: 5,045
    edited 2013-02-05 19:38
    Glad you found the problem. You can probably fix it in hardware if you add pullups to P30. I'd start with around 3KOhm pullups. You don't need to modify the USB circuit: you have a pin on the PropStick for P30.

    Just for completeness, the LED that I mentioned was meant to aid in debugging the problem. Any old LED would work, and if you connect it to an unused propeller pin you can use the following code at the beginning of you program:
    DIRA[LEDpin]~~
    OUTA[LEDpin]~~
    waitcnt(CLKFREQ + CNT)
    OUTA[LEDpin]~
    
    Correctly functioning code will have the LED turn on once, and then remain off. With the bug that you encountered the LED would flash or remain on.
  • Duane C. JohnsonDuane C. Johnson Posts: 955
    edited 2013-02-06 03:12
    To expand:
    GeofPrice wrote: »
    Can you expand on that thought a bit? Having what "turn on a light for 1 second"? Which output? The link you gave mostly discusses the propeller chip with the removable USB. The Propstick has all the USB circuitry, EEPROM, crystal, propeller chip, ect. built on a single 40-pin mini board. I can't add circuitry between the chip and USB lines.
    The test is to choose any unused prop pin:

    1. Connect an LED with a series current limit resister from Pin to Gnd.
    2. Add some code to your program to continuously output a high to this pin to light up the LED.
    3. See if it is lit steadily or not.

    When the Prop is reset the pins all go to input mode so the LED will go out.

    Duane J
Sign In or Register to comment.