Cannot switch-off Power UP Timer (PUT) at 12F675

[bschriek]

Code starts with:
#include <12F675.H>
#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,BROWNOUT,NOPUT
etc.....

The Power Up Timer (PUT) is always enabled.
PUT or NOPUT command, both result in an enabled Power Up Timer.

Is there a way to switch-off the PUT in the program code at an other way
than setting the fuses?
Now every time the Power Up Timer must be disabled in the menu of the programmer by hand.

IDE, PCB and PCM version 4.060

[Ttelmah]

What programmer?.
If you look at the .lst file, the PUT fuse, _is_ being changed by the compiler. It suggests your prgrammer is overriding the value.

Compiling two programs, one with PUT enabled, and one without, gives in the hex file:
:02400E00F5318A //Without PUT

:02400E00E5319A //With PUT

Note the 'E', rather than 'F', which is correctly clearing bit 4 of the config register.

Best Wishes

[bschriek]

I have added the C-code and List file.

PUT enabled
C-code:#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,NOBROWNOUT,NOPROTECT,PUT
List code:Configuration Fuses:
Word 1: 3184 NOWDT NOCPD NOPROTECT NOMCLR PUT INTRC_IO NOBROWNOUT BANDGAP_HIGH

PUT should be disabled but...
C-code#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,NOBROWNOUT,NOPROTECT,NOPUT
List code: Configuration Fuses:
Word 1: 3184 NOWDT NOCPD NOPROTECT NOMCLR PUT INTRC_IO NOBROWNOUT BANDGAP_HIGH
The config word must be 3194 but it isn't????

The programmer is a GALEP-4 with updates but the result is the same at our home made PIC programmer.

We already checked the output file and fuses before.
We can live with it for now but it would be nice if we could overide the #fuses by a C-command.
Is there a way to change the #fuses in C?
A compiler update would be better of course but first we want to be sure it's not a mistake of ours.

Best regards and thank you in advance,
Bas

[Ttelmah]

Try reloading the original devices4.dat file that came with the compiler (or re-installing the compiler). This behaviour can be triggered if the device editor has been used, and the fuse is incorrect in the file...

Best Wishes

[bschriek]

We checked the fuses in the Device Table Editor and this seems o.k.
The PUT/NOPUT mask and value are o.k.

Furthermore we also installed the C-compiler at an other computer and the result is the same. PUT is always ON.

We already got 2 updates because of bugs in the compiler and therefore I don't want to install the "older" .dat files. The old bugs may come back.

Is there a way to change the #fuses in C????

[S9J8Z6]

You can include a #ROM statement, with the required byte values to put into the fuse locations.
What puzzles me though, is why your compiler is doing this. The compiled lines I posted, came from the same compiler version, and it works fine....

Best Wishes

[bschriek]

We added this code: #ROM 0xF2007={0X3194}

This command does nothing at adress 0x2007.
Other addresses can be changed by the #ROM command but not address 0x2007!

For 0x2007 the settings are used according the #FUSES at the begin of the program.

[ckielstra]

Do you have the setting ICD=TRUE in your code?
I know on some chips this setting forces the NOPUT, NOBROWNOUT and NOWDT fuses. I can't test it right now, but maybe your compiler version / chip type forces the PUT fuse?

[Ttelmah]

Er.
The address you have selected, is F2007......

I like Ckielstra's idea. Had forgotten about the ICD settings.

Best Wishes

[PCM programmer]

I installed vs. 4.060 and compiled the following test program:

[bschriek]

Thank you very much for your help!

ICD=TRUE ----> solved the problem
For now every program starts with this code.


Best regards,

[ckielstra]

[bschriek]

You are right, the program must run without ICD.
In fact, we don't even have an ICD.

For now we only use the ICD=TRUE command to switch-off the PUT.
Now the circuitry and the program runs fine and the PUT is really switched-off.

For your information I have added the program of mr "PCM programmer" and modified some fuses with and without the ICD=TRUE code.

One way or another the compiler forces some fuses without warning.


#include <12F675.h>
#device ICD=TRUE
#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,BROWNOUT,NOPUT
#use delay(clock=4000000)

//==========================
void main()
{


while(1);
}

/*

.LST result:
CCS PCM C Compiler, Version 4.060, 37576 24-mrt-09 10:54



C-Code:
#device ICD=TRUE
#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,BROWNOUT,NOPUT
.LST result:
Configuration Fuses:
Word 1: 3194 NOWDT NOCPD NOPROTECT NOMCLR NOPUT INTRC_IO NOBROWNOUT BANDGAP_HIGH

C-Code:
//#device ICD=TRUE
#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,BROWNOUT,NOPUT
.LST result:
Configuration Fuses:
Word 1: 31D4 NOWDT NOCPD NOPROTECT NOMCLR NOPUT INTRC_IO BROWNOUT BANDGAP_HIGH



C-code:
#device ICD=TRUE
#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,NOBROWNOUT,NOPUT
.LST result:
Configuration Fuses:
Word 1: 3194 NOWDT NOCPD NOPROTECT NOMCLR NOPUT INTRC_IO NOBROWNOUT BANDGAP_HIGH

C-code:
//#device ICD=TRUE
#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,NOBROWNOUT,NOPUT
.LST result:
Configuration Fuses:
Word 1: 3194 NOWDT NOCPD NOPROTECT NOMCLR NOPUT INTRC_IO NOBROWNOUT BANDGAP_HIGH



C-code:
#device ICD=TRUE
#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,BROWNOUT,PUT
.LST result:
Configuration Fuses:
Word 1: 3194 NOWDT NOCPD NOPROTECT NOMCLR NOPUT INTRC_IO NOBROWNOUT BANDGAP_HIGH

C-code:
//#device ICD=TRUE
#FUSES INTRC_IO,NOMCLR,NOCPD,NOWDT,BROWNOUT,PUT
.LST result:
Configuration Fuses:
Word 1: 31C4 NOWDT NOCPD NOPROTECT NOMCLR PUT INTRC_IO BROWNOUT BANDGAP_HIGH

*/

[Ttelmah]

The point that Ckielstra was making, was that _if you did have ICD=TRUE in your code, it would force the PUT off, and therefore explain it not being changeable by your code_.

Both PCM, and myself, have compiled example programs, and PUT changes fine with them, using your compiler version...

Using the #ROM statement _with the right address_, should allow you to override the setting. Why it is not working for your, _must_ be down to something you are doing, either in the setup, or installation. Is it possible (for instance), that in fact the compiler is accessing an incorrect devices4.dat file, because there is another in a directory in your 'path' somewhere?.

Best Wishes

[PCM programmer]