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

A problem about PIC10F200

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



Joined: 11 May 2005
Posts: 57
Location: london

View user's profile Send private message

A problem about PIC10F200
PostPosted: Fri Nov 18, 2005 7:55 am     Reply with quote

Hi all,

I've started a little project with PIC10F200 and am experiencing some initial problem. I put my basic test code underneath:

Code:
#include<10F200.h>

#use delay( clock = 4000000 )

#byte GPIO = 0x06
#bit out = 0x06.1

void main()
{
  #asm
  //MOVLW 0b00000000
  MOVF 0x00, w
  TRIS 6
  #endasm

  while(1)
  {
    #asm
    BSF GPIO, 1
    #endasm
    delay_ms(1000);

    #asm
    BCF GPIO, 1
    #endasm
    delay_ms(1000); 
  }
}


Now I am trying to toggle GPIO.1, which is GP1, every 1s. Obviously the LED doesn't blink and I have some thought:

1. The internal clock is not running
or 2. I failed to set the tris state correctly

If the problem is one of them or else, could anybody explain why and give hints how to get around it?

Thx
Ttelmah
Guest







PostPosted: Fri Nov 18, 2005 8:58 am     Reply with quote

First, where are your fuses?.
Second, why the assembler?. You are using C, so use it.
Code:

#include<10F200.h>
#fuses NOMCLR,NOWDT,NOPROTECT

#use delay( clock = 4000000 )

#byte GPIO = 0x06
#bit out = GPIO.1

#use fast_io(B)
//Otherwise the compiler will want to control the TRIS

void main()
{
  set_tris_b(0b01000);
  //Remember B3, must be an input.
  while(1) {
    out=1;
    delay_ms(1000);

    out=0
    delay_ms(1000); 
  }
}

Or just use the 'output_high', and 'output_low' functions, leave the I/O mode set as standard_io, and stop fiddling with the TRIS at all.
Have you got your progammer set to save the byte at the top of memory?. If this has not been saved, then no code will work (this contains the value meant to be put into the OSCCA register, and is read by the code on boot). If nothing is here, the processor will hang.
Unless you are manually overriding the value in the config register, I'd suspect your problem is that the default setting, without fuses, has 'MCLR' enabled.

Best Wishes
ye



Joined: 11 May 2005
Posts: 57
Location: london

View user's profile Send private message

PostPosted: Fri Nov 18, 2005 9:36 am     Reply with quote

Ttelmah,

Thanks for your info.

I didn't use fuese because I set all the fuses in MPLAB( there are just 3, basically).

I know little about assembly. I used it because I didn't realise Port GP refers to Port B. It's a weird and confusing name. And I didn't find a TRIS register in memory so simply thought maybe there was no way to control a TRIS in C.

=====================================


Quote:
Have you got your progammer set to save the byte at the top of memory?. If this has not been saved, then no code will work (this contains the value meant to be put into the OSCCA register, and is read by the code on boot).


What do you mean the byte at the top of memory? You mean calibration byte? I do keep having the ICD warning: "ICDWarn0044: Target has an invalid calibration memory value (0x0). Continue?", but I ignored it. Would that be problem?

Could you explain why the code wouldn't work if the byte has been been saved? I didn't come across this before coz' I have been using external clock all the time.

Thanks!!!
Ttelmah
Guest







PostPosted: Fri Nov 18, 2005 10:52 am     Reply with quote

These chips, actually start be executing the byte held in the top address in memory, not address '0'!. Address '0', is the 'effective reset vector', but the real vector is address '0xFF', which is meant to contain a MOVLW XX instruction, which loads 'W' with the value that should go into the OSCCAL register. The very first byte of the code actually generated by the compiler, is a 'MOVWF 05', which transfers this byte into the required register, to adjust the oscillator. Now the effect of having an 'incorrect' value at this location, depends on what is actually there. If it contains a value, that proceeds to the next instruction, then the code will probably work, but if it contains (for example), a 'sleep' instruction, or any form of 'jump' or return, then the code will never run (or at least not properly). This is why the programmers normally have an option to save this byte.
Depending on how your programmer behaves, you may be able to get the code working, by manually writing the value 0xC00 to this address (which will give an uncorrected oscillator, but it should not be badly out).

Best Wishes
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