| View previous topic :: View next topic |
| Author |
Message |
fvnktion
Joined: 27 Jun 2006
Posts: 39
|
| Pins refuse to go high? Code or hardware? |
 Posted: Fri Dec 12, 2008 5:01 pm |
 |
|
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
|
|
| Posted: Fri Dec 12, 2008 5:04 pm |
|
|
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
|
|
| Posted: Fri Dec 12, 2008 5:04 pm |
|
|
| 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
|
|
| Posted: Fri Dec 12, 2008 5:25 pm |
|
|
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
|
|
| Posted: Fri Dec 12, 2008 6:13 pm |
|
|
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
|
|
| Posted: Fri Dec 12, 2008 6:32 pm |
|
|
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
|
|
| Posted: Fri Dec 12, 2008 6:39 pm |
|
|
It's probably a RMW problem. (Read-Modify-Write).
How are you testing the result ? With a logic analzyer ? A Watch Window ? |
|
|
Guest
|
|
| Posted: Fri Dec 12, 2008 7:07 pm |
|
|
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
|
|
| Posted: Fri Dec 12, 2008 8:57 pm |
|
|
| Quote: | | then testing the actual with a meter. |
Does this mean you are single-stepping the code ? |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Dec 13, 2008 7:09 am |
|
|
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
|
|
| Posted: Sun Dec 14, 2008 8:43 pm |
|
|
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
|
|
| Posted: Mon Dec 15, 2008 3:06 am |
|
|
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
|
|
| Posted: Mon Dec 15, 2008 6:20 am |
|
|
| 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
|
|
| Posted: Mon Dec 15, 2008 12:50 pm |
|
|
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 |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
