odd eeprom behavior

gfbankston · Joined: 21 Jul 2014 Posts: 35

Hello,

I have moved from the free XC8 compiler to the CCS for PIC18F.

My chip is the PIC18F25K50 and the compiler is the latest version.

If I do this:
unsigned char i;

i = 5;
write_eeprom(0,i);
i = read_eeprom(0);

location 0 in the EEPROM tab view in MPLAB X never changes from 0xff.
However, i is also not changed from 5 after the read_eeprom(0);

This is also the case with the eeprom routines I wrote myself.

But, under the XC8 compiler with MPLAB X, location 0 (and all others)
DO show up correctly under the EEPROM view.

What is going on?

TIA

GlenB

temtronic · Posted: Wed Jul 30, 2014 11:54 am

If you're running a version of MPLAB like 8.63 be sure to set the 'build configuration' to 'release' and NOT 'debug'( the default).

Without seeing your entire complete program it's a 'guessing game' though I've solved one problem this week with 'release' !

hth
jay

ezflyr · Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA

Hi,

In the absence of a small test program and the version number of your compiler, what can we really say?

My guess is that your PIC isn't even running. Blink an LED and see if it really is!

John

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

It is completely unclear, what you are actually doing.

Are you running in debug mode?. Accessing the ROM, from inside MPLAB, suggests this, in which case then you do (of course) want to be building in debug mode, not release (opposite of temtronics comment).
If you are in debug mode, and compiling for debug, then the most likely thing, is ezflyr's comment, that the chip is not actually running. Possibly oscillator settings etc..

I took the chip with an 8MHz crystal attached, with the 5.026 compiler, and tried the following:

gfbankston · Joined: 21 Jul 2014 Posts: 35

Well,all I can say is that the debugger is running, and would not run unless I was using the debug compiled code...

The ram view seems to work fine, changing ram is not a problem in MPLAB X.

Maybe there is something to what you are saying about not running the debug version of the code. If I hit the left button to Make Clean MPLAB X brings up the CCS compiler and completes. The I hit the right button to Launch the debug session and it recompiles again, presumably to make a debug version of the code so it can launch the debugger.

Another thing I have noticed: if I run the XC8 version of the code on the debugger it loads all the default values into eeprom. Then, when I run the CCS version of the code, the board runs fine. I am assuming it is because the eeprom now has the proper values in it, put there with the XC8 version of the code.

GlenB

temtronic · Posted: Thu Jul 31, 2014 8:11 am

I don't use MPLAB X however in the MPLAB 8.xx version I KNOW you cannot compile in 'debug' mode and have it run in the 'real world'.I t just ain't going to work!!!

Life is too short to figure out why, and frankly I don't need to know....as I do all my debugging in the real world as no simulation works right 100%
I do know that 'debug' mode adds code, changes fuses, etc.

hth
jay

gfbankston · Joined: 21 Jul 2014 Posts: 35

Hello,

I forgot to mention that I ALWAYS am running in debug mode.

I have too many problems with this compiler to 'fix' before I can go to a release version.

For instance, I found out that 16-bit read and writes do not work to SFR registers.

#word MCU_TMR0 = 0xFD7
#byte MCU_TMR0H = 0xFD7
#byte MCU_TMR0L = 0xFD6

MCU_TMR0 = 0xff15;
does not do a thing!

but
MCU_TMR0H = 0xff;
MCU_TMR0L = 0x15;
works!

Same thing with ADRES register. Had to access it 8 bits at a time.

Too many items in the learning curve...

I converted my board from Atmel because of the price increases Atmel imposed. Initially, it took about 1 1/2 days to get the free XC8 compiler to run my old Atmel code, mainly time spent learning the PIC18F25K50.
That XC8 code has no issues that I can find, but the free compiler uses 72% of the code space before the USB and bootloader are even brought in. The CCS is at 51% of code space.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

It's not a compiler bug. You're confused about the Endiness. Microchip
uses the Little Endian (LSB first) method of storing variables which are
larger than a byte. Just change the #word declaration to LSB first and
you'll find that it works just fine. Example:

gfbankston · Joined: 21 Jul 2014 Posts: 35

OK, will try it. However, these SFR definitions come directly from what the CCS folks told me to do:
Goto View, Registers, then select your chip, then output the register definitions to a file.

I did that, and that is where I got these from. You are telling me CCS is giving me bad info...

gfbankston · Joined: 21 Jul 2014 Posts: 35

Yes, changing the #word definition worked, and thanks...who knew that CCS output file would be WRONG!

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I don't have the IDE, but if that's what they're doing, then it's a bug
and should be reported to CCS tech support.

When they declare a #word register in the .h file, they do it correctly.
The word address is the LSB address. Example:

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

Comments:

Register defines for CCS are 99% not needed.
The timer is available from the set_timer, and get_timer functions. The few (very few) registers that are worth accessing, are often already pre-defined in the processor include file.
This is why nobody uses the include file.
Think 'CCS', not 'XC'.

If you want to access the register use the getenv ability. This returns the correct address.

The 'auto include' file uses old syntax, and is often wrong (whoever you spoke to at CCS ought to be shot for recommending it), unless you specifically asked a question like 'how can I get a file of register defines like XC uses', for which this is the answer, but is also still often wrong.

gfbankston · Joined: 21 Jul 2014 Posts: 35

Thanks for the tip about get_env

Well, all I ever have done is direct access to the chips for the past 30+
years. I am not about to learn a new way. But, for new guys, or guys who have no desire to learn how the chip actually functions, this is fine.

And yes, I asked them about direct access. That is when they told me how to 'create' the register file .h They did not tell me about get_env

I know about software too, and how some folks feel about other guys code.

Just image someone who has done nothing but assembly language for 20 years suddenly starting to use C. I still do it the same way, read the data sheet on the chip first. Second, if a question arises, try and find some other guys code (where they tell you the code works).

Heaven help you if the data sheet for the chip is wrong. That HAS happened to me before.

GlenB

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

Only 20 years....

Many of the old hands here helped design the first micros, and wrote some of the parts of the languages used today. I have a first edition of K&R, signed by Brian Kernighan. However one thing you should have learnt, is 'use tools'. If I want to reduce the diameter of a rod, I don't go filling it down, but use a lathe....

temtronic · Posted: Thu Jul 31, 2014 3:21 pm

Glen
I'm in the same boat, different paddle ! 'Grew up' on assembler sqeeeeezing every bit of code out of real 'core'.
One thing to read and reread is the great examples that CCS supplies in the examples folder. There's a LOT of nice 'tidbits' there.Also, pressing F11 while your project is open, accesses the Help files. Yeah, it's always open for me....been 20+ years with 'C' and I still can't wrap my head around some things.
And have a look at the code in the 'code library'.Some really good code there as well!
I do know if you do a few hours a week some of it does get burned onto the grey cells.

jay