pic 12F675 issue

Discussion in 'Embedded Systems and Microcontrollers' started by geoffers, Apr 26, 2013.

  1. geoffers

    Thread Starter Active Member

    Oct 25, 2010
    239
    6
    Hi all,

    I've just been reading through a few other posts to see if I can sort myself out.... I've some pic12f675's lying about that I wanted to use for a project that uses the comparator, I remember I gave up on them a few years ago when I was using a Picstart plus. I've now been using a pickit2 which is about a thousand times better.

    Anyway I dug out the 12f675's and wrote a very short programme to flash a LED on gpio,5 with the pickit2 powering the chip I got my led to flash:).

    I then added power via my bench supply, the led still flashed so I went about programming it for my application (ir beam break). It was fine now nothing, I've gone back to the start again and none of the four I have will work?

    Could I have cooked them previously? Experiance has so far told me pics are quite tough. It appears to me as if they arn't starting up.

    Details; Circuit, very simple, decoupling cap, 5v regulated supply
    One resistor, one LED
    ICP header.

    Configuration; Internal osc, no clock out
    Powerup timer on
    WDT off
    Brown out off
    MCLR off
    Code protect off

    Has anyone else had trouble with these? Any ideas or shall I just buy new ones!

    Thanks Geoff
     
  2. tshuck

    Well-Known Member

    Oct 18, 2012
    3,531
    675
    Please post your code. A schematic, no matter how trivial may also help. Sometimes, that's where you realize a mistake.
     
  3. hexreader

    Active Member

    Apr 16, 2011
    250
    82
    I half remember that PICkit2 and 12F675 have issues with losing the OSCCAL value.

    Remove the calibration call from the start of your program (I am guessing that you are using assembly language). Your timing will be inaccurate, but your code will run.

    If you plan to buy buy new chips, buy 12f683 or newer. PIC12f683 is factory calibrated and there is no issue with oscillator calibration.

    Search the Microchip archive if you want real facts that do not rely on my failing memory.

    My guess is that your PICs are not faulty, but just need OSCCAL value re-generated.

    EDIT: better still, ask the same question on the Microchip forum
     
  4. tracecom

    AAC Fanatic!

    Apr 16, 2010
    3,869
    1,393
    I bet your diagnosis is correct. The late versions of the PICkit2 Programmer software have an OSCCAL regen function, but I don't know if it works on the 12F675.
     
  5. geoffers

    Thread Starter Active Member

    Oct 25, 2010
    239
    6
    Wow, thanks for the swift replys, I knocked out the osccal write but they're still not playing!
    Here's my schematic

    12f675.gif

    And my code;

    Code ( (Unknown Language)):
    1. #INCLUDE P12F675.INC
    2.     LIST P=12F675
    3.     ORG  0X00
    4.     GOTO    START
    5.  
    6. __CONFIG_INTRC_ORC_NOCLKOUT_WDT_OFF_PWRTE_ON_MCLRE_OFF_BOREN_OFF_CP_OFF_CPD_OFF
    7.    
    8.     COUNT   EQU 0X20
    9.     TIME    EQU 0X21
    10. ;#########################################################
    11. DELAYP5 MOVLW   .100
    12.         MOVWF   COUNT
    13. TIMED   CALL    DELAY
    14.         DECFSZ  COUNT
    15.         GOTO    TIMED
    16.         RETLW   0
    17.  
    18. DELAY   CLRF    TMR0
    19. LOOPA   MOVF    TMR0,W
    20.         SUBLW   .39
    21.         BTFSS   STATUS,Z
    22.         GOTO    LOOPA
    23.         RETLW   0
    24.  
    25. DELAY1.5    CLRF    TMR0
    26. LOOPB       MOVF    TMR0,W
    27.             SUBLW   .10
    28.             BTFSS   STATUS,Z
    29.             GOTO    LOOPB
    30.             RETLW   0
    31.  
    32.  
    33. START BSF   STATUS,5    ;BANK1
    34.  
    35.     CLRF    ANSEL
    36.  
    37. ;   CALL    3FFH
    38. ;   MOVWF   OSCCAL
    39.     MOVLW   B'00001011' ;GP0, GP1 COMPARATOR INPUT REST OUTPUT
    40.     MOVWF   TRISIO
    41.     MOVLW   B'00000111'
    42.     MOVWF   OPTION_REG
    43.     BCF     STATUS,5    ;BANK0
    44.  
    45.     MOVLW   0X07        ;  
    46.     MOVWF   CMCON
    47.  
    48.     CLRF    GPIO
    49.  
    50. ;############################################
    51.  
    52.  
    53. BEGIN   BSF     GPIO,5
    54.         CALL    DELAYP5
    55.         BCF     GPIO,5
    56.         CALL    DELAYP5
    57.         GOTO    BEGIN
    58.  
    59. END
    60.  
    Thanks for looking, its bugging me!:confused::confused:
     
  6. Markd77

    Senior Member

    Sep 7, 2009
    2,803
    594
    Not sure if this really causes a problem, but you are supposed to do a "clrwdt" before changing prescaler to TMR0 (section 4.4 of datasheet)
     
  7. geoffers

    Thread Starter Active Member

    Oct 25, 2010
    239
    6
    Thanks, just tried that to no avail!!! Darn it. The programming is always reported as successful, I've got a 100nF decoupling cap, is that what other folks use?
    Cheers Geoff
     
  8. tshuck

    Well-Known Member

    Oct 18, 2012
    3,531
    675
    Subtracting 39 from 100 won't result in 0, try subtracting a factor of 100...

    Or test another flag...
     
  9. RG23

    Active Member

    Dec 6, 2010
    301
    2
    Comment the config line of your code

    Instead in MPLAB use the configuration bits set in code and try to build the program

    If it builds successfully program your PIC with pickit2

    Disconnect the pickit2 and run your unit
     
  10. geoffers

    Thread Starter Active Member

    Oct 25, 2010
    239
    6
    Thanks for the replies, 39 isn't subtracted from 100, it counts 39 cycles of tmr0, 100 times? for a nice long delay, the led should at least light up.

    Just rebuilt it setting config bits in mplab and it goes! Thank you, I'm now really curious as to why it worked and then didn't?

    As I was writing I felt a need to tinker, changed my config code to;

    Code ( (Unknown Language)):
    1. __CONFIG_INTRC_ORC_NOCLKOUT
    2. __CONFIG_WDT_OFF_
    3. __CONFIG_PWRTE_ON
    4. __CONFIG_MCLRE_OFF
    5. __CONFIG_BOREN_OFF
    6. __CONFIG_CP_OFF
    7. __CONFIG_CPD_OFF
    Rebuilt it with config set in code and it works. I'm pleased but puzzled?:confused:

    Thanks again Geoff
     
  11. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    5,435
    1,305
    If the config is programmed wrong (or is missed) then the PIC might expect a xtal, and it won't run without the xtal.

    So even though your code is expecting the internal oscillator to run, the programmed PIC won't run.
     
  12. geoffers

    Thread Starter Active Member

    Oct 25, 2010
    239
    6
    Thanks for the reply, the bit that puzzles me is that in worked to start with? I changed nothing in the config,and it stopped. Sort of an aside what is the approved convention for configuring a PIC? I'm self taught and have seen various ways of doing it? The first book I read suggested setting the 'fuses' in mplab configure section then reading the number and putting __config'xxxx' ie what ever the number was.

    This seemed a bit muddly I've tried the way I did it this last bit of code a few times but it seems to have gone wrong this time?

    I guess I could be opening a can of worms?!

    Cheers Geoff
     
  13. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    I can't say why it worked, then didn't work, then worked. Could be as simple as not noticing MPLAB not saying "Build successful!" at the end because of some other minor thing.

    I've always put the config information into the code, usually near the top of the main dot C file, the one that holds main(). Microchip uses this same area. The big advantage over putting inside MPLAB is you have more control as you can use conditional compilation to change configs for whatever reason (but usually different PICs).

    I'm self taught too, I've just been at this for a longer time. <grin>
     
  14. geoffers

    Thread Starter Active Member

    Oct 25, 2010
    239
    6
    Thanks I shall do that! One thing I've learnt is pic's always do what you tell them! If their not doing what you expect its your fault!:)
    Thanks for everyones help Geoff
     
Loading...