Topic : Variable casting/comparing problem

Forum : 8051

Original Post
Post Information Post
July 7, 2009 - 11:03am
Guest

Variable casting/comparing problem

Hello, Im currently working on migrating a project from Keil to Raisonance (Rkit Lite 80c51 toolchain).
During this process I have experienced a number of weird errors which seem to originate from the way RIDE allocates my variables.
Ill try to make this clear by a couple of code snippets I have prepared:

   #define ADDRESS_1      0XB802
   #define MASK_1      0X01
   #define ADDRESS_4   0XB814
   #define ADDRESS_3   0XB815

   if(XBYTE[ADDRESS_1]&MASK_1)
   {   
      ident=XBYTE[ADDRESS_4];         //identifier (Bit 10...3)
      ident*=256;
      ident+=XBYTE[ADDRESS_3];         //identifier (Bit 2...0)
      ident/=32;      
               
      //ident is now 0x231      
      
      if(ident & 0x7F == node_id || ident==0 ) //node_id is 0x31
      {
         ...
      }
   }

The first if-statement always evaluates true and hence the code in the curly brackets is executed.
In my test scenarios, I have assigned the value 0x231 to ident (after reading from xdata and bit-shifting) and 0x31 to node_id, so the second-if should also be executed.
However, it seems to depend on the way I allocate my variables:
//#2 SUCCESS
typedef unsigned char byte;
typedef unsigned int word;

struct
{   word IDENT;
   byte RTR;
   byte DATEN[8];
} xdata STRUCT_1[MSGBUFSIZE];
struct
{   word    ident;
   byte   rtr;
   byte   dlc;
   byte   daten[8];
} xdata STRUCT_2;
struct 
{   byte   acc_code;   // Acceptance Code
   byte   acc_mask;   // Acceptance Maske
   int      time;      // Busübertragungsgeschwindigkeit
} xdata STRUCT_3;


byte xdata Auftrag=0,M_Auftrag=0,schritt=0,sonder_aufnehmen=0,
      aufnehmen=0,abgeben=0,sonder_abgeben=0,Status,Stoerzeichen=0,
      Halbspiel_aufnehmen=0,Halbspiel_abgeben=0,GS_Zyklus=0,
      outbuf[0x1f],inbuf[0x30],telebuf[0x30],Art,sum,i,
      Wiederh_Riemen=0,flipper=0,merker=0,verschub=0,riemen=0,
      regeln=0,
      adr,ab4,ab5,vt=0,vsoll=0,
      e,s,outpoint=0,inpoint=0,send_wart=0,Dec_Zaehler1,Dec_Zaehler2,Dec_Zaehler3,rtr,dlc,Datenlaenge,/*ip=0,op=0,*/ii,eb1_empfang=0,eb2_empfang=0,dach=0;

byte xdata eb1,eb1neu,eb1zaehl=0,eb2,eb2neu,eb2zaehl=0,eb3,eb3neu,eb3zaehl=0;

word xdata node_id,ip,op;

word Zeit,FB_Zeit,FF_Zeit,pause,rampebe,rampebr,altrampe,ledz=0,wartezeit=0;
      
word xdata Zeit_Rampe_Be,Zeit_Rampe_Br,Zeit_Verschub,Zeit_Riemen,Zeit_Hub,Zeit_Dach,
      Zeit_LS,Zeit_Geber,zvz,Einschaltzeit_Verschub=0,Einschaltzeit_Hub=0,
      Zeit_Verschub_Warte,Zeit_Hub_Warte,alive_led=0,mit_verschub=0,ident,
      Einschaltzeit_Dach=0;
int      CAN_knoten_status=0;
float    v=0,delta;

bit    send_aktiv=0,tele_komplett=0;

bit   G_Fach_links_frei,G_Fach_rechts_frei,G_Vorabschalt_links,
      G_Vorabschalt_rechts,G_im_Regal_links,G_im_Regal_rechts;
      
bit   T_ziehen_links=0, T_verschieben_links=0, T_heben=0, T_verschieben_rechts=0, T_ziehen_rechts=0,G_Hub_oben,G_Hub_unten,G_Vorabschalt,G_Dach_oben,G_Dach_unten,
      G_Tisch_links,G_Tisch_rechts,G_Verschub_pos,Freigabe,
      Hubantrieb=0,Verschiebeantrieb_links=0,Verschiebeantrieb_rechts=0,
      Ziehantrieb_links=0,Ziehantrieb_rechts=0,Dachantrieb=0,
      Grundstellung=0,Fehler=0,ffl=0,ffr=0,fbr=0,fbl=0,s_fbl=0,s_fbr=0,
      Stoerung=0,Automatik,Hand,zyklus=0,links=0,rechts=0,getauscht=0,
      nochmal_aufnehmen=0,nochmal_abgeben=0,
      Verschub_nicht_stop=0,Flanke_Verschub=0,Hub_nicht_stop=1,
      Flanke_Hub=0,ziehen_nicht_stop=1,Flanke_ziehen_aussen=0,
      Flanke_ziehen_links=0,Flanke_ziehen_rechts=0,
      auto_einmal_aufnehmen=0,auto_einmal_abgeben=0,
      LS_Fehler=0,LS_Fehler_Verschub=0,statmerker_C=0,statmerker=0,
      Richtung,tisch_mitte,version_flipper=0,version_belegung=0,
      version_fachtaster=0,version_keinekorrektur=0,version_dach=0,
      Grundst_frei=0,Grundst_belegt=0,Ueberlast_Verschub=0,
      Ueberlast_Hub=0,Verschub_warte=0,Hub_warte=0,
      bus_status,ADDRESS_1_toggle,trans_req=0,overrun=0,
      T_Dach,Flanke_Dach=0,Dach_nicht_stop=0,Ueberlast_Dach=0;

During bugfixing, I allocated my variables the way you can see above and the code is being executed as expected.
However, the following form of allocation results in the second (first code-snippet) if-statement to be evaluated false (given the values noted above) which is, in one word, wrong.
//#3 ERROR
typedef unsigned char byte;
typedef unsigned int word;

struct
{   word IDENT;
   byte RTR;
   byte DATEN[8];
} xdata STRUCT_1[MSGBUFSIZE];
struct
{   word    ident;
   byte   rtr;
   byte   dlc;
   byte   daten[8];
} xdata STRUCT_2;
struct 
{   byte   acc_code;   // Acceptance Code
   byte   acc_mask;   // Acceptance Maske
   int      time;      // Busübertragungsgeschwindigkeit
} xdata STRUCT_3;


byte xdata Auftrag=0,M_Auftrag=0,schritt=0,sonder_aufnehmen=0,
      aufnehmen=0,abgeben=0,sonder_abgeben=0,Status,Stoerzeichen=0,
      Halbspiel_aufnehmen=0,Halbspiel_abgeben=0,GS_Zyklus=0,
      outbuf[0x1f],inbuf[0x30],telebuf[0x30],Art,sum,i,
      Wiederh_Riemen=0,flipper=0,merker=0,verschub=0,riemen=0,
      regeln=0,
      adr,ab4,ab5,vt=0,vsoll=0,
      e,s,outpoint=0,inpoint=0,send_wart=0,Dec_Zaehler1,Dec_Zaehler2,Dec_Zaehler3,rtr,dlc,Datenlaenge,/*ip=0,op=0,*/ii,eb1_empfang=0,eb2_empfang=0,dach=0;

byte xdata eb1,eb1neu,eb1zaehl=0,eb2,eb2neu,eb2zaehl=0,eb3,eb3neu,eb3zaehl=0;

word xdata node_id,ip,op;

word Zeit,FB_Zeit,FF_Zeit,pause,rampebe,rampebr,altrampe,ledz=0,wartezeit=0;
      
word xdata Zeit_Rampe_Be,Zeit_Rampe_Br,Zeit_Verschub,Zeit_Riemen,Zeit_Hub,Zeit_Dach,
      Zeit_LS,Zeit_Geber,zvz,Einschaltzeit_Verschub=0,Einschaltzeit_Hub=0,
      Zeit_Verschub_Warte,Zeit_Hub_Warte,alive_led=0,mit_verschub=0,ident,
      Einschaltzeit_Dach=0;
int      CAN_knoten_status=0;
float    v=0,delta;

bit    send_aktiv=0,tele_komplett=0;

bit   G_Fach_links_frei,G_Fach_rechts_frei,G_Vorabschalt_links,
      G_Vorabschalt_rechts,G_im_Regal_links,G_im_Regal_rechts;
      
bit   T_ziehen_links=0, T_verschieben_links=0, T_heben=0, T_verschieben_rechts=0, T_ziehen_rechts=0,G_Hub_oben,G_Hub_unten,G_Vorabschalt,G_Dach_oben,G_Dach_unten,
      G_Tisch_links,G_Tisch_rechts,G_Verschub_pos,Freigabe,
      Hubantrieb=0,Verschiebeantrieb_links=0,Verschiebeantrieb_rechts=0,
      Ziehantrieb_links=0,Ziehantrieb_rechts=0,Dachantrieb=0,
      Grundstellung=0,Fehler=0,ffl=0,ffr=0,fbr=0,fbl=0,s_fbl=0,s_fbr=0,
      Stoerung=0,Automatik,Hand,zyklus=0,links=0,rechts=0,getauscht=0,
      nochmal_aufnehmen=0,nochmal_abgeben=0,
      Verschub_nicht_stop=0,Flanke_Verschub=0,Hub_nicht_stop=1,
      Flanke_Hub=0,ziehen_nicht_stop=1,Flanke_ziehen_aussen=0,
      Flanke_ziehen_links=0,Flanke_ziehen_rechts=0,
      auto_einmal_aufnehmen=0,auto_einmal_abgeben=0,
      LS_Fehler=0,LS_Fehler_Verschub=0,statmerker_C=0,statmerker=0,
      Richtung,tisch_mitte,version_flipper=0,version_belegung=0,
      version_fachtaster=0,version_keinekorrektur=0,version_dach=0,
      Grundst_frei=0,Grundst_belegt=0,Ueberlast_Verschub=0,
      Ueberlast_Hub=0,Verschub_warte=0,Hub_warte=0,
      bus_status,ADDRESS_1_toggle,trans_req=0,overrun=0,
      T_Dach,Flanke_Dach=0,Dach_nicht_stop=0,Ueberlast_Dach=0;

I also included nonrelevant declarations since the problem seems to be related to all rather than only one variable in my program.
Again to make this clear, snippet #2 results in correct execution of the program, #3 results in the second if-statement evaluating false and therefore wrong execution.
We are testing this program on a 80C32 µController with an xdata-size of 32768.

Is there any compiler-setting that this could possibly be related to or are there any other possible causes?

Replies
Post Information Post
+1
0
-1
July 9, 2009 - 6:11pm
Guest

I am not sure that it's the only problem, but it could be.
In the following statement:
if(ident & 0x7F == node_id || ident==0 ) //node_id is 0x31
it seems that some parenthesis are missing. We always recommend to place parenthesis 'almost everywhere' and it makes things easier to understand.
In this case, the '&' operator has the lower priority than '==', and your expression evaluation matches with:
if( (ident & (0x7F == node_id)) || (ident==0) ) //node_id is 0x31
I am not sure that it is what you are expecting. In this situation, (0x7F == node_id) is 0, and the overall expression is always false.
Let me know if the problem is there, or if you want that I investigate further.
Thanks

+1
0
-1
July 15, 2009 - 3:04pm
Guest

Yes that was indeed the problem it seems, thanks for your reply.
However I have some, namely two, more issues with Rkit Lite 80c51, both of which are hard to reproduce but critical nontheless.
Firstly, sometimes the GUI just crashes without a warning, error or message of any sort. This always happens after succesful complitation. I cant exactly say wether the Ride-GUI crahses during linking (Running LX51 ...) or during converting converting an AOF-File to Intel-Hex (Running OH51 ...). Sometimes its enough to simply reopen Ride.exe and pressing F9 again, sometimes it keeps crashing until I change the code (its enough to add another blank line) and build again (after restarting Ride, the IDE goes right to linking the file if I remember correctly). Typically this happens after adding a structure with bit variables (byte var:1;). (Windows XP SP3)
Secondly, there seems to be a condition under which access to certain variables results in a portion of the code crashing or entering an unreachable state (the while loops which triggers the watchdog keeps running) on our 80C32. Surprisingly after switching around the variable initialization code-block I got it to stop crashing on that part.Since this is hard to reproduce Id like to show you the complete code we are having issues with. I can not however post any of this in public, is there a way I can email you a copy of our program which shows said strange, crash-like, behaviour?
Thanks in advance.

+1
0
-1
July 16, 2009 - 1:44pm
Guest

Hi

Changing the option "options->Target->Launch tools with executable" did not solve this issue?

Regards,
Matloub

+1
0
-1
July 16, 2009 - 2:05pm
Guest

When I check that option I can see a window flashing for a split second and after that I get the following output in the make-tab:
Running RC51 on C:\Users\etcetc\lagv30.c
|.....Unrecoverable Error detected!
The window seems to contains "Running RC51 from command line" and some arguments, its hard to say which ones since, as I said, I can only see it flashing for fraction of a second.

+1
0
-1
July 27, 2009 - 10:06am
Guest

The question remains, can I send you the source-code we're having problems with so you can evaluate and fix the bug we're facing?

+1
0
-1
July 27, 2009 - 10:21am
Raisonance Support Team

Hi,

First, please give us the Build Number (BN) of your kit. If it is not the latest, then you'll want to upgrade before making any more tests.

If you have the latest version (BN758) and still have these problems, please send your example project to 'support@raisonance.com'. We will need a complete compiled project, with sources, includes, listings, obj files, etc.

Best Regards,

Vincent

+1
0
-1
July 27, 2009 - 2:09pm
Guest

I have checked and am indeed running BN758. My email has been sent to .

+1
0
-1
August 5, 2009 - 11:08am
Guest

Any word so far?
Did you get my email, if so, did you find any problems or is it a user error on my end?

+1
0
-1
August 6, 2009 - 10:12am
Guest

Could you check your PATH setting?With RIDE6, Ride\Bin should be present in the PATH definition.
Could you also give us some details about your environment: Windows version, ... THanks

+1
0
-1
August 6, 2009 - 10:32am
Guest

I checked my Path setting and it does contain C:\RIDE(FULL)\BIN (which is my RIDE-directory), I'm running Windows XP Professional (Version 2002) SP3. Hardware-wise this computer has an AMD Sempron 3000+ with 2 Gb RAM (in case this is relevant as well).

+1
0
-1
August 6, 2009 - 12:18pm
Guest

ok... I believe that the parenthesis could be NOT supported in this case... (for the directory name).

+1
0
-1
August 6, 2009 - 1:20pm
Guest

You are right, excluding the parenthesis from the directory name solved the problem of RIDE crashing (by running tools with executable, which now works).
The problem with our specific program, however, remains. We'd be glad if you could still look into it. By now I'm pretty sure that said condition keeps the timer interrupt from working which results in an unresponsive, yet running (since we trigger the watchdog inside the main loop, which does keep running), program.

+1
0
-1
August 7, 2009 - 9:55am
Guest

Quote:
The problem with our specific program, however, remains

I thought you fixed the issue when fixing:
if(ident & 0x7F == node_id || ident==0 ) //node_id is 0x31
Do you have another problem?
If you have a problem with interrupt, I suggest that you disable the optimization option that make the compiler using the 'Absolute Registers".
+1
0
-1
August 10, 2009 - 10:19am
Guest

Said option is disabled, you should check the email I sent to (sent 07/27/2009).

+1
0
-1
August 11, 2009 - 8:21am
Guest

Ok, I look at the email and I will answer.

+1
0
-1
August 25, 2009 - 11:04am
Guest

Just to clear this up, thanks to your help I have solved said problem.