Propeller accepts program but will not run

Jon Keinath

I have been working on a propeller based program and all of a sudden the propeller will no longer run the program after the new program is installed. Here is what I have tried.
1] Verify power good.
2] Reset board.
3] Download simple "blink led" program. (Suspect board downloads and verifies to both RAM and EEPROM)
4] Use RCFAST, RCSLOW, and Crystal w/ & w/o PLL.
5] Verified simple "blink led" program runs on different propeller [propeller development board]. (It does in all modes above)

The suspect propeller is on a board that I designed and populated myself, based on diagrams available, and uses the propeller plug for its programming interface. It has been running off and on for a many months without issue. I don't know exactly, but the issues seemed to start at some point yesterday after I removed the prop plug it no longer ran.

Is there anything else I can try to get this prop spinning again, short of trying to replace the surface mount prop, through hole crystal, or both? (or populate a new board?)

Thanks!

mindrobots

Steps 1-4 above all are performed on the board you designed using the same Prop Plug? But you have a particular program that doesn't run on it? I assume that your custom board has special hardware that you can't just run the failing program on your PPDB, for example.

It sounds like all your hardware pieces are working. If you suspect the board still after running the tests you have run, please explain more, I may be missing something. #3 and #4 indicate the hardware is ok, so I suspect the program that is failing.

What was the last thing you changed in the program that won't run? Did you add code to use a hardware component you hadn't used before? Did you add software that might use more COGs? Could be a power issue.

Added code to a started COG that causes a stack issue? If you have room, make your stacks larger.

It always helps to post the code, post pictures, post schematics. The more info, the easier to help.

Phil Pilgrim (PhiPi)

You didn't say anything about an EEPROM. Can we assume the board has one and that you loaded your program into it? Can you post a schematic and a photo of your board?

-Phil

Jon Keinath

Yes, items 1-4 were all performed on the custom board with the same prop plug. None of them generated a successful operation. It just accepts the program and does nothing. The custom board has pins 19 to 25 available to a header where I wired in an LED w/resistor. (I used this pin and LED in the program I am working on as an indicator so I know it was working). Yes, the board has an EEPROM. I'll make some more information available shortly, I just wanted to get the clarification of your questions available to others.

Here is the simple code for testing:

CON

  _clkmode = RCFAST 
  '_xinfreq = 5_000_000

PUB LedOnOff                        ' Method declaration 
                       
    dira[20] := 1                   ' Set P16 to output

    repeat                          ' Endless loop prevents
                                     ' program from ending.
     
        outa[20] := 1               ' Set P16 high 
        waitcnt(clkfreq/4 + cnt)    ' Wait a moment
        outa[20] := 0               ' Set P16 low
        waitcnt(clkfreq/4 + cnt)    ' Wait a moment

mindrobots

Thanks, that helps! I totally misread and misunderstood #1 through #4. (coffee deficit)

Is there any reason you are actually working with PIN 20 in your code and referring to it as P16 in your comments?

Is the LED on P20 or P16? If it is really on P16, you of course won't see it blink when you toggle P20 in the code.

Jon Keinath

I have attached PDFs of the Schematic, and PCB. I've also added some pictures.

PCB_Bottom.pdf
PCB_Top.pdf
Schematic.pdf

The only reason for the pin comment mismatch is because I copied the code from here: http://www.parallaxsemiconductor.com/quickstart2 and changed the pins, but not the comments.

mindrobots

Jon Keinath wrote: »

The only reason for the pin comment mismatch is because I copied the code from here: http://www.parallaxsemiconductor.com/quickstart2 and changed the pins, but not the comments.

Fair enough! I was just eliminating the kinds of mistakes I make!!

Could you have cracked a solder joint or something around the PropPlug pins when you removed it last time?

Nice looking board! It's always good to see Propellers in commercial applications!

Jon Keinath

I checked the traces from the header to the prop plug with a multi-meter and they all appear good. The propeller tool identifies and successfully downloads to the propeller (RAM & EEPROM). Could I have damaged say RESn if I unplugged the prop plug while the board was powered and USB were connected? Could RESn be failed and still allow the prop to be programmed but hold it in reset?

Mike Green

There is a failure mode that occurs when the Propeller isn't bypassed properly or if some of the power pins are not connected. Voltage transients occur on the chip and damage the clock multiplexor. The main symptom is that the chip will download a program from a PC or EEPROM, but the program won't execute unless it uses one of the built-in RC clocks sources (RCSLOW or RCFAST). None of the crystal-based clock settings will work. The bootloader works because it uses RCFAST.

Jon Keinath

Some additional testing. RESn reads 3.3v with the prop-plug installed, or disconnected when the propeller should be running. I thought I would try measuring the output of two spare pins (just go to an empty header). I modified the program as follows, and measured the voltage. It stayed at 0v.

CON

_clkmode = RCFAST 

PUB LedOnOff                        
                       
    dira[20] := 1                   
    dira[27] := 1
    dira[26] := 1
    outa[27] := 1
    outa[26] := 1
    repeat                         
      outa[20] := 1                
      waitcnt(clkfreq/4 + cnt)        
      outa[20] := 0               
      waitcnt(clkfreq/4 + cnt)

ChrisGadd

First and (so far) only time I fried a Prop caused the same thing; the Prop appeared to accept the program but failed to produce any activity on the IO pins. In my case it was a boneheaded miswiring of the 3.3V and 5V supplies.

Phil Pilgrim (PhiPi)

This is a stretch, but I only mention it because it's happened to me -- more than once. Sometimes I'll have another Prop board connected to USB but buried in the strata on my bench. So I'll load a program into what I think is the target system, only to have it not run. That's because it got loaded into the board I'd forgotten was still connected.

-Phil

Duane Degn

It looks like the vias from the top ground connections don't connect with the copper pour on the bottom of the board.

Is this a problem or am I reading something wrong?

From my reading of the copper layers, it looks like several all of the ground pins are not connected to ground.

Jon Keinath

You found my board error... I soldered some jumpers to those points when I received the boards. They have been there since the beginning. I didn't want to scrap the prototype board for just that one issue. I might try redoing those to see if it makes a difference.