Hello,

Well, as stated in the title, I'm using a PIC12F1572 in a 8pin package.

So i disabled the MCLR pin in the CONFIG words.
Now, the problem is if this pin is kept low on power up the PIC never actually starts executing code. if I left it float on power up and connect the device after it works normally.

Has anyone encountered such behaviour? Is there anything I am missing from the datasheet?

As far as I understand, this pin can only be used as a input, and to actually disable the MCLR I must disable de Low Voltage Programming, I did both.
The only thing I think I could do is invert all logic in the program and put a mosfet or transistor inverting the input.

What I'm using:
MPLAB X 5.05 (linux)
Pickit 3
pic12f1572 DIP8

 

Welcome to AAC!

You are correct, LVP (CONFIG2, bit 13) must be 0 and MCLRE (CONFIG1, bit 6 must be 0) to make pin 4 a digital input. On this part, disabling MCLR/ can let the pin be an input based on the TRIS register; other parts of the datasheet refer to all 6 as I/O but I think you're right about it only being an input. That would be consistent with others in the family.
Nothing in the errata says anything about it not starting with MCLR low when it's disabled and that is consistent with my experience with 8 pin Enhanced Midrange, too. It should work if the CONFIG is OK.

If the PIC starts with the pin floating, what happens if you then pull MCLR/ low? If it resets, that would indicate that there is a problem in the CONFIG bits ie. MCLR/ is still active. How are you generating the CONFIG bits? If you are using MPLABX's CONFIG bits generator, be sure to copy and paste the generated code into your source. It doesn't do it automatically like 8.x did. Also, double check the actual value generated by MPLABX against the datasheet. Occasionally, there have been mistakes in how X generates the CONFIG words.

Make sure your programmer is not using LVP. It's standard for many and that will cause MCLR/ to be active in the final chip image. Read the (not protected) chip back into the programmer and see what it reports for CONFIG.

Again, welcome aboard and good luck!

 

If I start the PIC with the pin floating it works as expected after, so it does not reset when pulled low and the program works as expected too. It gives me an indication that the CONFIG words are correct.

I'm using the MPLABX generator. I have the config at the beginning of the main file. I'll check if the words generated against the datasheet anyway.

 

As it happens, I have a 1572 circuit on a breadboard (built ~ 5 years ago). Works fine. I am not using RA3/MCLR for anything in the program and it is NC. I just tested the circuit - works fine. Then I tested it powering it up with that pin high, or low, or changing it to high or low while the program runs. No effect at all.

Here is the config that I used (MPASM, but should be the same idea in C).

;------------------------------------------------------------------------------
; CONFIG1
; _FOSC_INTOSC  INTOSC oscillator I/O function on CLKIN pin
; _WDTE_OFF  WDT disabled
; _PWRTE_OFF  PWRT disabled (power up timer)
; _MCLRE_OFF  MCLR/VPP pin function is digital input
; _CP_OFF  Program memory code protection is disabled
; _BOREN_OFF  Brown-out Reset disabled
; _CLKOUTEN_OFF  CLKOUT function is disabled-
;  I/O or oscillator function on the CLKOUT pin
  __CONFIG _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _BOREN_OFF & _CLKOUTEN_OFF
; CONFIG2
; _WRT_OFF  Write protection off
; _PLLEN_OFF  4x PLL disabled
; _STVREN_OFF  Stack Overflow or Underflow will not cause a Reset
; _BORV_19  Brown-out Reset Voltage (Vbor), low trip point selected.
; _LVP_OFF  High-voltage on MCLR/VPP must be used for programming
  __CONFIG _CONFIG2, _WRT_OFF & _PLLEN_OFF & _STVREN_OFF & _BORV_19 & _LVP_OFF

;------------------------------------------------------------------------------

Hope it helps.

 

Hello,

It appears the device connected to the MCLR pin was misbehaving when trigger too soon after power up, and holding the pin high permanently, holding my program in a loop somewhere ( I cant debug because it's using the MCLR pin and doesn't happen with the other pin i can use ).

Anyway, I introduced a 500ms delay at the start of the program to make sure that everything is up and running and it's now working after several tests.

I have to thank you all for the help and time.

 

Glad you got it working.