Shop OBEX P1 Docs P2 Docs Learn Events
Prop C code doesn't execute — Parallax Forums

Prop C code doesn't execute

deepblueqdeepblueq Posts: 5
edited 2014-06-10 15:05 in Propeller 1
(I'm not sure whether this should be in the PropGCC subforum or not; the problem could be specific to the C dev stack, or something in it could just be bringing a problem elsewhere forward.)

I made a custom board with a Propeller and I'm having some trouble programming it.

Spin with the Propeller Tool seems to work alright (I can activate other functions on the board just fine) but does have an issue with serial transmission back to a terminal. When one character is transmitted, two are received, and while the translation seems to be deterministic, the two received are garbage (e.g. transmitting "K" returns a 7 and an accented y). I'm probably making some stupid mistake here, but if I'm not, then it's relevant to the next bit.

I'd much rather program in C or C++, in no small part because I've already written a lot of relevant Arduino code I can port, so I tried out SimpleIDE (0-9-45). I first tried it on Windows, on the same computer the standard Spin stack seems to work on. The test program given on boot (welcome.c) compiled and loaded fine according to the IDE, but I got nothing back through the terminal at all. I've tried some other functions on the board, and no code seems to be actually executing. I've tried various permutations of LMM/CMM, C/C++, and Os/O2/O1 with no change in behavior. Loads verify to both RAM and EEPROM. Loading to EEPROM and connecting power without the programming interface doesn't change anything.

I loaded SimpleIDE (again 0-9-45) onto my laptop running Linux for another datapoint there. When I first loaded welcome.c from that (build/load/verify again OK), I got an endless stream of garbage back from the Propeller. From the terminal, there appeared to be no order at all to it. Baud rate changes really only affected the rate at which garbage came in (which was much slower than saturation at those rates). The prop plug has an LED in it for serial traffic, and it also looked fairly random, with (transient) frequency components from single-digit Hz up to the limits of vision. That load was only to RAM, so disconnecting power would have killed it anyway. I reprogrammed it from this state to turn on another LED on the board, and all activity stopped. Again from that point and ever since, no code seems to execute from any state, despite everything checking out OK from the IDE's perspective.

Wondering if I killed some HW somewhere along the line, I've tried the Prop Tool again, and it still works as it did before.

Testing has been with either welcome.c or my slightly more in-depth test.c:
#include "simpletools.h"

void main(){
  while(1){
    pause(1000);
    print("Hello world");
    high(20);                 // turn on LEDs
    high(22);
  }
}

Attached are the board schematic and layout. Try not to laugh, it's my first project with a custom board, and was going for compactness to minimize the budget. :innocent: Hacks abound, but I've got excuses for most of them, and it all seems to work with Spin save possibly the uplink to a terminal. The prop plug is the 4 pin header at the bottom. There's a ground plane, just not shown in that view (it's thoroughly verified, both in design and on board).

Board-1.3-Sch.png
Board-1.3-Layout.png


I feel like there's got to be some tiny, stupid mistake around here somewhere, but I'm completely stumped.

Thanks in advance for any help!
892 x 662 - 40K
628 x 642 - 79K

Comments

  • jazzedjazzed Posts: 11,803
    edited 2014-06-10 10:09
    Do you have a known good Propeller Board?
    If so, how does that work compared to your custom board?
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-06-10 10:11
    Are you using a 5MHz crystal? If not, you need to create a custom board configuration file so that the loader does the right thing.
  • ReinhardReinhard Posts: 489
    edited 2014-06-10 10:27
    It's only a guess.
    Can you measure what happends on the Reset - Pin RES/ during program execution.
  • PublisonPublison Posts: 12,366
    edited 2014-06-10 10:30
    As others will probably point out, I do not see any decoupling capacitors on the Propeller chip. There should be four attached to the corresponding VSS and VDD pins.

    Not having the caps sometimes results in the PLL being destroyed. The chip will program, but can not run speed dependent code like FullDuplexSerial,
    which not be the case in your simple code.
  • jazzedjazzed Posts: 11,803
    edited 2014-06-10 11:27
    All VDD/VSS pins are connected (most important).
    There is a single decoupling cap under the board. Not the best practice, but probably ok.
    The trace widths for power/gnd to the propeller are a bit small but probably ok.

    OP answers to forum questions will reveal more ....

    How do the 5V and 3.3V pins look? DVM? DC and AC. Oscope?
  • deepblueqdeepblueq Posts: 5
    edited 2014-06-10 12:21
    I don't have a known good board to test against.

    RESn is solid high.

    The crystal is 20 MHz, and I had forgotten about that (just the sort of thing I thought I might have done). I just tried it with the RCFAST board profile, and there's still problems at the terminal, but the LEDs work now. :)

    Power around the board all appears rock solid at 3.31 on a voltmeter, nothing AC, but that's with no load (more on that in a second). It turns out I'm not actually using the 5V supply for anything, so it's effectively just another filter stage. Power stability around the board is definitely a concern. The big MOSFETs on the left are motor drivers, and will be switching 2 motors that draw 30A stall each (there are off-board connections between them to route that much power around). I've got 6.3uF caps across each motor and across the battery, then the filter caps on the board are 100uF each (biggest SMD ceramic of reasonable cost I could find). That's one at the output of each regulator and one under the Prop. The battery and high-power wiring are beefy enough, and the motors are mounted ~8 inches from the board, but there will still be quite a bit of comm/switching noise on the 7.4V supply, hence the oversized ceramic caps for everything downstream.

    Thanks Dave, that appears to have been the main issue. Now it's just the terminal link that's bugged, which is a situation I'm much more comfortable with. I'll see about a custom board profile next.

    Right now, on test.c, I get occasional gibberish on the terminal at 57600 baud, nothing on other rates. I can imagine that being related to RCFAST's imprecision, so maybe I'll get lucky and the board profile will fix everything.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-06-10 12:23
    The terminal will not work with RCFAST because the frequency is too inexact and the baud rate will be off. You could try using the 20 MHz crystal without the PLL.

    -Phil
  • deepblueqdeepblueq Posts: 5
    edited 2014-06-10 12:49
    I got a custom board profile up:
    #nav.cfg
         clkfreq: 80000000
         clkmode: XTAL2+PLL4X
         baudrate: 115200
         rxpin: 31
         txpin: 30
    

    It's back to the same thing it was doing in Spin. In this case, test.c returned this at the terminal:
    0迿O0O0O0O0O0O0O0O0O0O0O0O0O0O0O0迿O0O0O0O

    ... with an extra 0O every second (every hello world). That gap in the middle is when I disabled and reenabled the serial link. The second time I did that, the LED went out and it stopped transmitting (the program was only in RAM), so something crashed.
  • jazzedjazzed Posts: 11,803
    edited 2014-06-10 13:05
    Can't use PLL with a 20MHz crystal.

    Use these ...

    clkfreq: 20000000
    clkmode: XINPUT
  • deepblueqdeepblueq Posts: 5
    edited 2014-06-10 13:55
    That's odd, but it seems to work. Hello world is returned properly (using clkmode: XTAL2; XINPUT doesn't give the crystal feedback at all ;)).

    Where was that in the documentation? I just looked through the relevant bits of the Propeller manual again, and saw nothing to indicate my setup wouldn't work. I can swap it to 5 easily enough, but when setting this up I didn't think it mattered at all as long as the PLL options could take it to 80.

    It does still seem to crash about half the time when I disable the serial port. It turns out I don't have a decent DMM at the moment. One is missing and one might be trustworthy... as a paperweight. I'll have one tomorrow morning. I could probably get access to an o-scope, but it's a bit of a hassle.
  • jazzedjazzed Posts: 11,803
    edited 2014-06-10 14:12
    The issue with the PLL frequency is mentioned in the Propeller Chip Datasheet ... in the clock section PLL enable bit entry.
    The PLL internally multiplies the XIN pin frequency by 16. OSCENA must be ‘1’ to propagate the XIN signal to the PLL. The PLL’s internal frequency must be kept within 64 MHz to 128 MHz – this translates to an XIN frequency range of 4 MHz to 8 MHz.
    


    Ya, get a 5MHz crystal. That would be the "rock solid" thing to do.

    Some people here will mention overclocking, most people who come here use 5MHz because that's what Parallax sells.

    I'm glad you found out about board types. I assume you did some digging or maybe even read the SimpleIDE user guide.
  • deepblueqdeepblueq Posts: 5
    edited 2014-06-10 15:02
    Interesting. So it looks like the frequency multiplier stage is always 16x, and then it can just be divided back down if necessary? I can imagine that being simpler in silicon.

    For board types, I just looked around PropGCC's files until I found something that looked like the board type list in the IDE, then followed their format. Quick and easy.

    I'll switch to 5, and tomorrow morning I should be able to investigate the crash further.

    Thanks all!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-06-10 15:05
    deepblueq wrote:
    Interesting. So it looks like the frequency multiplier stage is always 16x, and then it can just be divided back down if necessary? I can imagine that being simpler in silicon.
    Yup, it's simpler because the VCO can have a limited range of 64-128 MHz. A VCO with a huge range is way more complicated to make than a digital divider and harder to stabilize.

    -Phil
Sign In or Register to comment.