Post by thread:[PIC]: favorite anti-blowup strategies

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-requestTakeThisOuTmitvma.mit.edu

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-requestKILLspam@spam@mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestKILLspammitvma.mit.edu

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}> 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-requestKILLspam.....mitvma.mit.edu > > -- > http://www.piclist.com hint: To leave the PICList > EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 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-requestspam_OUTmitvma.mit.edu

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@speffKILLspaminterlog.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

> "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

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

> "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 KILLspamrubenKILLspampp.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

> 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

> "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

> "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

> "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

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}