FC7 keeps writing default configuration

[vinctech]

Hi,

My setup:
FlowCode7.1.1.0 professional,
mLoader version 3.4.1.0
Programmer: EB-006-00-9
Project: device series PIC 16F,
device PIC 16F630
compiler: Microchip MPLAB XC8 C Compiler (Free Mode) V1.38
My problem is the writing of the configuration word to the device.
No matter what configuration changes I select, at Build time, always the same (default?) configuration word (0x28C7) is written to the device or the hex-file.
My workaround is, to Build the program to a hex-file, manually edit the configuration data in the hex-file and write this modified hex-file to the device with mLoader.
Of course, I searched in the tutorials and help files for the settings but cannot find any that work.
1. In Build - Configure , I checked "Write config on download". When doing this, the Build process completes without errors but writes the wrong Configuration data.
2. In Build - Configure , I unchecked "Write config on download", the compiler suddenly gives a bunch of errors, says "Too many errors (21)" and stops without success.
3. In Build - Compiler Options - Programmer, I left "Enable writing of configuration to chip" unchecked. As I understand, this option must only be checked in case I want to write a custom configuration string.

Even if I write the correct configuration to the device with mLoader, each subsequent 'Build to device' overwrites the configuration with the wrong, default configuration. As mentioned, I cannot switch off the writing of the configuration, because in that case the compiler "crashes".

Probably the solution is simple (one simple check mark?), but I just cannot find it. Any help is appreciated!

[QMESAR]

Hi

Not mentioned by you however if you are using internal OSC are you setting the OSCON tune register ?

[vinctech]

Hi QMESAR,

I am using the internal oscillator indeed. I did not write the OSCON bits specifically, for two reasons:
1. I assume that, because both FC7 and mLoader know the device number, they automatically read the OSCON bits beforehand and write them back at flashing time.
2. Because my application is not time critical, a large clock frequency shift (caused by cleared OSCON bits) wouldn't be unacceptable.

Now I remember a post by kanda.com (who sells handheld (PIC)programmers) about the reason that they do not support the 16F630 in their programmers (e.g. PIC-HH0820). They write, quote:

The problem with PIC16F630 and PIC16F676 is the erase routine removes the calibration bytes, unlike all other PIC16F erase instructions. This means that the programmer would need to read these locations, store them and write them back. This is possible but we were worried about the possibility of something going wrong and leaving the chip in an unknown state.
A PC based programmer has much more scope to recover from this position than a handheld, which carries out operations in a linear fashion. If the PC version had a problem, it would be much easier to carry out restore operations that are too complicated for the handheld.

.

This leaves some questions:

• - Is it correct to assume that FC7 and/or mLoader retains the OSCON bits by pre-reading and rewriting?
  - If not, would this cause my issue that the default configuration word is written instead of my custom configuration?
  - Remember, my issue (always writing default configuration word) also occurs when Building to a hex file instead of Building to chip.

[medelec35]

This brings back memories when I was programming 12f675.
They have factory pre-claibrated internal osc just like the 16F630
It was OSCCAL value that was used for calibration of internal oscillator.
OSCCON or OSCTUNE was not used then.
What I did was the very first time of using these devices was to read the device and make a note of the OSCCAL value as accidents can happen.
I also made sure that the programmer used had the function storing /retrieving and writing back OSCCAL as its erased when programming.
I did not use PICkit at the time as the programmer I used stored the OSCCAL value, but I believe the PICkit range can do that as well.
So best bet is use PICkit2 or PICkit3, Read device and note the OSCCAL value, then use it to program your device.
When Steve is back from Christmas break (if not sooner ) then he would be able to say if mloader/PPP supports saving of OSCCAL.
My guess it does not, so bet not to use them until its known for sure.

I have just checked and can confirm Flowcode V7 is correctly saving fuses to the hex file.

So compile to hex and load with PICkit or other suitable programmer.
All may not be lost if you have erased OSCCAL value.
I believe 16F630 could work with software developed for calibrating 12F675 here
Maybe worth checking out.

Martin

[vinctech]

Hi,

Following your suggestions, restoring clock calibration is feasible and has an acceptable workaround, if it is not automatically done by FC7 or mLoader.

The main and most disturbing issue remains, that configuration changes (clock source, WDT, Code protection, MR source, etc, etc) are not sent to either Chip or HEX and requires manual editting of the HEX-file as described in my first posting.
One may suggest to one-time follow this manual editting procedure (as configuration often remains the same during code development). Then, during future code version uploads, uncheck "Write config on download". Unfortunately, as described, in that case the compiler doesn't complete at all.

Does anyone suggest that I repost this issue in the bug report section?

Any suggestions are appreciated.

[medelec35]

The main and most disturbing issue remains, that configuration changes (clock source, WDT, Code protection, MR source, etc, etc) are not sent to either Chip or HEX and requires manual editting of the HEX-file as described in my first posting.

I did state in my last post that fuse settings are being save to hex file:

Config 630.png

(74.63 KiB) Downloaded 3746 times

You can see my programming software showing fuses from hex file, next to configuration settings.
They do match.
Have you tried manually running mLoader:
For 64 bit windows
C:\Program Files (x86)\Flowcode 7\tools\mLoader

or
For 32 bit windows
C:\Program Files\Flowcode 7\tools\mLoader
There is a

Code: Select all

Write Config Enabled

option is that enabled?

mLoader1.png

(58.75 KiB) Downloaded 3746 times

I use mLoader with various chips (not with 16F630) and it does send correct configuration settings although can't rule out there could be an issue?
You can also check to see if config settings are embedded with hex and C code.
For C code look at the top of the generated file with a c extension:

Code: Select all

//************************************************************************************
//**  
//**  Source name:   C:\Users\Martin\Downloads\16F630.fcfx
//**  Title:         
//**  Description:   
//**  Device:        PIC.16F.16F630
//**  
//**  Generated by:  Flowcode v7.1.1.0
//**  Date:          Tuesday, December 27, 2016 11:41:32
//**  Users:         1
//**  Registered to: Martin
//**  Licence key:   BA48R5
//**  
//**  
//**  http://www.matrixtsl.com
//**  
//************************************************************************************


#define MX_PIC

#define MX_CAL_PIC

#define MX_CLK_SPEED 4000000

#define FCP_NULL Unconnected_Port



#include <xc.h>
#include <math.h>

__PROG_CONFIG(0x1, 0x3FD4);

/*========================================================================*\
   Use :Include the type definitions
\*========================================================================*/
#include "C:\Program Files (x86)\Flowcode 7\CAL\internals.c"

If Flowcode is not saving config data then the default will be:

Code: Select all

__PROG_CONFIG(0x1, 0x3FFF);

For hex file look at one row from last and config information is in Lower, upper byte format.

Martin

[medelec35]

Can you post you flowchart and generated hex file.

[vinctech]

Hi Martin,

Thank you so far! Currently I am experimenting with your suggestions (especially exploring the .c files) and logging screenshots, log-text-files etc.
When I have consistent results, I will report back...