This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Old Code working once properly newly compiled does no longer work properly

The code given below with the date from 2013 in the constant string was complied and exectued correctly in Februar 2013. SAB80C535 and LCD Modul in eight Bit Modus.

Today with the changed date for next year the code was compiled and linked witout any error message but does no longer execute properly on the hardware. Either the the display is not initialzied or the float value is not written to the dispaly or the float value is zero.

If the float operations are deleted, the remaining programm is executed properly.

If only sqrt is computed and written to the string, the string is correctly written to the display. All other char strings and their LCD operations deleted.

Compiling is in Large Code and Large Memory Model. Compiler is the same as in February.
The SAB 80C535 has 56k external RAM. Hardware the same as before.

No clue what has happend since February. The project is unaltered in folders, projectfile and so on, except for the content of the one constant string with the date. And the length of the string is 19 characters plus /n as before.

 #include <reg515.h>
 #include <lcd.h>
 #include <math.h>
 #include <stdio.h>


void main(void)
{

char select;

float x;

xdata char zeile1[20] = "Berufskolleg Hilden";
xdata char zeile2[20] = " 15. November 2014 ";
xdata char zeile3[20] = "   Kreis Mettmann  ";
xdata char zeile4[20] = "    IT-Abteilung   ";
xdata char zeile5[20] = "   Mikrocontroller ";
xdata char zeile6[20] = "   Digitaltechnik  ";
xdata char zeile7[20] = " Schlüsselverfahren";
xdata char zeile8[20] = "                   ";

 init(1,1,0);
 display_on_off(1,1,0);
 entry(1,0);
 home();
 clrscr();

lcdadr(0);
datschreib(zeile1);
lcdadr(63);
datschreib(zeile2);
lcdadr(20);
datschreib(zeile3);

 x = sqrt(2.0);
 printf(zeile8 , "%14.6f" , x);

do
{
                 switch(select % 5)
                 {
                        case 0 :
                                 {
                                        lcdadr(84);
                                        datschreib(zeile4);
                                        warte(2000);
                                        break;
                                }
                        case 1 :
                                {
                                        lcdadr(84);
                                        datschreib(zeile5);
                                        warte(2000);
                                        break;
                                }
                        case 2 :
                                {
                                        lcdadr(84);
                                        datschreib(zeile6);
                                        warte(2000);
                                        break;
                                }
                        case 3 :
                                {
                                        lcdadr(84);
                                        datschreib(zeile7);
                                        warte(2000);
                                        break;
                                }
                        case 4 :
                                {
                                        lcdadr(84);
                                        datschreib(zeile8);
                                        warte(2000);
                                        break;
                                }
                }

                select++;

        }while(1);
 }

Inhalt von lcd.h

void warte (unsigned int zeit);
void init(bit D, bit N, bit F);
void clrscr(void);
void home(void);
void entry(bit ID, bit S);
void display_on_off(bit D, bit C, bit B);
void datschreib(char *z);
void lcdadr(char a7);

Parents
  • What I can see is, that the HEX files are no longer identical in there beginnings.
    Comparing hex files as raw text typically only works well to answer the question "is this code exactly the same as that?" Once the answer to that is "no", you have to look at other files or use other tools to find out what those differences are.

    The primary place to look at is the map file. Usually some functions and variables will have stayed in the same place, while some others have moved. E.g. as soon as a single function's size changes, all functions behind it in memory move around, causing a large number of benign differences in the hex file. The same happens if any variable's size changes (possibly to zero, because it's optimized away).

    But in the end, all this only works to find small changes to the executable code. Which brings us back to things you'll have to check for yourself:

    *) you have to look at all changes made to that program's source code over time. Without a properly working revision control scheme in place, that'll be hard.
    *) you have to debug the non-working code on real hardware, to see what exactly goes wrong. Inspect variables just before and after that sprintf() call, step into functions to see what they're doing, etc.

Reply
  • What I can see is, that the HEX files are no longer identical in there beginnings.
    Comparing hex files as raw text typically only works well to answer the question "is this code exactly the same as that?" Once the answer to that is "no", you have to look at other files or use other tools to find out what those differences are.

    The primary place to look at is the map file. Usually some functions and variables will have stayed in the same place, while some others have moved. E.g. as soon as a single function's size changes, all functions behind it in memory move around, causing a large number of benign differences in the hex file. The same happens if any variable's size changes (possibly to zero, because it's optimized away).

    But in the end, all this only works to find small changes to the executable code. Which brings us back to things you'll have to check for yourself:

    *) you have to look at all changes made to that program's source code over time. Without a properly working revision control scheme in place, that'll be hard.
    *) you have to debug the non-working code on real hardware, to see what exactly goes wrong. Inspect variables just before and after that sprintf() call, step into functions to see what they're doing, etc.

Children
No data