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 CCS Technical Support
Pins refuse to go high? Code or hardware?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
fvnktion



Joined: 27 Jun 2006
Posts: 39

View user's profile Send private message

Pins refuse to go high? Code or hardware?
PostPosted: Fri Dec 12, 2008 5:01 pm     Reply with quote
Below is code that passes a byte of data and sets discrete preset port bits to the lower 4 values of the byte of data.

The code runs fine using Sim, but does not work well running in real time using ICD2.

When using Fast_io RA4 and RC0 are set but RA5 and RC1 are ignored.

When using standard io. It says that all are being set, but only RA4 and RC0 go high.

I am using vs. 4.057

Any suggestions?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Dec 12, 2008 5:04 pm     Reply with quote
Post your PIC and post a small test program. Show the #include, #fuses,
and #use delay() statements, and the rest of the program.
fvnktion



Joined: 27 Jun 2006
Posts: 39

View user's profile Send private message

PostPosted: Fri Dec 12, 2008 5:04 pm     Reply with quote
Code:

#include <18F4520.h>
#fuses INTRC,NOPROTECT,MCLR,NOBROWNOUT,BORV45,NOWDT,WDT128,NOPUT,NOSTVREN,NODEBUG
#fuses NOLVP,NOWRT,NOCPB,NOWRTB,NOWRTC,NOCPD,NOWRTD,NOEBTR,NOEBTRB
#fuses NOXINST   //extended cpu
#use delay(clock=4000000)


#bit RA4 = 0xf80.4
#bit RA5 = 0xf80.5
#bit RC0 = 0xf82.0
#bit RC1 = 0xf82.1

#use fast_io(A)
#use fast_io(B)
#use fast_io(C)


void byte_to_bit(char x){

//this does not work without fast io.

delay_cycles(1);

RA4 = x & 1;
RA5 = (x >> 1) & 1;
RC0 = (x >> 2) & 1;
RC1 = (x >> 3) & 1;

}

void main(){
char val2 = 1;

setup_oscillator(OSC_4MHZ|OSC_NORMAL);
set_tris_a(0x00);
set_tris_b(0x00);
set_tris_c(0x00);

output_a(0);
output_b(0);
output_c(0);

//test standard pin sets high low
//works without fast io
delay_cycles(1);
output_high(pin_a4);
output_low(pin_a4);
delay_cycles(1);
delay_cycles(1);
output_high(pin_a5);
output_low(pin_a5);
delay_cycles(1);
delay_cycles(1);
output_high(pin_c0);
output_low(pin_c0);
delay_cycles(1);
delay_cycles(1);
output_high(pin_c1);
output_low(pin_c1);
delay_cycles(1);


//test the #bit define values
//woirks without fast io
RA4 = 1;
RA4 = 0;

RA5 = 1;
RA5 = 0;

RC0 = 1;
RC0 = 0;

RC1 = 1;
RC1 = 0;



while(1){

byte_to_bit(val2);
val2 = val2<<1;

}//while
}//main
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Dec 12, 2008 5:25 pm     Reply with quote
Post a description of the external circuits that are connected to these
pins. Also post the value of the components in the circuits.
SherpaDoug



Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA

View user's profile Send private message

PostPosted: Fri Dec 12, 2008 6:13 pm     Reply with quote
Being a hardware guy I would unsolder the PIC pin and see what it does without a load. DIPs and SOICs are easy, but some packages ARE hard to unsolder just one pin.
_________________
The search for better is endless. Instead simply find very good and get the job done.
Guest
PostPosted: Fri Dec 12, 2008 6:32 pm     Reply with quote
Thanks for the input guys,

On the current board they are open circuit being tested with a meter.

Using a PIC18F4520 E\IP DIP 40. They are in a DIP socket and I have tried to switch one out with the same results.

I'll do some more trouble shooting on another board when i get back to the facilities.

It sure seems like it would work fine, but it has been one of those days.

Thanks
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Dec 12, 2008 6:39 pm     Reply with quote
It's probably a RMW problem. (Read-Modify-Write).

How are you testing the result ? With a logic analzyer ? A Watch Window ?
Guest
PostPosted: Fri Dec 12, 2008 7:07 pm     Reply with quote
Hmmm, not familiar with RMW ( read modify write). If this is the problem, how can it be tested and modified?

I am using a watch window to view the alleged data output and then testing the actual with a meter.

Interestingly, sometimes the watch value is not even correct. I believe when I am using fast IO.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Dec 12, 2008 8:57 pm     Reply with quote
Quote:
then testing the actual with a meter.

Does this mean you are single-stepping the code ?
Ttelmah
Guest
PostPosted: Sat Dec 13, 2008 7:09 am     Reply with quote
Obvious comment.
Do you have an external crystal?.
If not, you are turning off the oscillator, with:

setup_oscillator(OSC_4MHZ|OSC_NORMAL);

You don't need/want this. You have already told the code to use the internal oscillator with the fuses, and clock statement....

Best Wishes
donquixote



Joined: 21 Jul 2008
Posts: 15
Location: Shanghai, China

View user's profile Send private message

PostPosted: Sun Dec 14, 2008 8:43 pm     Reply with quote
Hi, guys,

I met the similar problem on pins not to being high or low with the output_high/output_low().

The chip is PIC24FJ128GA106, CCS Rev 4.80, and Mplab V8.15a. The testing code is attached below.

Code:

#include "24FJ128GA106.h"

#fuses HS, NOWDT, DEBUG, NOPROTECT, NOJTAG, IOL1WAY


void main()
{
   int c=0;
   
       do
   {
   output_high(PIN_B3);
                //output_low(PIN_B3);
                }while(1);   
}


Code is compiled correctly and downloaded into the chip via ICD2.

But the pin is not set to high when I use the Oscilloscope probe to test it.

Anyone could help me out?

Thanks in advance.
_________________
Don Quixote
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Mon Dec 15, 2008 3:06 am     Reply with quote
Yes, PCD V4.083 is still mixing up PIC24FJ128GA106 SFR addresses
.................... output_high(PIN_B3);
05470: BCLR.B 2C6.3 ; THIS IS TRISA, TRISB WOUL BE 2C8
05472: BSET.B 2CA.3 ; CORRECT

Regards,
Frank
donquixote



Joined: 21 Jul 2008
Posts: 15
Location: Shanghai, China

View user's profile Send private message

PostPosted: Mon Dec 15, 2008 6:20 am     Reply with quote
FvM wrote:
Yes, PCD V4.083 is still mixing up PIC24FJ128GA106 SFR addresses
.................... output_high(PIN_B3);
05470: BCLR.B 2C6.3 ; THIS IS TRISA, TRISB WOUL BE 2C8
05472: BSET.B 2CA.3 ; CORRECT

Regards,
Frank


Hello, Frank,

Thanks for your checing.

And I also do the pin setting with assembly code to verify it this afternoon.

Seems the output_high function is wrong.

I would like to fix this bug with my own assembly code and also considering to migrate the code from CCS IDE to Mplab IDE with Microchip C compiler.

I am afraid of the unexpected bugs in the future.

Regards,
_________________
Don Quixote
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Mon Dec 15, 2008 12:50 pm     Reply with quote
The best way to fix the bug is to define #bit SFR bits and assign values to it in C code, I think.

CCS has acknowledge the bug and said it's fixed in the next version.

You should expect some more PCD bugs, I fear.

Best regards,
Frank
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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