PIC18F2620 not being able to self-execute control code

[ssylee]

I have a PIC18F2620 with port b connected as shown in **broken link removed** (except on pin 1, it has a 10k pullup resistor to 5V rather than the power on reset circuit shown in the link). I'm currently using sdcc to compile my code and flashing the hex file to the microcontroller using a PICKIT2 programmer from Microchip through pk2 command line software in Kubuntu. The reason that I'm doing so this way is b/c I'm encountering problems with Microchip's PICKIT2 software in Windows. Basically, I'm using an internal oscillator in mode 2 at 8 MHz. I've talked to people on Usenet newsgroups, Microchip forums, dutchforce forums, and sdcc mailing list about the problem. While I'm very close on solving the fusebit initialization problems, I am still encountering the problem of not being able to have the microcontroller start the execution of the control code automatically whenever an external power supply other than the computer was applied to the microcontroller, although I've checked with an oscilloscope that it appears to be fairly stable. Does anyone here have any insights on this? I would be happy to provide more information if needed as I'm trying my luck here on another forum.

Thanks!

 

[ssylee]

I just wanted to update on the situation. I have swapped the PIC18F2620 with a PIC18F2220 and changed some code and the self-execution problem appears to be solved for now.

 

[atferrari]

What "self-execution" does actually mean?

 

[ssylee]

Perhaps I phrased things pretty badly. What I meant by "self-execution" is my code being able to run automatically when I apply an external power source to the microcontroller. Hope it helps clear the confusion.

 

[Nigel Goodwin]

Perhaps I phrased things pretty badly. What I meant by "self-execution" is my code being able to run automatically when I apply an external power source to the microcontroller. Hope it helps clear the confusion.

That's what they do, they don't work in any other way - if it's not working, you've probably got a power supply problem, coming up too slowly or something?.

 

[ssylee]

Don't really think it's a power supply problem, b/c if it is, I shouldn't be able to get it working with a microcontroller of a different model. It's probably something wrong with that microcontroller itself or something wrong in the code that I flashed to it.

 

[Nigel Goodwin]

Don't really think it's a power supply problem, b/c if it is, I shouldn't be able to get it working with a microcontroller of a different model. It's probably something wrong with that microcontroller itself or something wrong in the code that I flashed to it.

Fuse settings can have an effect, there are a number of them which could change it - but it doesn't mean the power supply isn't wrong, what are you using?.

 

[ssylee]

Are you asking about the fusebits or power supply?

 

[Nigel Goodwin]

Are you asking about the fusebits or power supply?

Both in that case!

 

[ssylee]

Power supply: 15V ac adapter that I scrapped off from a malfunctioning wireless router, regulated using a 7805 regulator with 22 uF (input) and 10 uF + 0.1 uF (output) caps in parallel

Fusebits: have to look at it when I get home from work; don't have the code in front of me

 

[ssylee]

Which fusebit details would you like to know?

 

[Nigel Goodwin]

Which fusebit details would you like to know?

Just post the lines you've used to set them.

 

[ssylee]

These are my fusebits command lines in the source code using PIC18F2620:

#pragma stack 0x200 0xff

code char at __CONFIG1H _conf0 = _OSC_INTIO7_1H;
code char at __CONFIG2L _conf1 = _BOREN_OFF_2L;
code char at __CONFIG2H _conf2 = _WDT_DISABLED_CONTROLLED_2H;
code char at __CONFIG3H _conf3 = _MCLRE_MCLR_OFF_RE3_ON_3H;
code char at __CONFIG4L _conf4 = _LVP_OFF_4L;
code char at __CONFIG5L _conf5 = _CP_0_OFF_5L & _CP_1_OFF_5L;
code char at __CONFIG5H _conf6 = _CPD_OFF_5H & _CPB_OFF_5H;
code char at __CONFIG6L _conf7 = _WRT_0_OFF_6L & _WRT_1_OFF_6L;
code char at __CONFIG6H _conf8 = _WRTD_OFF_6H & _WRTB_OFF_6H & _WRTC_OFF_6H;
code char at __CONFIG7L _conf9 = _EBTR_0_OFF_7L & _EBTR_1_OFF_7L;
code char at __CONFIG7H _conf10 = _EBTRB_OFF_7H;

The following is the fusebit command lines in the source code using PIC18F2220:

#pragma stack 0x100 0xff

code char at __CONFIG1H _conf0 = _OSC_INT_CLKOUT_on_RA6_Port_on_RA7_1H; //_OSC_INTIO7_1H;
code char at __CONFIG2L _conf1 =  _PUT_ON_2L & _BODEN_OFF_2L; //_BOREN_OFF_2L;
code char at __CONFIG2H _conf2 = _WDT_DISABLED_CONTROLLED_2H;
code char at __CONFIG3H _conf3 = _MCLRE_MCLR_Disabled_RE3_Enabled_3H; //_MCLRE_MCLR_OFF_RE3_ON_3H;
code char at __CONFIG4L _conf4 = _LVP_OFF_4L;
code char at __CONFIG5L _conf5 = _CP_0_OFF_5L & _CP_1_OFF_5L;
code char at __CONFIG5H _conf6 = _CPD_OFF_5H & _CPB_OFF_5H;
code char at __CONFIG6L _conf7 = _WRT_0_OFF_6L & _WRT_1_OFF_6L;
code char at __CONFIG6H _conf8 = _WRTD_OFF_6H & _WRTB_OFF_6H & _WRTC_OFF_6H;
code char at __CONFIG7L _conf9 = _EBTR_0_OFF_7L & _EBTR_1_OFF_7L;
code char at __CONFIG7H _conf10 = _EBTRB_OFF_7H;

In order to compare the fusebits, you would need to look at the .h files attached to the post. I have converted them to dos formats in case anyone using windows wants to look at it. You're welcome to change it back to unix format too.

 

[ssylee]

I'm also trying a 8.0 Mhz and 32.764 kHz crystal oscillators at the same time since I may need to use 2620's memory capacity for what I want to do.

 

[ssylee]

I have tried to manually reprogram the configuration bits in pk2 on the 2620. I have taken a shortcut on figuring out the fusebits by looking in the .h files that I've posted on this thread. Below shows the printout indicating that I have failed to configured the fusebits.

root@prak-laptop:/media/sdb1/Sysil Laboratories/software_projects/LED_toggle# pk2 -config 0x3000 0xfef8 0xff00 0x00fb 0xffff 0xffff 0xffff

PK2 version 2.04 - 2006/12/17
 pk2 -config 0x3000 0xfef8 0xff00 0x00fb 0xffff 0xffff 0xffff

Locating USB Microchip PICkit2 (vendor 0x04d8/product 0x0033)
Found USB PICkit as device '003' on USB bus 003
Communication established. PICkit2 firmware version is 1.21.0
Device ID 0x0c80
PIC18F2620 Rev 6 found
Writing config words
root@prak-laptop:/media/sdb1/Sysil Laboratories/software_projects/LED_toggle# pk2 -config

PK2 version 2.04 - 2006/12/17
 pk2 -config

Locating USB Microchip PICkit2 (vendor 0x04d8/product 0x0033)
Found USB PICkit as device '003' on USB bus 003
Communication established. PICkit2 firmware version is 1.21.0
Device ID 0x0c80
PIC18F2620 Rev 6 found

User ID: 0xffff 0xffff 0xffff 0xffff

Configuration data: 0x0000 0x1e18 0x8700 0x00c1 0xc00f 0xe00f 0x400f

Would that have to do with the pk2 program itself? I have also tried to modify the configuration bits in my code swapping the oscillator between internal, HS, and LP modes, but none of them worked. Did I describe enough information to proceed on what could've went wrong?

Thanks.

 

[ssylee]

I have checked with my oscilloscope on the CLKOUT pin of using the internal oscillator of the 2620. Apparently, I am consistently getting a clock out of 8.33 kHz. So the reason that the LED blinking action is not starting properly has to do with the different resets. I have posted previously on Microchip's forums in http://forum.microchip.com/tm.aspx?m=283989. The staff there suggested me to use a power on reset timer and a brown out reset configuration register b/c they think my supply voltage is too low, even though that it's shown on my scope that the voltage is constantly powering at 5V. I'm pretty lost in what more I need to do to get the control code resetting properly. Any insights would be much appreciated. Thanks!

 

[ssylee]

I'm not sure why there is no one responding to this topic, but I'm posting this to get this topic back up to the top anyway. I apparently not only get myself, but also a lot of people stumped on this. Meanwhile, I'm also talking to the technical support about some specifics on the problem. Much appreciated if there's any new ideas poppin' at this point that you would like to share.

 

[Nigel Goodwin]

Try posting a picture of how this is constructed, I get the feeling it may be a question of poor constructual methods?.

I'm presuming when you scoped the clock you used a x10 probe?, if not the capacitance of a x1 probe often upsets micro-controller clocks - might not be the case, but it's worth checking.

 

[blueroomelectronics]

Linux will be a problem until it's supported by Microchips tools.
If you were running XP and MPLAB 7.62 the new PK2 firmware supports (in beta) both programming and debugging the 18F2620.
A debugger can make it easy to see why your clock isn't running.
Your 1.21 firmware is very old, Microchip has released 2.10 for the PK2.
What's the windows error you're getting, I had inital problems with my PK2 in windows but it turned out to be my USB drivers.

 

[ssylee]

To answer Nigel's questions: Do you mean you want a schematic of how everything is connected? Also, I think I was using a x1 probe when I measured the oscillator.

To answer Bill's questions: It's not like I wanted to do it in Linux. The problem is that my computer is experiencing problems with Microchip's MPLAB and its PICKIT 2 flashing software in Windows also (they freeze regularly on my laptop). Even though the firmware using 1.21 is very old, pk2 only supports firmware version 1.2 and according to pk2, it supports PIC18F2620 under version 1.2. There is an alpha version of pk2 that supports firmware version 2 that's still in development mode. Maybe I can give that a try?

Btw, thank you for your continued attention on this issue. In the meantime, I am talking to the subscribers on sdcc mailing list and also Microchip technical support's help in looking at the hex files that got built.