| View previous topic :: View next topic |
| Author |
Message |
ZuLu
Joined: 13 Sep 2013
Posts: 3
|
| Time delay between power up and main function [Solved] |
 Posted: Tue Sep 17, 2013 5:46 am |
 |
|
Hello my friends,
I have PIC18F8723 micro controller in my circuit, this MCU controls inhibit of main power supply. When MCU power supply is stand up, I could not control any ports earlier than 63msec. Minimum time delay of controlling a port in main function is 63msec as shown. In scope screen yellow signal is pin of MCU, green signal is MCU power supply.
How can i control any ports just after power up?I want to shorten this delay as soon as possible.
Fuses: | Code: | #FUSES NOWDT //No Watch Dog Timer
//#FUSES HS //Low power osc < 200 khz
#FUSES INTRC_IO //Internal Oscillator enabled LEBC
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT
//!#FUSES BROWNOUT //brownout reset enabled LEBC
//!#FUSES BORV42 // 4.2'de reset olacak
#FUSES NOPUT //Power Up Timer enabled
#FUSES NOCPD //No EE protection
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOCPB //No Boot Block code protection
#FUSES MCLR //Master Clear pin enabled |
Main function summary:
| Code: | void main()
{
set_tris_E(0x00);
output_E(0x80);
...
} |
I fixed it
#zero_ram statement had been coused this delay. I remove this statement. Now i can control ports as soon as power comes.
Thanks.
Last edited by ZuLu on Thu Sep 19, 2013 2:43 am; edited 1 time in total |
|
 |
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Tue Sep 17, 2013 7:23 am |
|
|
since all I/O on the pic wakes up as tri state - you need to add a pull up or pull down resistor to the critical control pins until your program is ready to assert control. This is PIC safety 101 
also for best practice, set the desired initial state of the control pin BEFORE the set_tris operation......... |
|
|
alan
Joined: 12 Nov 2012
Posts: 357
Location: South Africa
|
|
| Posted: Tue Sep 17, 2013 8:17 am |
|
|
So true asmboy, got bitten nicely by not setting the output before setting the tris, everything went up in smoke about 2 times before I figured that one out.
Regards |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Sep 17, 2013 10:31 am |
|
|
Also many PICs start up on an internal clock source and run some initialisation code before the main clock source is stable. That means it won't run at the expected speed during start-up, often running slower for some considerable time, making delays much longer than expected.
I got caught by this on a PIC18F4580 and had to detect the change from slow internal to the faster PLL-multiplied main clock source:
| Code: |
// Wait for the crystal to stabilise. Before it does, we're on the default
// 1MHz internal clock which confuses the start-up timing.
// This is not needed and is just here to ensure we get normal timing from start-up.
while ((setup_oscillator() & OSC_STATE_STABLE) == 0);
|
Something like this might well be needed for other PICs. It won't speed up the start-up. It just waits for the main clock to kick in to ensure delays and baud rates are as expected. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Sep 17, 2013 1:39 pm |
|
|
| Quote: | | time delay of controlling a port in main function is 63msec as shown. |
The 18F8723 data sheet shows a power-up delay of 64 ms for the
internal oscillator (INTRC_IO), if you have the PUT fuse enabled.
But you have NOPUT. Or do you ?
You should your complete current test program, not snippets of it.
Post the #include line for the PIC. Post the #use delay() statement.
Post a small compilable program.
And post your full CCS version number, which will be in this format: x.xxx
Examples of version numbers:
http://www.ccsinfo.com/devices.php?page=versioninfo |
|
|
ZuLu
Joined: 13 Sep 2013
Posts: 3
|
|
| Posted: Wed Sep 18, 2013 4:36 am |
|
|
I finally successed to control any port just after power up.
"#zero ram" statement had been caused that delay. I remove #zero ram preprocessor statement and now i can control ports as soon as MCU power stands up. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Wed Sep 18, 2013 4:51 am |
|
|
It is worth realise just how much 'work' #zero_ram involves. On this chip, nearly 4000 RAM locations have to be cleared.....
No wonder it took a long time.
Goes back to always post a small _complete_ program that shows the problem. You left this directive out in what you posted, and every experienced user here would instantly have said 'several thousand instructions here'....
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
