Shop OBEX P1 Docs P2 Docs Learn Events
Propeller loads off the EEPROM, but won't run code — Parallax Forums

Propeller loads off the EEPROM, but won't run code

brendankmbrendankm Posts: 14
edited 2013-07-26 00:51 in Propeller 1
Hi,


First off, I'm semi-novice with the Prop. I've been putting in about 20 hours a week working with them over the past month, so I'm starting to get the hang of it.

Here is my problem: I wired up a brand new Prop on a previously-working breadboard (with another prop that I put into another project.) I had also replaced the EEPROM (again, the old one was put into another project). I plugged in my PropPlug, and Spin recognized it fine. I compiled and deployed my code onto the EEPROM, and it went with no problem, passed the verification too. However, upon reset it does nothing. I powered off and swapped the Prop with another new one I had just ordered, and it work fine. So I swapped back, this time I checked the EEPROM pins with a multimeter, and the Prop is definitely reading from the pins. The Prop is also still able to download code from Spin to RAM and the EEPROM via my PropPlug. It just seems like it can't run code.....Maybe there is something wrong with the Spin Interpreter?

Thanks,
~Brendankm

Comments

  • Patrick1abPatrick1ab Posts: 136
    edited 2010-10-02 10:06
    Have you tried loading your program directly into the RAM?
    If this doesn't work, I would check the chrystal (if you are using one)... although it is strange, that it works with another prop?!?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-10-02 11:39
    It could be that the non-working Prop can't run at the speed you've specified. (When loading and verifying EEPROM, it's running on the internal RC clock.) This can happen if you either haven't connected all the Vdd/Vss pins or have inadequate bypassing at the Vdd/Vss connections. Some Props may appear ot work under these conditions, even though they're on the hairy edge. In the worst cases, the Prop's PLL circuitry can become damaged by inadequate power supply connections.

    So tell us more about this breadboard of yours. How is it powered? Can you show us a photo? A schematic?

    -Phil
  • brendankmbrendankm Posts: 14
    edited 2010-10-02 11:51
    Phil Pilgrim (PhiPi) wrote: »
    It could be that the non-working Prop can't run at the speed you've specified. (When loading and verifying EEPROM, it's running on the internal RC clock.) This can happen if you either haven't connected all the Vdd/Vss pins or have inadequate bypassing at the Vdd/Vss connections. Some Props may appear ot work under these conditions, even though they're on the hairy edge. In the worst cases, the Prop's PLL circuitry can become damaged by inadequate power supply connections.

    So tell us more about this breadboard of yours. How is it powered? Can you show us a photo? A schematic?

    -Phil

    WOW! It works!!!! I actually didn't have one of the Vdd Pins connected, thinking it wasn't necessary....I connected it and still nothing. So I checked the clock on another project and the clock worked fine. Then I took out the 
      _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000

    and it worked. Then I added
      _clkmode      = xtal1 + pll8x
  _xinfreq      = 5_000_000

    And now it seems to be working well! Thanks!!
  • brendankmbrendankm Posts: 14
    edited 2010-10-02 12:04
    Hmm, well I thought my problem was solved, but now it seems to be running incredibly slow......

    A Simple 
    repeat
    !outa[14]
    blinks about twice per second.....
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-10-02 12:45
    Please post your entire slow-blinky program.

    -Phil
  • brendankmbrendankm Posts: 14
    edited 2010-10-02 12:46
    Phil Pilgrim (PhiPi) wrote: »
    Please post your entire slow-blinky program.

    -Phil

    Sorry...
    CON                       
  _clkmode      = xtal1 + pll8x
  _xinfreq      = 5_000_000   
PUB On
  dira[15]~~
  outa[15]:=1
  repeat 
    !outa[15]


    EDIT: Wrong one...fixed
  • Mike GreenMike Green Posts: 23,101
    edited 2010-10-02 13:19
    This is not a slow blinky program. The REPEAT statement is running full out in Spin, probably on the order of 1MHz. Try putting a delay in the REPEAT statement like:

    WAITCNT(CLKFREQ + CNT).

    This will add a 1 second delay so the LED should go on for 1 second, then go off for 1 second. Once you've verified that, you can reduce the delay by dividing the CLKFREQ by some constant. For example, CLKFREQ/4 would cause the LED to blink 2 times a second
  • brendankmbrendankm Posts: 14
    edited 2010-10-02 13:23
    Mike Green wrote: »
    This is not a slow blinky program. The REPEAT statement is running full out in Spin, probably on the order of 1MHz. Try putting a delay in the REPEAT statement like:

    WAITCNT(CLKFREQ + CNT).

    This will add a 1 second delay so the LED should go on for 1 second, then go off for 1 second. Once you've verified that, you can reduce the delay by dividing the CLKFREQ by some constant. For example, CLKFREQ/4 would cause the LED to blink 2 times a second

    No, its not supposed to be a slow blinking program....you missed the point...

    That program is causing the LED to blink at about 2 times per second, it should be blinking significantly faster. When the pll is removed, it goes to that significant speed, but i can't rely on the internal clock because I am using it to send IR Pulses..
  • Mike GreenMike Green Posts: 23,101
    edited 2010-10-02 13:34
    The program you posted will not blink the LED 2 times a second. If you're seeing a 2 times a second blink, then you're either running a different program or you're seeing some artifact (I'm not sure what).

    The program you posted uses an external crystal (5MHz) and uses the PLL to multiply that x8 which gives a system clock speed of 40MHz. At that speed, most Spin byte codes execute in a few microseconds and execution speed should be perfectly fine for IR communications. The built-in cog counters could be used to produce a high speed carrier with crystal accuracy.

    If you were running off the internal default clock, that would be around 12MHz and you'd still have a blink time on the order of tens of microseconds.
  • brendankmbrendankm Posts: 14
    edited 2010-10-02 13:46
    Mike Green wrote: »
    The program you posted will not blink the LED 2 times a second. If you're seeing a 2 times a second blink, then you're either running a different program or you're seeing some artifact (I'm not sure what).

    The program you posted uses an external crystal (5MHz) and uses the PLL to multiply that x8 which gives a system clock speed of 40MHz. At that speed, most Spin byte codes execute in a few microseconds and execution speed should be perfectly fine for IR communications. The built-in cog counters could be used to produce a high speed carrier with crystal accuracy.

    If you were running off the internal default clock, that would be around 12MHz and you'd still have a blink time on the order of tens of microseconds.

    Right, I am 100% fully aware of everything you said....I'm not that novice.....

    Yes, the program I posted does infact blink at twice per second, and with using a pll16x, it does nothing at all.

    I am fairly sure there is something wrong with the external clock part of my Propeller. And I know that the internal clock is 12MHz, but that also has an error of +-60% I don't want to risk that.....

    As I said before, removing the PLL it works fine, but I do not want to rely on the inconsistant internal clock.


    I'm not as novice as you might think.....
  • RaymanRayman Posts: 14,662
    edited 2010-10-02 13:49
    I'd try another prop chip...

    The PLL is often the first thing to fail...
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-10-02 14:01
    There's got to be something else going on. My bet is that when the LED is blinking it just looks like it's on because the rate is so fast and that your Prop is getting reset periodically, which causes the LED to turn off for a half second. Are you using a USB connection to your PC and is it plugged when you observe the slow blink?

    -Phil
  • brendankmbrendankm Posts: 14
    edited 2010-10-03 07:34
    Phil Pilgrim (PhiPi) wrote: »
    There's got to be something else going on. My bet is that when the LED is blinking it just looks like it's on because the rate is so fast and that your Prop is getting reset periodically, which causes the LED to turn off for a half second. Are you using a USB connection to your PC and is it plugged when you observe the slow blink?

    -Phil

    I unplugged the USB Connection-I thought that that may have been the problem-it wasn't. I checked the output with a multimeter, it is a steady 3.28 when its on, and not an average as if it were blinking (tested the average thing on another prop)

    I think it is a pll problem....are there any other ways to get a fast accurate clock?
  • obrienmobrienm Posts: 65
    edited 2010-10-03 07:34
    A long shot but I saw the same slowdown on a propeller once....
    Verify that your crystal is not being grounded. I was inadvertently grounding my crystal on one of the ground pins connected to the propeller on the breadboard. In my case however, I was still running at the default RCSLOW of 12kHz.
    It may be as referenced earlier - a constant reset occurring only in the case where (you do not have your usb clip connected and you are sending comms back the pc).

    thank you
    /michael
  • JonnyMacJonnyMac Posts: 9,107
    edited 2010-10-03 07:49
    I'm with Michael -- saw this once on a board we (EFX-TEK) made. Some water (from washing the board) got trapped under the crystal. The code would download and checkout fine as this happens using the internal RC clock. As soon as we tried to run the code.... nada.

    I desoldered/resoldered the crystal and bang, came right back to life.
  • brendankmbrendankm Posts: 14
    edited 2010-10-03 07:58
    putting the bad prop on a known working board produces the same slow result....
  • Mike GreenMike Green Posts: 23,101
    edited 2010-10-03 08:17
    The "PLL destroyed" problem alluded to is that, when the Propeller chip is subjected to power supply noise such that the voltage exceeds the "Absolute Maximum Voltage", the system clock PLL is usually the first structure to fail. The result is that the chip will identify itself and download programs because those us the fast internal clock, but the external clock settings won't work and the processor doesn't get a clock signal when it switches out of the internal clock mode after downloading or loading a program from EEPROM.
  • brendankmbrendankm Posts: 14
    edited 2010-10-03 08:57
    Mike Green wrote: »
    The "PLL destroyed" problem alluded to is that, when the Propeller chip is subjected to power supply noise such that the voltage exceeds the "Absolute Maximum Voltage", the system clock PLL is usually the first structure to fail. The result is that the chip will identify itself and download programs because those us the fast internal clock, but the external clock settings won't work and the processor doesn't get a clock signal when it switches out of the internal clock mode after downloading or loading a program from EEPROM.

    So is there a work around? Or am I stuck using the (inaccurate?) internal clock?
  • Mike GreenMike Green Posts: 23,101
    edited 2010-10-03 09:10
    The only workaround is to use an external clock oscillator without the PLL (XINPUT). There's no multiplication of the crystal frequency possible.

    Do try JonnyMac's suggestion. The PLL damage normally prevents the Propeller chip from doing anything when switched to PLL clock modes and that's not how your chip is behaving.
  • brendankmbrendankm Posts: 14
    edited 2010-10-03 10:20
    I tried JonnyMac's...nada, using the XINPUT seems to be working, however, now my timings seem to be off for the IR comm. Every timing returns a result of 3 ms on the receiving end
  • Mike GreenMike Green Posts: 23,101
    edited 2010-10-03 10:30
    Can't give you more specific advice without more information about your setup and your program. Please use the attachment feature of the forum (the paperclip icon) to attach the source of your program and a schematic diagram.
  • brendankmbrendankm Posts: 14
    edited 2010-10-03 10:57
    Mike Green wrote: »
    Can't give you more specific advice without more information about your setup and your program. Please use the attachment feature of the forum (the paperclip icon) to attach the source of your program and a schematic diagram.

    Attached are the two different programs. Both propellers have Identical clock, power schematics, EEPROMs ect. SendIRSignal is the one with the bad prop. The IR Emitter is driven off a transistor, with 100 Ohms in between the transistor and Prop.


    EDIT:
    ignore some comments in the code, it has been changed so many times, a lot of the comments don't mean anything anymore
    spin
    spin
    RecieveIRSignal.spin
    1K
    spin
    spin
    SendIRSignal.spin
    3K
  • RavenkallenRavenkallen Posts: 1,057
    edited 2010-10-03 16:45
    Could you try using a different Prop, but use the same crystal?
  • brendankmbrendankm Posts: 14
    edited 2010-10-03 17:39
    Ravenkallen wrote: »
    Could you try using a different Prop, but use the same crystal?

    I can put in another prop, but then I can only test one and of the IR Comm, because I only have two Props ATM (one for IR Sender, one for IR Receiver)
  • Mike GreenMike Green Posts: 23,101
    edited 2010-10-03 17:54
    _xinput = 5_000_000

    This is wrong. Please read the Propeller Manual for examples of what's allowed.
    This would cause the system clock to default to RCFAST

    If you're using an external clock source of 5MHz, you'd use

    _clkmode = xinput ' direct input to XI from an external clock
    _clkfreq = 5_000_000 ' for a 5MHz external clock
  • brendankmbrendankm Posts: 14
    edited 2010-10-03 18:12
    Mike Green wrote: »
    _xinput = 5_000_000

    This is wrong. Please read the Propeller Manual for examples of what's allowed.
    This would cause the system clock to default to RCFAST

    If you're using an external clock source of 5MHz, you'd use

    _clkmode = xinput ' direct input to XI from an external clock
    _clkfreq = 5_000_000 ' for a 5MHz external clock

    Thanks,
    I added 
      _clkmode = xinput ' direct input to XI from an external clock
  _clkfreq = 5_000_000 ' for a 5MHz external clock
    and took out the old incorrect definitions, however it produces no response from the Prop.....

    So far, the only way I've been able to get anything semi-useful out of the prop is by using the internal clock......
  • Mike GreenMike Green Posts: 23,101
    edited 2010-10-03 18:48
    _clkmode = xinput

    This only works when you connect an external clock signal to XIN. It doesn't provide an oscillator for just an external crystal. You could use an I/O pin of one Propeller to provide the clock for another for test purposes. There's an object in the object exchange to provide a pulse stream over a wide range of frequencies and you could use that to provide your external clock.
  • RavenkallenRavenkallen Posts: 1,057
    edited 2010-10-03 18:51
    What do you mean by no response? Do you mean that it has stopped functioning entirely?
    If you only have two props and you suspect one is damaged, the easiest thing to do would be to test another, even if it means you can't test out your complete system. This problem with the chip takes priority, because if you can't get one chip functioning correctly in experimental programs, then it surely will not work in the larger system. We are doing our best to help..
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-07-26 00:51
    Thankyou for this thread!

    Having designed many propeller boards, I thought I was going mad when I had a propeller that would download but not run! It was exactly the same fault as post #1 - can download to ram and even eeprom but won't run. Not even a flashing led. Tried swapping all the chips over and it is not the chips - it is the board.

    Thanks to all the clever posts on this thread, there really could be only one component that is the problem and that is the xtal. Checked the PCB and no Vias under the xtal. Unsoldered it and replaced with a new one. Same problem. Unsoldered again and replaced with a new one. Same problem. Unsoldered an xtal off a working board and put it on the new board and it all works.

    Seems I have a bad batch of xtals.

    But it is really the forum that saved the day (and google, which found this thread).

    Thanks again!
Sign In or Register to comment.