Searching \ for '[PIC]: favorite anti-blowup strategies' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'favorite anti-blowup strategies'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: favorite anti-blowup strategies'
2002\11\17@221202 by Rob Robson

picon face
After chasing a random crashing problem on a 16F877 project for days now,
I've run dry of troubleshooting strategies (not that I had very many
sensible ones to begin with).  In short, my project will perform certain
operations flawlessly sometimes, then fails spectacularly on the 'n'th
attempt, with 'n' generally residing between 1 and 10.  My inexperience has
likely led me to commit some programming faux pas I just can't spot.  To
help get me unstuck, would any of you gurus be willing to complete the
phrase;

"When my program blows up randomly, the first thing I look for is..."

Thanks in advance!

Rob Robson

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\11\17@223702 by hard Prosser

flavicon
face
1. Power Supply Variations outside expected limits (transients etc)
2. Interrupts (Intentional or not) and how they are handled..
3. Input pins changing into output pins (& driving a low impedance)
4. Floating pins defined as inputs & susceptable to exernal noise/
RF/static
5. External harware driving pins outside the limits.
6. Clock/Xtal problems.

If you still have problems we might need a bit more info as to the
application / environment etc. to suggest something deeper.

Richard P






After chasing a random crashing problem on a 16F877 project for days now,
I've run dry of troubleshooting strategies (not that I had very many
sensible ones to begin with).  In short, my project will perform certain
operations flawlessly sometimes, then fails spectacularly on the 'n'th
attempt, with 'n' generally residing between 1 and 10.  My inexperience has
likely led me to commit some programming faux pas I just can't spot.  To
help get me unstuck, would any of you gurus be willing to complete the
phrase;

"When my program blows up randomly, the first thing I look for is..."

Thanks in advance!

Rob Robson

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\11\17@232359 by Wagner Lipnharski

flavicon
face
Also, eliminate most of the non necessary routines for this debugging time,
bypass them with jumps.

If using AC power adapter, move to battery during the debugging.

If connected to other equipment, make sure ground lines are really tied and
with solid connection, using large copper area larger than the signal
wires.  if necessary use shielded cable to do it.

Try to eliminate all the external connections by simulating them on board,
using resistor dividers, etc.

Try to display important counters on some LCD for debugging purposes,
sometimes some counts get off limit and it messes with the program logic.
Make sure the program is reseting all counters to a known value at power on
reset routine.

as Rich said below, missing or wrong decoupling caps at the cristal input
pins.

Wagner.




Richard Prosser wrote:
{Quote hidden}

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Wagner Lipnharski - UST Research Inc
Orlando FLorida - USA - http://www.ustr.net
/_/_/_/ Atmel AVR Consultant /_/_/_/

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2002\11\18@003730 by Spehro Pefhany

picon face
At 07:12 PM 11/17/02 -0800, you wrote:
>After chasing a random crashing problem on a 16F877 project for days now,
>I've run dry of troubleshooting strategies (not that I had very many
>sensible ones to begin with).  In short, my project will perform certain
>operations flawlessly sometimes, then fails spectacularly on the 'n'th
>attempt, with 'n' generally residing between 1 and 10.  My inexperience has
>likely led me to commit some programming faux pas I just can't spot.  To
>help get me unstuck, would any of you gurus be willing to complete the
>phrase;
>
>"When my program blows up randomly, the first thing I look for is..."

First figure out if it is hardware or software (sometimes it is a
combination of the two, unfortunately, but this is rare).

If it is software, this sort of behavior is usually related to
interrupts (incomplete restoration of pre-interrupt state), or un-initialized
variables, including pointers. Usually good design will prevent this
sort of thing, and just as well as it can be very hard to track down.
Sometimes not setting the carry flag explicitly if there are multiple
paths to a given routine can cause this sort of problem.

If hardware, try to narrow it down to internally created problems vs.
externally (including outputs and inputs of your project). For example, if
you are switching a 3HP motor with a contactor and a relay, try
disconnecting the motor, then the contactor, then the relay and replacing
the latter with an LED. There are also the obvious (but not when they
are thwarting you) bad solder joints, pins not properly inserted into
sockets, poor supply bypassing, amplifiers and voltage regulators
oscillating and such like. And EMI/RFI. Inputs not connected and even
a power pin not connected are other possibilities.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
@spam@speffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@012822 by Russell McMahon
face
flavicon
face
> "When my program blows up randomly, the first thing I look for is..."

Lots of redundancies with other replies but -

- ENSURE that watchdog is either disabled or being properly reset always.
Starting with watchdog disabled is advisable. I have seen a whole product
run correctly but sluggishly with the watchdog resetting it regularly and
unintendedly.

- In processors which have a user settable stack pointer, set the stack
pointer at the earliest possible point in the code. (This is USUALLY the
first instruction - some processors demand some other action as the first
instruction).

- ENSURE that max available stack depth for interrupts / subroutines is
NEVER exceeded. (The depth may vary with circumstance. If you have IRQs and
Interrupts you may sometimes (fatally) overflow stack area when IRQ occurs
while at max stack depth in some subroutine.

- Beware sharing (fatally) registers/RAM between IRQ and foreground tasks.

- Ensure all subroutines have returns via all possible paths (and don't fall
off end into other code). Same applies for interrupts with appropriate
return.

- Ensure you use interrupt return for interrupt and subroutine return for
subroutine.

- Conditional paths may lead to death but be only called sometimes.

- If you assume a register has a given starting value ensure you put it
there during initialisations.
Safest method is to zero ALL RAM etc and assume it starts at zero.
Initialising with specific desired values as required and not initialising
those locations that don't assume startup values is fine AS LONG AS you
always get it right. Some processors will often but not always zero RAM.
Assuming that they always do will get you sooner or later.

- ENSURING that subroutines and interrupts do not corrupt the waters is
wise. Results vary with processor used. Some will push status flag on ints,
some don't. Some save various regs on IRQ, some don't.

- Ensure you understand EXACTLY what conditional branches do
(signed/unsigned/plus/half carry/overflow/ negative/ ... can create a host
of joys.

- Initial / boundary conditions often kill you. Murphy says that stopping a
loop one over or under or starting 1 below or above intended point is easier
than getting it right. The last character in an array will be unprocessed
when you leave. One more than the last character/number in an array will
have been processed. The character returned will be one off from where you
think it came from. Your multiplication / division will handle N+/- 1 bit
when N is intended etc.



       Russell McMahon

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@014931 by Scott Dattalo

face
flavicon
face
On Sun, 17 Nov 2002, Rob Robson wrote:

> "When my program blows up randomly, the first thing I look for is..."

...my most recent known working backup doing the same thing?

Without an in circuit emulator, it is risky to make a drastic change to
your code (and expect it to work). So typically I break development into
(at least) two strategies:

1) Make low risk, incremental changes and verify the change does what is
expected.

2) For changes that are in their nature "major", simulate before burning
chips. This can be a challenge with MPLAB, but something like gpsim or
UMPS makes the job "possible".  ICD may be a suitable alternative... Once
you've verified that the simulated works, debug the real thing. (The only
reason I say ICD "might" be a suitable alternative is that in many cases
it's just too intrusive.)

Scott

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@022911 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
> "When my program blows up randomly, the first thing I look for is..."
>
An emulator with TRACE possibilities :-)

Stack overflow.

Bank and page switching.

Interrupt routine messing with noninterrupt variables or routines.

One thing that has bitten me a couple of times: Interrupt routine that directly sets an IO pin of a port that is also managed by the main program while it is temporarily holding the port value in a register.
Code for main program:

1:      mov             w,#BITMASK
2:      and             w,PORT
3:      do something to the port value here
4:      mov             PORT,w

If you get an interrupt that also sets an output in this port register at step 3, it is lost as soon as the interrupt is returning and step 4 is executed.

Ruben==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
KILLspamrubenKILLspamspampp.sbbs.se
==============================

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@050014 by Alan B. Pearce

face picon face
> After chasing a random crashing problem on a 16F877 project for days
> now, I've run dry of troubleshooting strategies (not that I had very
> many sensible ones to begin with).  In short, my project will perform
> certain operations flawlessly sometimes, then fails spectacularly on
> the 'n'th attempt, with 'n' generally residing between 1 and 10.  My
> inexperience has likely led me to commit some programming faux pas I
> just can't spot.  To help get me unstuck, would any of you gurus be
> willing to complete the phrase;
>
> "When my program blows up randomly, the first thing I look for is..."


Well this is where it pays to have a linker in use :))

The linker produces a memory map of the whole project, and does it in two
forms. The first is in alphabetical name order of the variables, and the
second is in memory address order of the variables. It separates the data
ram area from the program memory, and by looking through this map it is easy
to see if there is the possibility of a ram bank error fouling up a critical
variable.

This has been an indispensable way of sorting out this most basic form of
mistake.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@072733 by Bob Ammerman

picon face
> "When my program blows up randomly, the first thing I look for is..."

A cold beer? (actually I am almost a teetotaler, but I couldn't resist!).


Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@080541 by Olin Lathrop

face picon face
> "When my program blows up randomly, the first thing I look for is..."

There is no easy answer to that.  If you have no idea what causes the
symptom, you probably need to work backwards.  Wait until it "crashes" and
look carefully at all the state.  Something will probably be amiss.  At
the very least it will not be responding properly to a new input.  You can
give it a new input and see why it handles it improperly.  At that point
*something* must be identifiably wrong.  Hopefully you can find a way to
set a break on the illegal condition and start working backwards.  If
you're lucky you can see what went wrong in the trace buffer right before
the illegal condition was caught.  Otherwise you may have to look back to
find an earlier illegal condition to trigger on and repeat the process.

Note that this kind of debugging is the last resort.  Pouring thru trace
buffer listings is tedious and slow, and is worth a great many Good
Programming Practises to avoid.

If you are using interrupts, step thru the interrupt routine carefully
even if you think its working right.  It might be trashing some state of
overflowing the stack, etc.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@110348 by Wouter van Ooijen

face picon face
> "When my program blows up randomly, the first thing I look for is..."

- unintialised variables
- interrupt problems (must assume nothing, must preserve averything,
race conditions? multi-byte updates?)
- watchdog enabled but not kicked often enough?
- hardware problems (Vcc decoupling, open inputs, ...)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@112250 by Alan B. Pearce

face picon face
> "When my program blows up randomly, the first thing I look for is..."

>- unintialised variables
>- interrupt problems (must assume nothing, must preserve
>averything, race conditions? multi-byte updates?)

Also check for foul ups in the non-interrupt code where you should disable
interrupts around a piece of critical code (empty/fill a FIFO that is
filled/emptied by interrupt routine) or race conditions on setting/resetting
flags for these. I find it is easy to get the interrupt code properly set
up, but then inadvertently take a short cut in the background routine.

This is an area where I found using Olin's modular development environment
very handy. Having the background routine in the same module, right adjacent
to the interrupt code helps keep the thinking for both sides in step. It
also enforces a process where you have to use an already written interface
routine to access buffers, so that the data registers have an encapsulation
enforced, which helps stop writing spaghetti code that gets you into
trouble.

It also results in having a module to do a function (uart, I2C, etc) that
you know has been thoroughly debugged and works, so in the next project you
do not have to do it again. At worst some additional routines may need to be
added to the encapsulation to add features.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\18@143502 by Matt Heck

flavicon
face
1. Find some way to verify that your stack depth REALLY IS what you think
  it must be below.  The PICs don't do a stack overflow the way a PC does...
  at least in that series, it's messy.

2. Make sure code that should not be re-entrant (calling itself) isn't.
  This gets more difficult when you realize that you aren't trying to catch
  just a recursive call, per se, but also to catch an accidental branch
  back into yourself becaue your page bits were set wrong.

3. Be sure your basic algorithm is sound!  Try implementing/simulating it in
  C (WITH THE SAME NUMBER OF VARIABLES AND SUBROUTINES) and see if it does
  what you expect.  Especially important with floating-point math and DSP,
  compression, and decompression work.

4. Be suspicious of RAM overlays.  Try using single-purpose variables until
  your problem is cleared up.

5. Component test everything.  That means, take each function, dump it on
  a chip with a test harness, and call it about a million times to make
  sure it works.

6. Failing anything else, start locking down relocatable code segments and
  RAM variables to fixed addresses and REALLY verify the hell out of EVERY
  page and bank select.

Good luck!
  Matt Heck
  Crystal Engineering


> {Original Message removed}

2002\11\18@144335 by Chris Hunter

flavicon
face
----- Original Message -----
From: "Rob Robson" <RemoveMEdanaggerTakeThisOuTspamTELUS.NET>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Monday, November 18, 2002 3:12 AM
Subject: [PIC]: favorite anti-blowup strategies

> "When my program blows up randomly, the first thing I look for is..."

... the coffee pot!

Chris

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\20@175615 by Philip Pemberton

face picon face
Rob Robson wrote:
> "When my program blows up randomly, the first thing I look for is..."
A fried power supply, crystal, resonator.
Oh, have you put a 1k resistor between /MCLR and Vcc?

Later.
--
Phil.
TakeThisOuTphilpemEraseMEspamspam_OUTdsl.pipex.com
http://www.philpem.dsl.pipex.com/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\21@071033 by Wouter van Ooijen

face picon face
> Oh, have you put a 1k resistor between /MCLR and Vcc?

Why would that be needed (unless you want to do ICSP)?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...