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

18f27j53 no write_configuration_memory available ??
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

18f27j53 no write_configuration_memory available ??
PostPosted: Thu Jun 18, 2015 2:47 pm     Reply with quote

Hello Smile
I'm starting with pic18F27j53 (before I used 18F2550).

I try to use the write_configuration_memory function, but I have an error (V5.045) "undefined identifier -- write_configuration_memory"

Why do I have this error ?

What is the solution to change clock source and pll config ?

Thanks for your help

Spilz
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

PostPosted: Fri Jun 19, 2015 6:33 am     Reply with quote

can I use
Code:
int data[4];
read_program_memory(0x300000,data,4);
// ... change config
write_program_memory(0x300000,data,4);
?

thanks for your help

Spilz
Ttelmah



Joined: 11 Mar 2010
Posts: 19451

View user's profile Send private message

PostPosted: Fri Jun 19, 2015 8:11 am     Reply with quote

Read section 28.1.1 in the data sheet.

The configuration is different in these chips. It doesn't actually have 'configuration memory' as such. It has 'FCW'. These are 4 _words_ (not bytes) of memory at the top of the program memory. When you boot, these 4 words are copied into the configuration registers. For your chip they are at 0xFFF8 to 0xFFFF.

Remember though that to change these you have to write the entire _page_.

I have to ask why you want to change these?.

Bootloader's should not change the configuration.
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

PostPosted: Fri Jun 19, 2015 8:31 am     Reply with quote

Hello Ttelmah,

Thanks for your reply,

I know that bootloader shouldn't change it, but I have a sub bootloader, so on 18F2550 I need to activate pll with 4MHz Quartz for USB and my software have to run at 4MHz with pll disable to save a lot of power...
So if bootloader is started, it directly change the config to have the good one, and after it finish the job, there is a specific space memory where software config is stored (that at define, always at the same location) the bootloader load the software config.
It's not perfect, specially for R/W cycles but it works well and I doesn't find an other way to do it ...

Sorry for the stupid question, but how big is a _page_ ?
Is there a simple way to write the entire page ?

Thanks for your help
Ttelmah



Joined: 11 Mar 2010
Posts: 19451

View user's profile Send private message

PostPosted: Fri Jun 19, 2015 11:49 am     Reply with quote

You do realise, that if you change the configuration, it won't apply till the _next_ boot. So you can't just change it, and run at the other speed. It's going to be very complex to do.

You can switch speeds in software though. If timings are not essential in the low power mode, just have the fuses default to running with the crystal/PLL, and then just software switch to the internal oscillator at 4MHz, to save power (and turn off the primary oscillator).

On the J53, the erase page is 1024 bytes. Means if you want to change the configuration, the whole top 1024 have to be read, the changes made, and re-written......
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

PostPosted: Sat Jun 20, 2015 10:37 am     Reply with quote

I realise that, I need to find a safe solution Smile

I don't really understand why I have to erase all the page, I did a test with :
Code:
read_program_memory(0x1FFF8,data,8);
config1 = 0x0000|0x000E|0x0010|0x0020|0x0080|0x0300|0x0400;
config2 = 0x0004|0x0018|0x0000|0x0000|0x0080;
     
data[1] = config1 >> 8;
data[0] = (int)config1;
     
data[3] = config2 >> 8;
data[2] = (int)config2;
     
write_program_memory(0x1FFF8,data,8);

and it seems to work well (after restart of course)
Ttelmah



Joined: 11 Mar 2010
Posts: 19451

View user's profile Send private message

PostPosted: Sun Jun 21, 2015 4:23 am     Reply with quote

You can only change bits from their _erased_ state, to their 'set' state. Once a bit is set, you can't then clear it, without an erase.
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

PostPosted: Sun Jun 21, 2015 11:47 am     Reply with quote

hello,

yes, it's what I understand with your explanation in this topic :
https://www.ccsinfo.com/forum/viewtopic.php?t=53690

with my test I didn't see it...

thanks for your help
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

PostPosted: Sun Jun 21, 2015 2:48 pm     Reply with quote

from : https://www.ccsinfo.com/forum/viewtopic.php?t=53690&postdays=0&postorder=asc&start=15
Quote:
Seriously, I still think you should 'think again', and change the clock rate another way. If you lose power during the config write, then the chip will have to be reprogrammed with an external programmer. It is a dangerous thing to do. One of the reasons it is so complex, is that Microchip do not expect this to be done. It's a wrong/dangerous approach.


I already try to use internal clock, but I had issue with serial port and temperature change...

The other only way I see is to be abble to turn on/off pll by software. I don't know if it's possible.
Ttelmah



Joined: 11 Mar 2010
Posts: 19451

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 12:31 am     Reply with quote

When using the internal clock, what you can do, is adjust to compensate for temperature.

The 'standard' clock is good enough over normal room ranges, provided you are using a baud rate that results in low error, but if this is not the case, what you do is have the transmitting device send a 'sync' frame at the start of it's comms. Typically something like <CR><0x55><0x55><CR>. At the start of the comms (when you see the CR), you enable the autobaud feature of the UART, which automatically adjusts the baud rate used in the chip to match the bit width of the next character received (must by 'sync' - 0x55).

Your baud rate will then be _better_ for the next few minutes, than typically achieved even when using a crystal....

MicroChip do expect you to be able to get reliable comms with the internal clock.
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 2:22 am     Reply with quote

it's good to know,

but in my case I can't use it :
It's to use a SIM900 board with the pic and AT commands, I can't change the protocol...

The electronic is in a waterproof box outside, so in summer it become hot inside the box and I had creasy sms sent because of the internal clock not reliable with this temperature difference..

In the datasheet p36, It seems I can turn ON/OFF PLL by software, using PLLEN.
I try that, but it does not work :
Code:
setup_oscillator(osc_pll_on);
... // led blink 5 times at 1Hz
setup_oscillator(osc_pll_off);
... // led blink 5 times at 1Hz

I did test with 1Hz blinking led, hopping frequence changing, but no change
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 2:25 am     Reply with quote

the other way can be to use interclock with PLL for bootloader, and external clock without bootloader for normal program.

I don't know if it's possible do to that
Ttelmah



Joined: 11 Mar 2010
Posts: 19451

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 2:46 am     Reply with quote

Did you have the PLL enabled in the fuses?.

You can _disable_ the PLL if it is enabled, but you can't enable it, if it is disabled in the fuses.

So as I said before, you want the PLL _enabled_ in the fuses, and then have the slow code turn it off.

Look at Table 3-1. Note that with HS, it says:

High-Speed Crystal/Resonator mode,
PLL always disabled, crystal/resonator
connected between RA6 and RA7.

Note 'PLL always disabled'.

Then look at HSPLL:

High-Speed Crystal/Resonator mode,
PLL can be enabled or disabled in
software, crystal/resonator connected
between RA6 and RA7.

Note 'PLL can be enabled or disabled in software'.
spilz



Joined: 30 Jan 2012
Posts: 218

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 2:49 am     Reply with quote

I tried both, and I had the same result..
Code:
#fuses HSPLL,PLL1,PLLEN

and
Code:
#fuses HSPLL,PLL1,NOPLLEN
Ttelmah



Joined: 11 Mar 2010
Posts: 19451

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 3:19 am     Reply with quote

How are you actually testing this?. In a chip for real?.
Code:

#include <18F27J53.h>
#device ADC=10
#use delay(clock=48MHz,crystal=4000000)
#fuses HSPLL,NOPLLEN,PLL1,NOCPUDIV,NOXINST,STVREN,NOWDT,SOSC_DIG

void flash(void)
{
   int8 ctr;
   for (ctr=0;ctr<5;ctr++)
   {
      output_high(PIN_B0);
      delay_ms(500);
      output_low(PIN_B0);
      delay_ms(500);
   }
}

void main()
{
   flash(); //5 seconds
   setup_oscillator(OSC_PLL_OFF);
   flash(); //48 seconds

   while(TRUE)
   {
      delay_cycles(1);
   }
}

I just merrily tried this, and it did exactly as expected.

Be aware that most debuggers will _not_ change the PLL when running.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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