|
|
View previous topic :: View next topic |
Author |
Message |
perthcom
Joined: 10 Jun 2005 Posts: 10
|
Something is not initalizing right here. CCS PCW 3.225 |
Posted: Tue Oct 24, 2006 10:40 am |
|
|
I've been scratching my head over this for a week now. I'm using a 16F870 with opto couplers on PortA inputs and an open collector driver on PortC ouputs. Port B is unused and is held high with 1k resistors. I also have LED's through 1k resistors on Port C to monitor the output.
Right now i've reduced the code to just counting up over and over and displaying the binary outputs on Port C.
What's happening is after sitting powered off for several hours, the circuit will operate eratically. it will count up to maybe 30-100 then its like the WDT resets. Also the port B input acts like its set to output as the pullup resistors are being held low, I've pulled the opto-isolators so all there is left is the pullups.
After power-cycleing the circuit a couple times it will start to work as expected and will continue to start and work fine until left OFF for a few hours again. I've tried 4 new chips, all do this.. even a chip that was working fine in another circuit, reprogram it and it acts up too.
I'm sure I'm not initalizing something correctly as once it works its fine. I used the Start-Up wizard to setup the chip in the begining. I've also copied the contents of the header file over to the main C program .
Here is what I have stripped the program down to and still no luck, even this won't start and run after a few hours.
I know i'm using fast I/O with the TRIS command, but I like to use byte-wide inputs and outputs at times.
Code: |
#include <\program files\picc\devices\16F870.h>
#device adc=8
#fuses WDT,XT, PUT, PROTECT, NODEBUG, BROWNOUT, noLVP, noCPD, noWRT
#use delay(clock=3570000,RESTART_WDT)
#ZERO_RAM
#use fast_IO(a)
#use fast_IO(b)
#use fast_IO(c)
//Inputs
#bit channel_busy = 5.0
#bit CTS = 5.1
#bit alarm_in = 5.5
//Port b unsed, but pulled high
#byte unused_b = 6
//Outputs
#byte outputs = 7
#bit channel_steer = 7.0
#bit monitor = 7.1
#bit PTT = 7.3
#bit CTS_out = 7.5
#bit busy_out = 7.6
#bit busy_channel = 7.7
void main()
{
int cntr,alarm_cntr,CTS_cntr;
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_timer_0(RTCC_INTERNAL);
setup_wdt(WDT_2304MS);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_ccp1(ccp_off);
SET_TRIS_A(0b00011111);
// SET_TRIS_B(0b00000000);
SET_TRIS_B(0b11111111);
SET_TRIS_C(0b00000000);
delay_ms(100);
channel_steer = 0;
PTT = 0;
monitor = 0;
delay_ms(1000);
cntr = 0;
WHILE(true)
{
RESTART_WDT();
delay_ms(100);
++cntr;
outputs = cntr;
}
}
Can anyone help?
thanks
:cool: |
|
|
|
Ttelmah Guest
|
|
Posted: Tue Oct 24, 2006 10:51 am |
|
|
First, try restarting the watchdog timer, after changing it's prescaler. The watchdog has been running from the moment the chip booted, and initially is running without the prescaler. There is a _lot_ of time involved in the boot, since you have '#zero_ram' selected, which means every RAM location is cleared. The watchdog may be expiring in the long delays before the main loop.
Best Wishes |
|
|
perthcom
Joined: 10 Jun 2005 Posts: 10
|
|
Posted: Tue Oct 24, 2006 11:54 am |
|
|
I put RESTART_WDT() right after I set up the WDT prescaler, no difference, so then I took out the #ZERO_RAM and it still doesn't work correctly.
In the project file, when compaired to another working project, the working project show the entire path to the file under Include = , [MRU-List] and [Windows]. Not sure if that makes any difference, it compiles Ok.
GRRRRRRRRR!
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Oct 24, 2006 12:54 pm |
|
|
Quote: |
What's happening is after sitting powered off for several hours,
the circuit will operate erratically. |
This sounds like a power-on startup problem.
1. I would get rid of the Watchdog timer. It's just adding confusion
at this point.
2. Your test program could be stripped down a heck of a lot more.
You could get rid of all that Wizard stuff that turns off the Timers,
the CCP, the PSP, etc. Those modules are 'off' by default.
3. If it was me, I would get rid of all the #fast_io statements and
all the setup_tris_x() statements. I would use CCS i/o functions
and let the compiler handle the TRIS. It's far less error-prone, to
do it this way.
4. You have a large number of external circuits that can potentially
supply power to the PIC through the upper protection diodes which
are on the i/o pins. Most people try to avoid this. They let the PIC
supply the power to the LEDs, for example. (LED Cathode goes to
ground). In your particular case, this may or may not be causing
a problem, but seeing it in your post -- it raises a red flag to me.
5. Read the links given in the following post, regarding random resets.
http://www.ccsinfo.com/forum/viewtopic.php?t=27638&start=4 |
|
|
Guest
|
|
Posted: Tue Oct 24, 2006 3:37 pm |
|
|
DOHHHH!!!
What a silly willy I am!!
My main input is Alarm_in = 5.5, but in my SET_TRIS_A(0b00011111), I have that set to an output!!
changing it to SET_TRIS_A(0b00111111) so its an input fixed it..
My LED's are between the PIC and the TD62083 driver IC's and the opto isolators pull the inputs to ground so I'm not driving external voltages into the PIC.
I haven't been sucessful in using the port byte-wise without using the SET_TRIS command.
Thanks all for your help!
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Oct 24, 2006 4:04 pm |
|
|
Quote: | I haven't been sucessful in using the port byte-wise without using the SET_TRIS command. |
I meant using the pin i/o functions, such as output_low() and
output_high().
To make those functions work, you should use standard i/o mode.
This is the default mode of the compiler. Don't use a fast_io()
statement.
For example, suppose you have a program like the following.
If you use #fast_io, the output statement won't work.
Code: | #include <16F877.h>
#fuses XT, NOWDT, NOPROTECT, PUT, BROWNOUT, NOLVP
#use delay(clock=4000000)
#use fast_io(B)
//========================
int main ()
{
output_low(PIN_B0);
while(1);
} |
Here's the .LST file. Notice that it doesn't set the TRIS. Because the
PIC pins are set to inputs at power-on reset, they remain in that state.
The code below sets the output latch to a 0, but it doesn't affect the
state of the pin because it's still configured as an input.
Code: |
.... output_low(PIN_B0);
000C 1283 00305 BCF 03.5 // Bank 0
000D 1006 00306 BCF 06.0 // PortB.0 = 0
|
If you remove the #use fast_io(B) statement above and re-compile,
you get the following code. Now it sets the TRIS to make the pin into
an output before it writes to the latch. (Bank 1 was selected for the
TRIS statement in a line above this code, that I didn't show).
Code: |
.... output_low(PIN_B0);
000C 1006 00303 BCF 06.0 // TRISB.0 = output
000D 1283 00304 BCF 03.5 // Bank 0
000E 1006 00305 BCF 06.0 // PortB.0 = 0
|
If your CCS pin i/o functions are not working properly, it may be
because you have fast_io statements in your program. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|