Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Help me with my code (CCS) for testing a PIC

Status
Not open for further replies.

rpisharody

Junior Member level 1
Joined
Mar 20, 2007
Messages
19
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,420
PIC Behaving strange

I wrote the following code on CCS C compiler for testing a PIC16LF877A..

void main() {
set_tris_a(0xFF); set_tris_b(0x00); set_tris_c(0x00);

while(1) {
output_bit(PIN_B1, 1);
output_bit(PIN_B2, 0);
}
}

Can anyone point out what is wrong in this code ?

Reagrds,
Rahul
 

Re: PIC Behaving strange

What makes you think the code is wrong?

What is the strange behaviour of PIC?

Cheers,
 

Re: PIC Behaving strange

a story , no question on story , no conclusion at the end of story.

any way !

problem may be at the bank/page selection !

in your code there is no bank selection line >>>>>>>>>

i am not c programmer for pic , but i guess .

port a = input port
port c = output port
port b = output port
 

PIC Behaving strange

i don't think that writing in C requires bank switching.

and the code is wrong, because you use functions which do ... something (; but probably you don't know exactly what. what is the purpose of writing set_tris(), if you can do the same thing by just writing: TRISx = 0x00 (of course only when the compiler is not so stupid to forbid that). the same goes for assigning some values for ports.

0x41 0x56 0x45!!
 

Re: PIC Behaving strange

namqn,

I'm not sure that the code is wrong. Somebody pointed out that the code may be wrong. So I thought that I would rather post the code here, so someone can point out the errors, if there are. As of the strange behaviour, the PIC is not lighting up a LED connected at pin b1. It usually does if written in this way as I have done it in the past. But I'm new to C. I've tried both BASIC and assembly to some extent.

manish12,

Sorry for the weird format of the question! I was a bit busy and so didn't think of those things while posting this here. Many thanks on your patience to read and understand this ! As "Freddie Chopin" pointed out, no bank selection is required in CCS C.

Freddie Chopin,

As I said earlier I'm new to PIC programming in C. So I'm learning the functions as it is required. I found out the set_tris_x() function from the CCS C product manual and I'm using it. So I guess it is right ? Thanks for replying. I'll try what you suggested. ie, writing "TRISx = ". In the mean time, can you think of any other probable errors relating with architecture or something ?
 

Re: PIC Behaving strange

Try this

Code:
void main()
{ 
set_tris_a(11111111);   // 1 for Input and 0 for Output, this is easy to remember
set_tris_b(00000000);
set_tris_c(00000000); 

while(1) { 
              output_high(PIN_B1);
              output_low(PIN_B2);
             } 
}

but what's in anyway you are assigning Port A and Port C, you are not using them in your code?

So this line isn't necessary in your program.

Code:
set_tris_a(0xFF); set_tris_b(0x00); set_tris_c(0x00);
 

Re: PIC Behaving strange

I've not used the tris_x(11111111) format.
But I have tried output_high() function. I don't whether it is the reason, but when I do that, the PIC doesn't light up the led. But if i pull the Vss connection and put it rght back, the led lights up !!!!

Any idea ?
And does anyone think of something thats badly configured in the program ??
 

PIC Behaving strange

if you know assembly, that would be easy for you to check the disassembly listing and check whether it looks good.

0x41 0x56 0x45!!
 

Re: PIC Behaving strange

Hello,

there is nothing wrong with the original code. If you don't have a #USE_FAST_IO statement in your code, the preceeding set_tris_x() isn't necesarry to drive pin B1 and B2.

As an additional remark, it causes no visible action to repeat the output_bit() function in a loop. If you want to stop further PIC action at this point, you could use an empty while(1) {}; as well. Or do a simple program that creates an alternating LED indicator:
Code:
while(1) { 
output_bit(PIN_B1, 1); 
output_bit(PIN_B2, 0); 
delay_ms(500);
output_bit(PIN_B1, 0); 
output_bit(PIN_B2, 1); 
delay_ms(500);
}
It could be, that the issue isn't from code, but from wrong connection of LEDs. Also, some #fuses settings could be necessary to operate your processor. But CCS has a lot of example code, that should help. To my option, it's operation is straightforward. To debug your code, you could use the ICD debugger. Or integrate CCS with Microchips MPLAB IDE (it could be downloaded for free) and use the excellent simulator.

Regards,
Frank
 

Re: PIC Behaving strange

Thank you Frank, for your wonderful reply.
Further, I would like to know what are those internal fuses that you talked about to make the
PIC work ??
 

PIC Behaving strange

fuses is a term saying that FvM probably uses AVR [; in PICs there are some configuration bytes/words in the upper program memory space specific for each family and model of the uC. they define such things as selected oscillator, the function of MCLR pin, Low Voltage Programming etc. check the manual of your compiler and the datasheet of your PIC for details.

0x41 0x56 0x45!!
 

PIC Behaving strange

Microchip used to call them fuse bits on the old OTP parts. As like a fuse once they were blown they could not be reset. Now they're simply called config bits, they simply preset the microcontroller with power up defaults. (ie oscillator type, brownout, WDT etc...)
 

Re: PIC Behaving strange

Hello,

I was particularly referring to CCS PIC compiler, which has a #fuses keyword to define Microchip configuration bits, cause Rahul uses CCS. You're correct so far, that I'm using PIC only among other processors, including AVR. Thus I didn't think about CCS using a term uncommon to Michrochip. But in contrast, I know about CCS compiler and the meaning of PIC specific built-in functions.

There are a few option bits essential for a design, e. g. selection of oscillator configuration, watchdog activation, function of MCLR pin. Others are dealing with special features that wouldn't prevent a design from operation, e. g. brownout detector threshhold, startup timer. Some are device or family specific, Microchip documentation as well as CCS online help tells about their function in detail.

Normally, one could use the #fuses setting from an CCS example program as template (I usually start with settings from a previous PIC design) and consider, which changes could be meaningful for the new design.

I don't think, that wrong respectively missing #fuses setting is very likely to cause problems in Rahuls design, I just wanted to mention it as another condition that should be checked.

Regards,
Frank
 

PIC Behaving strange

check the compilor library and check the status of ports.
 

Re: PIC Behaving strange

Actually nothing happens. That is th problem. But, when I pull out the ground, the led lights up at a very dim brightness. When i put it back, sometimes, the led may glow.

I'm trying it again tomorrow.
Meanwhile pls help me if something is wrong...
 

Re: PIC Behaving strange

Hello,

don't know where you "pull out the ground", but most likely the processor isn't executing your code, not setting the ports to output, not setting it high or low, etc.

Some questions to proceed from the endless discussion:

Whats your programming enviroment?
How do you know, that your code has been succesfully downloaded to flash?
How do you know, that the processor is operating (e.g. has a clock) and is executing your code?
Are you able to single step code execution with ICD?
Have you a capability of doing any electronic measurements, e.g. have a multimeter to check supply levels or an oscolloscope to watch signal waveforms?

Regards,
Frank
 

Re: PIC Behaving strange

I use the CCS C compiler from within MPLAB to program as I absolutely hate their CCS IDE.
Actually, I don't know whether the processor is operating. But it gets proper VDD and VSS. I even measured the ouput voltage of the pin intended to be high. It shows around 2.2 volts. But, still it doesn't light up the LED. Maybe it has a low current output. I'm not sure. I'd doubts about the working of the programmer I use. Its a Xeltek 280U Programmer. It is rumoured here in my college, that it is not properly working. But nobody has actually tried to see it whether it actually functions or not. Again, the same programmer worked for me last year. But I used PICBASIC to program and my chip was a PIC16F84A. I disable the Brown out fuses in the programmer. I select HS oscillator for Xtal of 4MHz, simply because, last year Xtal osc. option in the programmer didn't work for me.

I've not tried single stepping with ICD, but as I told, I had use Oshonsoft's PIC Simulator to simulate. It worked fine in the sim. I'm trying again tomorrow. So, will get back today itself, ok?

Regards,
Rahul
 

PIC Behaving strange

Your C code does not set the config fuses, so the PICs are defaulting to RC clock. Look at the #pragma statement for a clue.
PS Simulators don't simulate the oscillator and always run.
 

Re: PIC Behaving strange

Hi all,

I couldn't access the internet over a week due to maintanence here. Thats why the delay.
Last week, I bought a fresh PIc and tested the code. It isn't working. plus, no sine wave is there across the Xtal. I'll try agian tomorrow with assembly.
will report back.
Thank you all

Regards,
Rahul
 

Re: PIC Behaving strange

Hi,

I tested the following assembly code agin, but no avail. I'm seriously thinking of issues with the programmer?

Here's the code, by the way...
Code:
            org 0x00
start     clrf PORTB
            banksel TRISB
            clrf TRISB
            banksel PORTB
            movlw 0xAA
            movwf TRISB
            end

Even that code isn't working.
By the way, I noted an intersting thing. A couple of AT89C52 were also programmed in it over the past week. Both of them are also not working.

Maybe an issue with the programmer ???

Any idea???
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top