PIC18F2620 not being able to self-execute control code - Page 2 - Electronic Circuits Projects Diagrams Free

ssylee · 14th October 2007, 01:00 AM

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 · 15th October 2007, 05:45 PM

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** · 16th October 2007, 09:21 AM

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 · 16th October 2007, 03:13 PM

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 · 16th October 2007, 05:41 PM

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.

ssylee · 19th October 2007, 05:59 AM

Got word from Microchip technical support. It seems that the problem could be with pk2, the command line software that's responsible for communicating between my computer to the PIC microcontroller in Linux. So Bill has a strong point there. I think what happened with the PICKIT 2 software from Microchip was that I didn't connect some of the pins properly, resulting in a program freeze. Other than that, I just found that that flasher software was resource-consuming, hence the reason of doing so in Linux instead. I will further look into pk2 and sdcc before I make the switch again to developing the control code in Windows. Thanks for your help.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Title	Starter	Forum	Replies	Latest
Accessing EEPROM	Clayton	Micro Controllers	15	23rd March 2007 04:00 AM
Need PIC16F84A Cool Project	Agent 009	Micro Controllers	158	11th March 2007 07:15 AM
Motor control interface	dreamproject	Micro Controllers	0	31st March 2005 04:48 AM
PIC16F84A Code Protect	gatas	Micro Controllers	3	21st July 2003 03:44 PM
Remote control code grabber	nonzero	Electronic Projects Design/Ideas/Reviews	5	20th July 2003 05:02 PM

14th October 2007, 01:00 AM	(permalink)
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!

15th October 2007, 05:45 PM	(permalink)
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.

16th October 2007, 09:21 AM	(permalink)
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. __________________ PIC programmer software, and PIC Tutorials at: http://www.winpicprog.co.uk

16th October 2007, 03:13 PM	(permalink)
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. __________________ Bill Smart Kits build Smart People http://www.blueroomelectronics.com Last edited by blueroomelectronics; 16th October 2007 at 03:16 PM.

16th October 2007, 05:41 PM	(permalink)
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.

19th October 2007, 05:59 AM	(permalink)
ssylee	Got word from Microchip technical support. It seems that the problem could be with pk2, the command line software that's responsible for communicating between my computer to the PIC microcontroller in Linux. So Bill has a strong point there. I think what happened with the PICKIT 2 software from Microchip was that I didn't connect some of the pins properly, resulting in a program freeze. Other than that, I just found that that flasher software was resource-consuming, hence the reason of doing so in Linux instead. I will further look into pk2 and sdcc before I make the switch again to developing the control code in Windows. Thanks for your help.