CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Zany 16F88 problem.
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
theMagni



Joined: 21 May 2004
Posts: 48
Location: Victoria, BC

View user's profile Send private message Visit poster's website

Zany 16F88 problem.
PostPosted: Fri Feb 11, 2005 11:27 am     Reply with quote

Okay, this one is a doozy. First, a text summary:

I'm using the 16F88 and compiler version 3.218. The chip is connected to a GPS module and a VHF transmitter. Besides the RS232 connections, there is a VHF_MOD line and a CS_GPS line. The code has no problems getting a GPS fix, and when it gets a GPS fix, it sends a little signal over VHF.

When the VHF line sends its signal, it turns off the CS_GPS line. That's bad. When I comment out the vhf_chirp() command, the program runs fine. Also, when I comment out the comparator setup lines, the program ALSO runs fine.

The comparator is an issue because I ran out of pins and had to use some of the comparator pins as interruptable inputs. On the 16F88, A3:A0 are used as the comparator inputs. I've configured it to use A0 and A1 as the comparator inputs, A2 and the A/D converter, and A3 as the CS_GPS line. The VHF_MOD is on A4.

So, why is the CS_GPS line going low? It just doesn't make any sense to me whatsoever. I've checked the ASM list, and there are no extra calls to BCF 05.3 - NONE!

If any of you can shed any light on this, I'd be quite happy. So would my boss, because we wouldn't have to think about buying a more expensive compiler. Bascially, everything started going to hell when we upgraded so we could work on the 10F20X chips.

I took out the code here for clarity - there's a much simpler snippet lower in the thread. Thanks for looking.
_________________
In the 90's, I promised myself I'd never use a so-called "smiley icon". I hate what I've become. ;)


Last edited by theMagni on Fri Feb 11, 2005 6:22 pm; edited 1 time in total
dyeatman



Joined: 06 Sep 2003
Posts: 1923
Location: Norman, OK

View user's profile Send private message

PostPosted: Fri Feb 11, 2005 12:25 pm     Reply with quote

Have you checked to see how CM2:CM0 in the CMCON register are being configured? According to the data sheet page 122 they have to be set 011 (or 010 with CIS=0). If they are set 110 then the A3 is the C1OUT pin.

You dont show enough to know if the Port A is set for FAST_IO. I would use FAST_IO and a TRIS statement to set the pin directions.

I have had a few cases where the compiler tried to manage the pins and caused this type of problem so I always use FAST_IO and TRIS to set my pin directions.


Last edited by dyeatman on Fri Feb 11, 2005 12:50 pm; edited 1 time in total
theMagni



Joined: 21 May 2004
Posts: 48
Location: Victoria, BC

View user's profile Send private message Visit poster's website

Comparators
PostPosted: Fri Feb 11, 2005 12:42 pm     Reply with quote

The only way to use the internal reference voltage is to set the comparators up in 010 mode. I absolutely must use the internal reference voltage, and I don't have the pin to spare to put Vref on A2.

I'm not really sure what drugs they were taking when they designed this chip, but they must have been expensive and powerful.
_________________
In the 90's, I promised myself I'd never use a so-called "smiley icon". I hate what I've become. ;)
dyeatman



Joined: 06 Sep 2003
Posts: 1923
Location: Norman, OK

View user's profile Send private message

PostPosted: Fri Feb 11, 2005 12:51 pm     Reply with quote

Sorry, I edited my input just as you posted.. here is my other thought....

You dont show enough to know if the Port A is set for FAST_IO. I would use FAST_IO and a TRIS statement to set the pin directions.

I have had a few cases where the compiler tried to manage the pins and caused this type of problem so I always use FAST_IO and TRIS to set my pin directions.
theMagni



Joined: 21 May 2004
Posts: 48
Location: Victoria, BC

View user's profile Send private message Visit poster's website

TRIS
PostPosted: Fri Feb 11, 2005 1:14 pm     Reply with quote

Oh yeah, I set my own. I don't trust the compiler to do that sort of work for me. I'm using SPI and RS232. I'd hate to see what the compiler would try to do. (One of the pins is RS232 RX and SDO).

I'll just double-check and ... gah. standard IO? Let's fix that and test. Okay, I swtiched over to fast_io( a ) and the problem is still there. Good catch, though.

Based on what you said, I set pins A3 and A4 (CS_GPS and VHF_MOD) as fixed_io outputs. The bug is still there. What the hell is going on here?
_________________
In the 90's, I promised myself I'd never use a so-called "smiley icon". I hate what I've become. ;)
dyeatman



Joined: 06 Sep 2003
Posts: 1923
Location: Norman, OK

View user's profile Send private message

PostPosted: Fri Feb 11, 2005 1:54 pm     Reply with quote

Just to clarify, the A3 pin works sometimes and just goes low at the wrong time or does it go high at all?

Just to rule things out and narrow down the problem, is there any way you can trigger another pin in parallel temporarily to see if it works correctly there? (i.e. when you set/clear A3 also set/clear some other open pin at the same time).

If both pins always keep the same state you have some kind of logic problem. If they dont you may have a chip problem.

This would help you determine if another piece of code somewhere, or maybe a comparator circuit problem is causing the problem.

FWIW....
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Feb 11, 2005 2:30 pm     Reply with quote

My suggestion is to write a small program that demonstrates the
problem, and doesn't contain any proprietary code. Then you can
post the complete program here and we can analyze it.
theMagni



Joined: 21 May 2004
Posts: 48
Location: Victoria, BC

View user's profile Send private message Visit poster's website

Clarification
PostPosted: Fri Feb 11, 2005 5:02 pm     Reply with quote

Yes, the CS_GPS line does go on until the position fix is found. Then, when the VHF signal indicating that the position was sent, the CS_GPS line went low. As far as I can tell, the interrupts on the comparator

This has been a problem with the GPS lines in this 16F88 with every version of the CCS Compiler since version 3.212. At least, it has been on this end. Previous incarnations have checked CS_GPS instead of using GPS_KEEP_SEARCHING.

In order to get the units out the door, I got production to put in a bodge fix by bridging a wire across 2 pins. Luckily, this particular order doesn't require the use of that one pin(B6) but the next order does, so the same fix won't work. I have to find out what the software fix is.

PCM, once I get a chance, I'll post a version of the code that is small enough to understand and still exhibits the problem.

Uh, if I seem grouchy, it's because it's been a long day and a long week.
_________________
In the 90's, I promised myself I'd never use a so-called "smiley icon". I hate what I've become. ;)
theMagni



Joined: 21 May 2004
Posts: 48
Location: Victoria, BC

View user's profile Send private message Visit poster's website

Failure code
PostPosted: Fri Feb 11, 2005 6:09 pm     Reply with quote

As requested, here's some code that fails. When I call the vhf_chirp() function, the CS_GPS line turns off. Here's the code:

Code:

/*********************************************************************
** failure.c    Version 100                                        **
** 11 Feb 2005                                                     **
** Magnus McElroy                                                  **
**                                                                 **
** This program is designed to test why the CS_GPS line goes low   **
** when it is tested or when the VHF_MOD line is used.             **
********************************************************************/



/********************************************************************
                           DEFINITIONS
********************************************************************/
/* General purpose definitions */
#define LOW           0
#define HIGH          1

/* Tristate Definitions */
//0 is output, 1 is input.
#define RS232_MODE    0b01000111
#define SPI_MODE      0b01000011



/********************************************************************
                         DEVICE DIRECTIVES
********************************************************************/
#include "16F88.H"              //required by the compiler.
#fuses INTRC_IO, WDT, PUT, NOPROTECT, NOBROWNOUT, MCLR, NOLVP, WRT

//With the restart_wdt in the RS-232. it can take a monent to get a
//character. Putting the reset in the delay causes issues.
#use delay( clock=4000000 )


/********************************************************************
                            INCLUDES
********************************************************************/
//#include "A127.h"
/* Port A */
#byte PORT_A        = 0x05
#bit  REED          = PORT_A.0 //pullup
#bit  AD_IN         = PORT_A.1 //pullup
#bit  COMP_IN       = PORT_A.2 //pullup
#bit  CS_GPS        = PORT_A.3
#bit  VHF_MOD       = PORT_A.4
#bit  MCLR          = PORT_A.5
#bit  MORT          = PORT_A.6 //pullup
#bit  CS_RTC_READ   = PORT_A.7

/* Port B */
#byte PORT_B        = 0x06
#bit  INTR          = PORT_B.0 //pullup
#bit  SDI_SDA       = PORT_B.1
#bit  SDO_RX        = PORT_B.2
#bit  CS_RTC        = PORT_B.3
#bit  SPI_CLK       = PORT_B.4
#bit  TX            = PORT_B.5
#bit  RTS           = PORT_B.6
#BIT  CS_SEEPROM    = PORT_B.7


#byte OSC_CON     = 0x8F
#byte TRIS_A      = 0x85
#byte TRIS_B      = 0x86
#byte COMREF      = 0x9D
#byte OPTION      = 0x81
#byte ANSEL       = 0x9B
#byte WDTPS       = 0x105

int1 initialize( void );

void vhf_chirp( int chirps )
{
  do
  {
    VHF_MOD = HIGH;
    delay_ms(18);
    VHF_MOD = LOW;
    delay_ms(50);
    chirps--;
  }while( chirps > 0 );
}


/********************************************************************
                         GLOBAL VARIABLES
********************************************************************/
int1 MAGNET_ON;


/********************************************************************
                         PROGRAM BEGINS
********************************************************************/
main()
{
  int1 status = 0;

  status = initialize();

  restart_wdt();

  do
  {
    restart_wdt();
    OSC_CON = 0b01100010; //(4MHZ mode)

    TRIS_A = 0b01100111;
    TRIS_B = SPI_MODE;

    //sets the WDT (in conjuction with the prescaler) for 4:28. That's
    //more than the max sleep time.
    OPTION |= 0x0F;
    WDTPS = 0b00010111;
    restart_wdt();

    //This simple test should either turn the GPS line off right away
    //if there's a bug or leave it on for 20 seconds if there is none.
    CS_GPS = HIGH;
    delay_ms( 2000 );
    vhf_chirp(3);
    delay_ms( 20000 );
    CS_GPS = LOW;
    restart_wdt();

    sleep();
  }while( true ); //always loop.
  //Just in case the uP exits, reset and start the code over
  //again from the beginning.
  reset_CPU();
  return( 0 );
}//end of main()



/********************************************************************
                        FUNCTIONS BEGIN
********************************************************************/



//initialize()
//Magnus McElroy
//24 Sept 2004
//This function moves a lot of code away from the main program so it's
//easier to understand.
int1 initialize( )
{
  int1 status;
  //initialize. Set the tristating, the oscillator, etc.
  //setup_oscillator( OSC_4MHZ );
  OSC_CON = 0b01100010;
  //set the prescaler to the maximum amount and assign it to the WDT.
  OPTION |= 0x0F;
  //set the WDT to the maximum available. This times it out for 268
  //seconds. (4 min, 28 sec) That's more than the current sleep time.
  WDTPS = 0b00010111;
  restart_wdt();

  //set up the comparator
  //CMCON = 0b00000010;
  setup_comparator( A0_VR_A1_VR );
  //set the voltage reference for about 1/2 way.
  COMREF = 0b10000111;
  enable_interrupts( int_comp );
  //enable_interrupts( int_rb );
  enable_interrupts( global );
  //Change the GPS pin from default analog to digital. I think that
  //0 makes it digital, but it's not clear at all. The only ones that
  //should be analog are the reed switch (to fool the comparator), the
  //SW switch, and the A/D in. (A0. A1, A2) A4 and A3 must be digital
  //since they are the VHF_MOD and CS_GPS lines.
  SETUP_ADC_PORTS( NO_ANALOGS );
  ANSEL = 0b00000111;

  //Flash a set of 0s to all pins to reset devices and clear all
  //possible conflicts. Resets to the proper tristating after the
  //flash and starts in the correct mode for normal operation.
  TRIS_A = 0b00000000;
  TRIS_B = 0b00000000;
  PORT_A = 0b00000000;
  PORT_B = 0b00000000;

  TRIS_A = 0b00100101;
  TRIS_B = SPI_MODE;
  PORT_A = PORT_A;
  PORT_B = PORT_B;

  CS_GPS = LOW;
  CS_SEEPROM = HIGH;
  CS_RTC = LOW;
  VHF_MOD = LOW;
  CS_RTC_READ = LOW;
  //RTS = LOW;
  PORT_B = PORT_B;

  //Wait for a moment to let the interruptable pins settle down. This
  //will prevent the interrupts from keeping the GPS off.
  PORT_B = PORT_B;
  delay_ms( 200 );
  VHF_MOD = HIGH;
  delay_ms( 350 );
  VHF_MOD = LOW;
   delay_ms( 200 );
  VHF_MOD = HIGH;
  delay_ms( 350 );
  VHF_MOD = LOW;
  delay_ms( 200 );
  VHF_MOD = HIGH;
  delay_ms( 350 );
  VHF_MOD = LOW;
  CS_GPS = LOW;
  //SURFACED = TRUE;
  restart_wdt();
  return( status );
}



/********************************************************************
                    INTERRUPT SERVICE ROUTINES
********************************************************************/
//magnetic_interference()
//Magnus McElroy
//20 Aug 2004
//This function checks the comparator to see if the reed switch has
//been activated. Rush: Don't check the comparator. Check RB6, the
//RTS line. (It must be set as an input, always!) Changed its name
//to MAGNET_INT
#int_comp
void magnetic_interference()
{
  OSC_CON = 0b01100010;
  //The comparator has just been triggered. Set the MAGNET_ON
  //to sync with the comparator. The reed switch is on A0, and that
  //is comparator one. The pin will go low when the reed switch is
  //activated, so the negative rail of the comparator will go below
  //the positive rail, making C1 out low.
  MAGNET_ON = C1OUT;
  //CS_GPS = FALSE;
}


_________________
In the 90's, I promised myself I'd never use a so-called "smiley icon". I hate what I've become. ;)


Last edited by theMagni on Mon Feb 14, 2005 10:30 am; edited 2 times in total
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Feb 11, 2005 7:40 pm     Reply with quote

I don't want to offend you, but this file doesn't compile "as is".
I sitting here and starting to make a whole lot of changes
in order to get it to compile, and doing so makes it less likely
that I'll find the real problem.

For example, what if your function prototype is different
than the one that I might create. Yes, the compiler should
give an error if the prototype doesn't match the function,
but what if it doesn't ?

Another example: The compiler complains with this message:
Undefined identifier OSC_CON
Somewhere, you have a #byte statement for that value.
I could add it by looking at the data sheet, but it might not
be exactly what you're using, and that might be where the
problem is.

If you can, please post code that shows the problem, and that I can
drop into MPLAB and compile without change.
adrian



Joined: 08 Sep 2003
Posts: 92
Location: Glasgow, UK

View user's profile Send private message

PostPosted: Mon Feb 14, 2005 6:55 am     Reply with quote

I may be barking up the wrong tree here, but I dont see you clearing the comparator interrupt by reading CMCON
theMagni



Joined: 21 May 2004
Posts: 48
Location: Victoria, BC

View user's profile Send private message Visit poster's website

Sorry.
PostPosted: Mon Feb 14, 2005 10:35 am     Reply with quote

Sorry, PCM. I was out of line posting that. It was pretty busy here on Friday. I've changed the code in my previous post to be one file without any includes. That should cut and paste and run.

Thanks for your help.
_________________
In the 90's, I promised myself I'd never use a so-called "smiley icon". I hate what I've become. ;)
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Feb 14, 2005 12:28 pm     Reply with quote

Just letting you know that I'm looking at your code now.
It may take a while. I'm going through it methodically.
Of course, others are free to comment if you see something.

-----
I do have one quick question. If you disable the watchdog timer,
does the problem go away ? This would save me some time, if
I knew the answer to that.
theMagni



Joined: 21 May 2004
Posts: 48
Location: Victoria, BC

View user's profile Send private message Visit poster's website

WDT -> no effect
PostPosted: Mon Feb 14, 2005 1:12 pm     Reply with quote

PCM:

I disabled the WDT and commented out the OPTION and WDT lines. The problem still exists.

Take your time; I've been trying to find an answer to this bad boy for months. Looking over my records, I've had some version of this bug since the beginning of December 2004.
_________________
In the 90's, I promised myself I'd never use a so-called "smiley icon". I hate what I've become. ;)
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Feb 14, 2005 4:23 pm     Reply with quote

I have a few more questions:

1. What is your Vdd voltage for the PIC ?

2. What are these signals ?

REED

AD_IN

COMP_IN


A. What devices or components are connected to these pins ?

B. What voltage levels do these devices apply to the PIC pins ?
(Example: If the first one is a Reed switch, what is the high
level voltage and what is the low level voltage that comes
from this switch ?)

C. If there are pull-up resistors on these pins, what are the resistor
values and what is the pullup voltage ?

----------------
Additional thoughts:

Right now, I think it might be a Read-Modify-Write problem.
I have a question about the CS_GPS signal. I assume that
it goes to the GPS unit. Can the GPS ever pull that signal
down to zero volts ? Is the GPS permanently powered-on ?
Is it possible that the GPS gets powered-down, and then
pulls the CS_GPS line down to a low level ?

I'm going to add a 16F88 onto an existing order that I'm doing
anyway, and when it comes in (Wednesday) I'll test it in hardware.
So you might have to wait until then. (Unless someone else comes
up with the answer first).
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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