What are the most common causes of Propellers crashing after integrating workin
ElectricAye
Posts: 4,561
Hi all,
after testing my various isolated programs that successfully run various components (DS1307, DS18B20, SD cards, TV ), I'm now frustrated by system crashes happening when I put it all together. It's the hardest thing in the world to debug, especially when the SD cards continuously get doinked and I have to struggle to reformat them after every crash. Rather than post massive reams of code that nobody wants to look at anyway, I thought I'd ask a general question: what are the most common causes of Propellers crashing after integrating working code? What sort of things should I be looking for these next 7 years as I slowly go insane debugging this thing, wishing I had never ever started down this path in the first place?
after testing my various isolated programs that successfully run various components (DS1307, DS18B20, SD cards, TV ), I'm now frustrated by system crashes happening when I put it all together. It's the hardest thing in the world to debug, especially when the SD cards continuously get doinked and I have to struggle to reformat them after every crash. Rather than post massive reams of code that nobody wants to look at anyway, I thought I'd ask a general question: what are the most common causes of Propellers crashing after integrating working code? What sort of things should I be looking for these next 7 years as I slowly go insane debugging this thing, wishing I had never ever started down this path in the first place?
Comments
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
2) Array subscripts out of range
3) "Infinite" recursion. This is similar to #1, but can occur with only one cog with the main stack.
All of these are really cases of a program writing to some unexpected portion of memory.
did you put together everything in one step ?
Well this could be done as one quick (and dirty) try with a wish of good luck
if it works you had a lot of luck
If it does not work do it step by step.
Putting two parts together and test it again. NOT only a quick "propeller starts up OK" add the next one
You should do a more intensive testing of the two parts
Then add a third part.
If you have all together another method is to narrow down the thing
delete ONE componente and test again
Or insert commands that will send debug strings to a Terminalsoftware or TV_Text
The best way is to test each component REAL intensively. Otherwise some strange effects will
occur after two weeks up to some months of working properly and then you have to test it all
best regards
Stefan
Two Cogs each trying to control the same I/O pins.
For PASM it's usually missing a # for jmp in my case. Having misaligned words and longs can be a pain.
I tried to include a range of various TV_Text drivers in a program once ( Basic Stamp emulator ) so the user could select which they wanted nice characters versus more characters at run-time and tried to move the screen buffer to a higher object to save RAM and pass its address down to the drivers. Should have been a piece of cake but it never worked.
something). But this sort of thing is definitely frustrating.
What sometimes helps is to add a serial port logging to a terminal program, and start adding debug statements; this will show you the last things to happen
before a crash (and the display doesn't go away when the Prop crashes).
The reformatting issues are probably because the fsrw routines are getting stomped (internal data structures cleared or something) and then it's writing to
block zero (where the partition information is stored). I would disable writes in your code if possible until you have this problem figured out.
If you are using fsrw from multiple cogs, this sort of behavior could occur.
yours are truly words of wisdom. I need to litter this thing with debug statements and output to something other than a TV so I don't lose the very thing I need to see when it all comes crashing down. Because it crashes in a repeatable interval, I'm guessing it's some kind of memory overwrite madness as rokicki suggests. Honestly, this is exactly the kind of topic I had hoped to avoid learning about when I undertook this project.... (What in the wild, wild world of sports is a-goin on here?) ... but oh well.... I got a handful of bullets here I guess I'll have to starting biting down on.
Molar fragments anyone?
Mark
I think you should post your complete project archive if you are disposed. It would help in perhaps guiding you in the best way to debug your program.
Turns out that when the USB on a propstick is unplugged, the FTDI chip is just an unpowered lump of silicon, and when my full duplex serial object pulsed it during initialization, the pulse fed back through to the reset! (Bug or feature?)
Sounds easy now, but I spent some considerable time finding that out.
Had to add a jumper for 'configuration' mode, and not start the serial object unless it is on.
I ultimately found this using a combination of Erik's method of commenting out objects, and consulting the schematic.