PIC code self-start execution

This depends on the configuration of the pin, see the datasheet at

If the pin is not configured as a digital input, you have to connect it to Vdd. The internal power-on reset circuit should do the reset, if the power-up slope is not too slow.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

If it's your own circuit you're putting it in, here's a general checklist of why circuits appear to do nothing:

MCLR must be high Check Vdd and Vss Make sure oscillator is connected, if it's a 3 pin resonator make sure it's grounded and try it the other way round. Make sure oscillator is in frequency range and correct type for the oscillator configuration set on the config bits Test your program with it requiring no inputs (ie. it will output some visible effect with no input signal) Check the config bits - make sure the internat oscillator is enabled if required, and WDT is disabled, and POR and BOR are enabled. Do a verify of the program - flash writes often write incorrect data with poor programmer connections. Try a new chip - fried chips can do really wierd stuff.

Also, some compilers add a "debugger bootstrap" to your code, which may be interfereing if it can't connect to the debugger. Try a simple one line assembly program, and check the hex file with notepad to see that there's no more than one or two bytes of data.

I've ensured that MCLR is high through a power on reset connected as such

as instructed in the power-on reset section of the manual. However, the time it takes to return to

5V from 0V after the reset butt> If it's your own circuit you're putting it in, here's a general

Stanley,

When you're setting up your processor's configuration switches, fuses, or whatever syntax your compiler requires, try setting the MCLR pin as an input. Look in your documentation for a configuration switch that looks something like "MCLRE OFF" (in whatever syntax convention your compiler uses.) On your breadboard, float the MCLR pin. Don't even worry about pulling it high.

Also, make sure that you've set your configuration options to select the internal RC oscillator. In your code, program the internal oscillator for 8 MHz right as your first step after reset.

My suspicion is that you don't have an MCLR problem. I'm guessing that your prolem is related to the internal oscillator.

Good luck!

Tom

That might be your problem, or at least a large part of your problem. You're using tools not specifically designed for PICs, with who-knows-what quality of documentation for PIC topics.

You're trying to learn two things at once: using PICs in a Linux environment, and learning how to use PICs.

I'd recommend that, until you're very comfortable with the PIC environment, that you move back to Windows and use MPLAB and the C18 compiler.

Once you're comfortable with PIC programming, you can then move back to Linux.

Right now, you're shooting at two moving targets. You need to simplify your situation to avoid spinning in circles.

If you're going to stay with Linux tools, maybe posting your questions in a Linux group would be a better. There must be folks there that know the ins and outs of the tools you're using, and can provide more specific answers than my "something that looks like MCLRE OFF." Answers like that aren't going to help you one little bit.

Just a thought...

Good luck!

Tom

Hi Tom,

First of all, I would like to thank you for your replies on the issue. First of all, by talking to the people on SDCC mailing list and got that sample code. I have also compared the fuse initialization commands with the bytes described in PIC18F2620.h file from the SDCC libraries. Hence, I'm sure that the fusebits were configured properly to my knowledge. I'll probably get back to them about the problem for additional insights.

In case if I haven't talked to you about my reasons of developing PIC codes in Linux, I do so b/c MPLAB and PICKIT2 programming software, for some reason, always freezes on my computer b/c of them using .NET technology from Microsoft. My laptop computer is on the verge of getting phased out (it's an Acer Travelmate 2300, bought about 3 years ago), and I'm planning to max out the life of my laptop until I really can't use it anymore (aka power switch fails). This situation doesn't happen when I use Ubuntu (at least not yet). So here's the motivation of why I'm using Linux for PIC code development.

Stanley

That's good news, Stanley, that you have access to the SDCC experts. That will help you a lot.

I'm also stretching the life of an old laptop. I use a Dell PIII 1 GHz C610 for my electronic work because it has a serial port. (With my "good" laptop, I have to play the USB-serial converter bingo game. "Let's see... which of my three converters (if any) might work with

*this* app today?" Yuk!)

By the way... don't worry about your power switch. Your hard drive will fail first. Make frequent backups. :-)

Have fun!

Tom

Hey Tom,

It is also suggested by

that there could be a problem with my DC adapter. I'm just wondering if you have any thoughts on my approach on the brown out reset and power on timer for the execution start delay

Stanley

Hi, Stanley,

I wouldn't think that power could cause your problem. PICs aren't very critical about the power you're feeding them, as long as it's clean.

Measure Vdd to Vss at the PICs power pins. If it's anywhere near 5 volts, you should be in good shape. Make sure you bypass the power feed with a good, low ESR capacitor as close to the PICs power terminals as possible. (At a minimum, use a 0.1 uF ceramic cap. If you have a good tantalum readily available, so much the better.)

In your config section, try turning BOR and PWRTE off. I don't think you need them. (If your power supply is in good shape, they shouldn't make any difference at allm no matter how they're set.)

I have to admit, at this point, that I'm scratching my head. If you have the internal RC oscillator running, and you've either turned MCLR off or have pulled it up, your PIC should be running. The fact that it's not is a mystery to me.

Good luck!

Tom

Stanley,

I just took a look at your posting on the Dutchforce site:

"I have managed to get a sample code of blinking the LEDs compiled and built into a hex file. I have managed to write the code onto a PIC18F2620 using a PICKIT2 programmer using pk2 in ubuntu. However, I can only run the microcontroller when I type in "pk2 -on" to turn on the power supply from the computer to the mcu. If I try to run the control code without a pk2 connected to be supplying the computer power supply to the mcu circuit (i.e. only connecting Vdd and Vss pins to the DC power supply and output pins), it seems that the code never executes. I'm suspecting that I'm doing something wrong with the MCLR pin. I haven't enclosed any software coding b/c I'm currently suspecting that it's a hardware problem. Does anyone have any ideas?"

I infer from the above that you're trying to power the PIC from the Pickit2 at all times, even after you've programmed it.

you said that the PIC runs only after you've typed "pk2 -on."

My guess is that unless you've turned on the Pickit2, it's not supplying power to the PIC.

Try this: after programming, completely disconnect the Pickit2 from the PIC (all five ICSP leads) and power your PIC from an external 5 volt source. Take the Pickit2 completely out of the equation. Then fall back to basic troubleshooting, if your PIC still isn't running, to solve your problem.

If you're still having trouble, please come back and state exactly what you've done, in detail, including any measurements you've taken.

Tom

From your listing published on Dutchforce:

I think you just turned off your oscillator. Try this:

Also in main{}

Hi Tom,

I have connected a tantalum 0.1 uF capacitor across the power terminals of the PIC, pins 19 and 20. I have also ensured that the fusebit configuration in the code disabled BOR and PWRT. I have originally initalized my internal oscillator in the main function, but has since changed its initialization routine in init_cpu() and have my main function call init_cpu() as shown in the code included. One new observation that I have made with the problem is that after I programmed the microcontroller and instructed PICKIT2 to turn on the power supply, the mcu wouldn't start execution until I pulled it off the programming headers and reconnected PICKIT2 to the programming header. The microcontroller wouldn't run on an external regulated DC supply unless I manually reset MCLR pin by shorting it to ground sometimes. Also, I'm suspecting that the hex file isn't compiled properly in Piklab IDE. I'm working on manually compile and link the code with Makefiles. Here's the link on the developments on that side if you're interested:

Thanks for your help,

Stanley

interested:

It's been a while since I've last posted so I guess I'll update you about what's going on. I have been exchanging the status of the problem on the sdcc mailing list, and apparently, I did not set a power on reset properly and also a gpr stack variable initialization, although I'm still experiencing the same problem right now after taking their recommendation. I'm not too sure if I should look into the Microchip's forum's suggestion more seriously now. I'm also thinking about developing some code that would be common on any controller on a PIC16F877A at the same time. Does anyone have any thoughts on the progress?

Thanks,

Stanley

interested:

I have some good news today to report. I have swapped out the PIC18F2620 with a PIC18F2220, changed some code with the help of the folks at sdcc, and the self-execution problem has been solved.

Thank you all for your help,

Stanley