(warning: long post -- but no cows for Gary's sake) Some observations: There has been some discussion recently about RAM getting corrupted I/O registers getting messed up and that we should all include somewhere in the firmware loop various degrees of re-initialization so the processor can get back up on its feet after a hit. I'm not going to tell you not to do that stuff but here are some tips I have learned over the years to minimize the hits. I'm probably not going to state anything that you folks don't already know, but there may be a few new people out there that might benefit. I'm not covering everything either because I don't know everything. Embedded designs are not easy to troubleshoot in the first place and sometimes you don't know if it's the hardware, the software, the firmware, the compiler, the cable, version incompatibilities, the power supply, timing problems, the phase of the moon etc., and repairing each bug can be an adventure in itself. So the approach I use is to try to get it right the first time (short cuts rarely are). Here's a process I use: 1) Analyze the requirements. Articulate the problem you are trying to solve. A process I like to use is a simple one. Write a paragraph or so on what your widget is supposed to do. Get it to a point where someone else can read it and understand what you are trying to do without any coaching on your part. 2) Now take out two different colored HI-LIGHTERS and mark all the verbs with one color and all the nouns with another. The nouns are the data. The verbs are the processes. Collect the verbs (processes) into four streams (a) low level (implementation dependent) input (b) high level (logical) input (c) high level (logical) output and (d) low level (implementation dependant) output. Collect the nouns (data) with the appropriate verbs and identify them as either input(s) or output(s) to that process. Identify cohesive functions by collecting similar processes within each stream. This will help establish a functional hierarchy for your project and will enable you to understand what needs to be done. Unfortunately it will not reveal to you *when* things need to be done and this is the major challenge of embedded controller designs i.e. real time systems, but if you don't know completely what needs to be done you will quickly learn that doing the wrong thing at the "right" time is equally useless. 3) Take your time on the hardware design. Be conservative. You can always eliminate things later after you get it working. Have someone else review it. Ask her what's wrong with it. Try to visualize how your design might fail. Incorporate mechanisms to handle the failure cases. 4) Go directly to a PCB four layer (or more) board if you can. Troubleshooting a rat's nest is no fun at all and you may end up spending a lot of time learning nothing. As you acquire more experience and confidence in your ability this won't seem so shocking. Use the outer two layers for signal traces (most modifications occur here). Inner layers for power and ground. Analog and digital ground eventually get tied together someplace but try to isolate the analog circuits from the digital ones as much as possible. Provide layout for an addition chip (20 pin dip) just in case you need to add a gate, a flip-flop, or other components. Provide in the layout any by-pass caps that may be required there as well. Pay attention as to what you are "bypassing" and where. You can't get something clean without getting something else dirty. 5) Pay attention to shared current paths in both the power traces and ground traces. If you're controlling high current loads, separate power supplies may be in order. What you don't want is a change in load current to produce a "recognizable" change on an input line somewhere else. A separate regulator for the PIC circuitry could be prudent. 6) Bypass every chip's power pin to ground using a 0.01-0.1 uF cap. 7) Isolate the PIC as much as possible with buffers. 8) Always use line drivers/receivers when going off board. Differential is best. Lines should be properly terminated. If TTL, reduce pullup voltage with diodes to limit voltage swings. Ribbon cable may not be a good choice in faster systems. 9) Use shielded cables. Board connectors should have a metal shell and tied to the PCB ground plane. 10) Develop the firmware in small pieces. Ensure that each piece works before going to the next step. Don't try to do too much at once. 11) Run the design at the slow speeds to start. When everything seems to be working then start experimenting with fast. 12) If possible use polling in the beginning. Interrupt driven stuff can drive you nuts enough when that alone is not quite right. 13) Shield the product (metal enclosure). 14) Incorporate a display in your design (leds or other) to provide visual feedback as the PIC rips through the code. In closing ... I've always had a lot of respect for people who do this kind of work. It's not easy -- it can be very frustrating, but a working design tells a lot about the person who made it work. Rich At 07:34 PM 2/27/98 -0500, you wrote: >On Thu, 26 Feb 1998 17:42:27 -0800 "Mauro, Chuck" > writes: >>Yes, it can be updated anywhere in your program. But, don't forget to >>use a MOVWF OSCCAL at the very beginning of your program (@ address 0) >>to establish the proper factory calibration (the data sheet explains >>this). It sounds like you are definitely experiencing a reset >>problem. > >You should keep the factory value somewhere else in your program (a >logistical nightmare), and periodically do movlw /movwf OSCCAL. >Second best would be to copy the factory value to RAM as well as to the >OSCCAL register at the start of the program, then periodically copy it >back to OSCCAL. But if a glitch hits hard enough to trash the RAM, this >won't work. > > >_____________________________________________________________________ >You don't need to buy Internet access to use free Internet e-mail. >Get completely free e-mail from Juno at http://www.juno.com >Or call Juno at (800) 654-JUNO [654-5866] > > ========================================= = Abolish the Income Tax! Fire the IRS! = = http://www.nrst.org/ = =========================================