PIC code self-start execution

[ssylee]

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?

 

[Frank Buss]

I'm suspecting that I'm doing something wrong with the MCLR
pin.

This depends on the configuration of the pin, see the datasheet at
http://ww1.microchip.com/downloads/en/DeviceDoc/39626C.pdf
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.

 

[[email protected]]

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.

 

[ssylee]

I've ensured that MCLR is high through a power on reset connected as
such http://imagebin.ca/view/4YjqO0.html 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 button is turned on in this configuration
is 250 ms, but no matter which combination of the R and C I've tried,
it still won't reset automatically when I first power up using
anything other than a PICKIT 2. I'm not sure what other information
would be useful. I guess I could try changing MCLR reset on in the
code. I'm using a DC adapter that's scrapped off a decommissioned
wireless router. Any insights on this would be much appreciated.

 

[Tom2000]

I've ensured that MCLR is high through a power on reset connected as
such http://imagebin.ca/view/4YjqO0.html 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 button is turned on in this configuration
is 250 ms, but no matter which combination of the R and C I've tried,
it still won't reset automatically when I first power up using
anything other than a PICKIT 2. I'm not sure what other information
would be useful. I guess I could try changing MCLR reset on in the
code. I'm using a DC adapter that's scrapped off a decommissioned
wireless router. Any insights on this would be much appreciated.

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

 

[Tom2000]

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

 

[ssylee]

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

 

[Tom2000]

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.

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

 

[ssylee]

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 http://forum.microchip.com/tm.aspx?m=283989
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

 

[Tom2000]

Hey Tom,

It is also suggested by http://forum.microchip.com/tm.aspx?m=283989
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

 

[Tom2000]

Hey Tom,

It is also suggested by http://forum.microchip.com/tm.aspx?m=283989
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

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

 

[Tom2000]

Hey Tom,

It is also suggested by http://forum.microchip.com/tm.aspx?m=283989
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

From your listing published on Dutchforce:

//void init_cpu() {
/* INT Osc with 8MHz */
// OSCCON = 0x70; /* 01110000 */
//}

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

 

[Tom2000]

From your listing published on Dutchforce:


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

Also in main{}

 

[ssylee]

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:
http://sourceforge.net/mailarchive/[email protected]&forum_name=sdcc-user

Thanks for your help,

Stanley

 

[ssylee]

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:http://sourceforge.net/mailarchive/forum.php?thread_name=14c4beb30709...

Thanks for your help,

Stanley

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

 

[ssylee]

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

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