Jump to content
Sign in to follow this  
jevdsnny

Compiler Error

Recommended Posts

Two programs, both with the exact same functions and variables, just one declaration moved between the two. One works, one doesn't...100% repeatable...try it for yourself! Target is a 16F84A with JDM and IC-Prog. The one that works writes a byte to the EEPROM, the one that doesnt, doesnt. I'm gonna wade thru the hex code to see if I can figure it out, but that doesn't help much...

 

==========good program==========

#include <system.h>

 

 

char i;

char j;

char a;

 

void DebounceDelay() {

 

for ( j = 0; j < 100; j ++ )

for ( i = 0; i < 100; i++ )

a = 0;

}

 

char Addr;

char Data;

 

//save the current setting to EEPROM

void SaveSetting () {

 

char WriteInProgress;

 

//wait for any prior writes to complete

//very unlikely in this particular application

WriteInProgress = eecon1;

while (WriteInProgress & WR)

WriteInProgress = eecon1;

 

eeadr = Addr;

eedata = Data;

 

set_bit ( eecon1, WREN ); //enable writes

clear_bit (intcon, GIE); //disable any interrupts

 

eecon2 = 0x55; //magic sequence for writing

eecon2 = 0xAA;

set_bit ( eecon1, WR ); //do the write

 

clear_bit ( eecon1, WREN ); //disable writes

 

 

}

 

 

 

 

void main() {

 

Addr = 0;

Data = 10;

 

SaveSetting ( );

 

DebounceDelay();

 

}

=============================

 

==========bad program==========

#include <system.h>

 

 

 

char Addr;

char Data;

 

//save the current setting to EEPROM

void SaveSetting () {

 

char WriteInProgress;

 

//wait for any prior writes to complete

//very unlikely in this particular application

WriteInProgress = eecon1;

while (WriteInProgress & WR)

WriteInProgress = eecon1;

 

eeadr = Addr;

eedata = Data;

 

set_bit ( eecon1, WREN ); //enable writes

clear_bit (intcon, GIE); //disable any interrupts

 

eecon2 = 0x55; //magic sequence for writing

eecon2 = 0xAA;

set_bit ( eecon1, WR ); //do the write

 

clear_bit ( eecon1, WREN ); //disable writes

 

 

}

 

char i;

char j;

char a;

 

void DebounceDelay() {

 

for ( j = 0; j < 100; j ++ )

for ( i = 0; i < 100; i++ )

a = 0;

}

 

 

 

void main() {

 

Addr = 0;

Data = 10;

 

SaveSetting ( );

 

DebounceDelay();

 

}

============================

Share this post


Link to post
Share on other sites

Can you edit you post and mark the differences. Otherwise it's not easy to spot them.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

The only different between the two programs is the declaration location of the two functions.

 

In the "good" program, the order is:

 

DebounceDelay

SaveSettings

Main

 

In the "bad" program, the order is:

 

SaveSettings

DebounceDelay

Main

 

There are no other differences in the code. The code in each of the programs is identical except for the order of declaring the functions.

Share this post


Link to post
Share on other sites
The only different between the two programs is the declaration location of the two functions.

 

Have you tried to debug code to see where it actually goes bad?

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Just like the post says- when you run the "good" program, it writes a byte to the EEPROM data, when you run the "bad" program, it doesnt write a byte to the EEPROM data, even though they are the exact same code with just the declarations switched.

Share this post


Link to post
Share on other sites

And this happens only on real target. Right? Maybe some timing issues.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

I dont see how it could be a timing issue- it is 100% repeatable; I've tested it at least 20 times over the past three days on each scenario- the "good" one always writes the byte and the "bad" one always doesn't- that would be a huge coincidence.

Share this post


Link to post
Share on other sites
I dont see how it could be a timing issue- it is 100% repeatable.

 

The timing in the "bad" code if different than in "god" code and this could make it fail 100% of the times. There may be something elso too but not likely related to the compiler.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
I dont see how it could be a timing issue- it is 100% repeatable.

 

The timing in the "bad" code if different than in "god" code and this could make it fail 100% of the times. There may be something elso too but not likely related to the compiler.

 

Regards,

Pavel

 

 

take a look at the code- its exactly the same...i would agree if the code were different, but its not. the contents of the two procedures are identical. the calls are identical. the only thing that differs is the order of the declaration of the procedures. there is no way the timing can be different. even so, timing doesnt have much to do with it. interrupts are disabled. the circuit is just an RC clock and reset tied to VDD. nothing else. all it does is write a byte, call the delay loop and then enter an infinite loop. it seems that you are concluding that the compiler is not at fault without tryintg to diagnose the problem, so i am not going to chase the issue any more. ive already spent 3 days debugging this thing and its not working so im just going back to mplab and assembly because i dont have any more time to spend on it.

Share this post


Link to post
Share on other sites
take a look at the code- its exactly the same...i would agree if the code were different, but its not.  the contents of the two procedures are identical.  the calls are identical...

 

If the code is identical than why do you think that something is wrong with the code? I'd say a wrong part is somewhere else. Beside code what is left: timing, data (variables) or hardware. You also say that under debugger both versions work. Than I'd filter out data too. What is left: timing and hardware (or maybe something else that we missed. Do you have any ideas?).

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Also try to add endless loop at the end of main. When code returns from main (what never is supposed to happen) the behaviour is unpredictable. Maybe that's the cause of the problem.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

jevdsnny,

 

I'm just interested how do you know that your code is failing on the actual target ?

 

Presumeably you add some code to read the EEPROM back and show the result to the outside world. If this is the case, then that dramtically affects you program.

 

If you have two projects one that demonstrates the problem, and one that doesn't then please send them to support@picant.com, and I will investigate futher.

 

It maybe that your pick has a bad memory location, when the code is changed, it changes which locations are used for what. This may then use the bad memory location for data that doesn't matter so the code succeeds.

 

The simulator is very well trusted, although timing with respect to EEPROM writes made be better than the actual hardware, ie the simulator operates like a more ideal device.

 

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...