> From: Clyde Smith-Stubbs > > "J. Cabral" wrote: > > > I've compiled sucesseful the project and made a dowload to memory! > > > > I connected an oscilloscope to the socket pin 2 (used pin 12 as GND) > > and ... nothing worked! > > It's never useful to say "nothing worked". Firstly - did you start the > program running? Did you single step to confirm that it executes the code > you wrote? Did you examine the contents of TRISA and PORTA to see if the > bits actually changed? When using the PICMaster you can do this - it's not > like you're just programming a ROM and turning it on. > > Maybe the lines like "bsf rp0" should be "bsf status,rp0". But your message > should be much more detailed when asking for help. I have to agree with Clyde. Some of us like to help so _please_ spend a few minutes polishing your email and adding the necessary information for problem resolution. I propose the following "form" which indicates the sort of information that should be provided if you want a quick answer from fellow piclisters. If you _really_ feel that something is not applicable then leave it out. However, since you are posting a problem then presumably you are not expert enough to solve it yourself so it would be best to enter all information. The problem is often in a totally unexpected direction. I would hope that the form would be made more comprehensive. It should also be the first answer to posters who say "My PIC's broken. Please help!". Regards, SJH Canberra, Australia PIC HELP FORM ------------- 1) Background . Description of application. . PIC Device number. 2) Hardware config including . Power supply - Voltage confirmed (oscilloscope, multimeter) - Connected to _all_ power pins e.g. '74 has two GND and +5 pins - Bypass cap . Oscillator type - Clock speed? - Confirmed set configuration bits. - Confirmed clock signal on OSCOUT. - Confirmed frequency (oscilloscpe, freq meter) . MCLR pin - Method of control e.g. tie to +5, external brownout protection . . I/O pins - Connections in circuit - give description or ascii diagram. - Mode (in, out, I/O, analogue, comparator, used by peripheral) . Other considerations e.g. - Electrically noisy environment - Temp range 3) Software . What is the code supposed to do? . Reset path - Setting of option register - Setting I/O port directions and initial values - Analogue input configuration - Peripheral configuration . Using interrupts? . Code lowest and highest address (looking for page boundary overflows) . Use of peripheral functions - Timers - SPI - UART - ADC - Capture/compare/PWM . Using watchdog timer? . Using power-down (sleep) modes? . Add assembler listing fragments if appropriate. Note that a balance h as to be made between excessive bandwidth from list server and ability to see all the code. You should be prepared to send a complete listing if requested. . Add listing of interrupt routine. Since interrupt handlers can have drastic and unexpected effects, it is well worthwhile to include at least this part of the code. NB: Assembler list output is more useful than source code since it allows confirmation that macros have expanded correctly etc. In many cases you will solve your own problem by looking through the listing. 4) Development environment . PC operating system (DOS, WIN31, WIN95 etc.) . MPLAB, Clearview PDE etc. and version numbers . Programmer hardware 5) Testing procedure - detail results. . Use MPSIM? If not, give reason as to why use of MPSIM etc. was not helpful e.g. too difficult to make real-time stimulus. . Use in-circuit-emulator? . Use programmed chip in target circuit? . Was test-point code added e.g. toggling a spare port pin at certain points in code. If so, what did this indicate? 6) Any other relevant information. 7) Go over your email to make sure that it is not ambiguous or misleading. Correct the typos, spelling and grammar to the best of your ability.