Prop C code doesn't execute
deepblueq
Posts: 5
(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:
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. 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).
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!
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. 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).
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!
Comments
If so, how does that work compared to your custom board?
Can you measure what happends on the Reset - Pin RES/ during program execution.
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.
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?
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
It's back to the same thing it was doing in Spin. In this case, test.c returned this at the terminal:
... 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.
Use these ...
clkfreq: 20000000
clkmode: XINPUT
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.
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.
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