Jump to content
Sign in to follow this  
emte

12f675 Config Bit Problem

Recommended Posts

When setting up the CONFIG bits for the 12F675 i came across an issue:

When assigning/using the _INTRC_OSC_x flags the compiler says:

invalid pragma DATA argument

the flags are clearly defined and it does not complain about any of the

other ones. Assiging the hex value associated with the flags works as well.

 

Currently i am suspecting the length of the flag name itself as they are

substantially longer than the others.

 

On a slightly different issue, same chip, the header does include many

of the common name mappings. Is there any interest to include a

secondary or enhanced header for this device?

(i am writing a personal one anyway)

Edited by emte

Share this post


Link to post
Share on other sites
When setting up the CONFIG bits for the 12F675 i came across an issue:

When assigning/using the _INTRC_OSC_x flags the compiler says:

invalid pragma DATA argument

the flags are clearly defined and it does not complain about any of the

other ones. Assiging the hex value associated with the flags works as well.

 

Currently i am suspecting the length of the flag name itself as they are

substantially longer than the others.

I can't reproduce this issue, this code compiles with no errors:

CODE

#include <system.h>

 

#pragma DATA _CONFIG, _INTRC_OSC_NOCLKOUT & _INTRC_OSC_CLKOUT & _EXTRC_OSC_NOCLKOUT & _EXTRC_OSC_CLKOUT

 

void main()

{

while( 1 );

}

 

On a slightly different issue, same chip, the header does include many

of the common name mappings. Is there any interest to include a

secondary or enhanced header for this device?

(i am writing a personal one anyway)

Please provide details on what is missing so we can make sure its added in the next release.

 

Regards

Dave

Share this post


Link to post
Share on other sites

stephane,

 

It usually happens to me (but surely not to you) if I specify the wrong target device.
So not a bug at all, the problem was finger trouble!

 

Regards

Dave

Share this post


Link to post
Share on other sites

The correct device is specified.

i am trying to figure out how to provide more details as i can reproduce the error every time.

Mapping to a shorter name works as well.

 

Some of the missing stuff is just common things you would expect, like all the timer0 stuff

accessible by name, etc.

Share this post


Link to post
Share on other sites

Well... when trying to verify and test a few things in hardware i've found an oddity.

 

It seems BoostC has some defined address locations?

Building code that is identical to working code from another compiler

shows a strange oddity when programmed and read back. The bulk of the

memory is blank with exception to a main tag at line 51 and the calibration value at 1024.

The result is no programmed code.

 

i am using an ICD2 to read and write to the 12f675 and have no issues with the test code

itself(as it works when compiled with other compilers). The disassembly after compiling

looks good, so the compiler itself seems to be doing its job... possible linker issue?

 

Do i need to use some special linker flag with the 12f devices?

Share this post


Link to post
Share on other sites
Well... when trying to verify and test a few things in hardware i've found an oddity.

 

It seems BoostC has some defined address locations?

Building code that is identical to working code from another compiler

shows a strange oddity when programmed and read back. The bulk of the

memory is blank with exception to a main tag at line 51 and the calibration value at 1024.

The result is no programmed code.

Can you provide a sample project demonstrating this problem

 

i am using an ICD2 to read and write to the 12f675 and have no issues with the test code

itself(as it works when compiled with other compilers). The disassembly after compiling

looks good, so the compiler itself seems to be doing its job... possible linker issue?

 

Do i need to use some special linker flag with the 12f devices?

No.

 

Regards

Dave

Share this post


Link to post
Share on other sites
#include <system.h>

/*  0x3fd4  _WDT_OFF & _PWRTE_OFF &_MCLRE_OFF &_BODEN_ON &_CP_OFF &_CPD_OFF &_INTRC_OSC_NOCLK */
/* #pragma DATA	_CONFIG,  _WDT_OFF & _PWRTE_OFF &_MCLRE_OFF &_BODEN_ON &_CP_OFF &_CPD_OFF &0x3FFC   some reason the intrc_osc_noclk does not work */

/* explicit value set */
#pragma DATA	_CONFIG, 0x3FFF & 0x3FFF & 0x3FBF & 0x3FDF & 0x3FFF & 0x3FF7 & 0x3FFC

#pragma CLOCK_FREQ	8000000

#define _SEND0	0x0B
#define _SENDA	0x41


void main(void)
{
unsigned char i = 0;
unsigned char s = 0;

trisio = 0;	/* set all as output */

while(1)
{ 
	while(i<8)
	{
		delay_ms(100);
		switch(s)
		{
			case 0:
			{
				gpio = _SEND0 << i;
				break;
			}
			case 1:
			{
				gpio = _SENDA << i;
				break;
			}
			default:
				break;
		}
		(i>8)?(i=0):(i++);
	}

	delay_s(1);
}

}

Share this post


Link to post
Share on other sites

emte,

#include <system.h>

/*  0x3fd4  _WDT_OFF & _PWRTE_OFF &_MCLRE_OFF &_BODEN_ON &_CP_OFF &_CPD_OFF &_INTRC_OSC_NOCLK */
/* #pragma DATA	_CONFIG,  _WDT_OFF & _PWRTE_OFF &_MCLRE_OFF &_BODEN_ON &_CP_OFF &_CPD_OFF &0x3FFC   some reason the intrc_osc_noclk does not work */

....
.....

The code compiles, a hex file is generated as expected, so I can't see why you should have an issue programming the device. If you read the device memory back what do you get ?

 

Regards

Dave

Share this post


Link to post
Share on other sites

Full of NOPs with a "GOTO main" at line 51,

although i did sort of solve that issue by enabling external MCLR

BUT(seems there is always a but) the code still does not run.

Even forcing the gpio pins high, i can not light up an LED.

 

Not sure what is happening, now comparing disassembly files.

Share this post


Link to post
Share on other sites

i have located one issue specific to BoostC,

if both mclr and the osc are internal,

the programmed hex is nothing but nop commands.

NOTE: this is programming with an ICD2, the generated hex file

is proper.

 

Under other compilers the programmed hex is the same as

the generated hex.

 

Is there some weird control commands being sent to the

programmer in the hex??

 

To further this point, if EITHER one or both(the mclr or osc)

are assigned external, the programmed and generated code

are the same.

 

So far this makes no sense to me why one is fine and the other is not.

(This behavior was verified comparing programming and readback from the device)

Share this post


Link to post
Share on other sites

emte,

Is there some weird control commands being sent to the

programmer in the hex??

 

To further this point, if EITHER one or both(the mclr or osc)

are assigned external, the programmed and generated code

are the same.

 

So far this makes no sense to me why one is fine and the other is not.

(This behavior was verified comparing programming and readback from the device)

Makes no sense to me either. Somehow the contents to the hex file is causing a problem. You could compare the two hex files (one that works and one that doesn't) to see exactly what is difference is. It should just be the data for programming of the configuration word.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...