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);
"Hardware the same as before"
Are you sure? Because sometimes even a _revision_ change of a component can cause trouble, if your software is "on the edge".
Test the old binary/hex on the current hardware, test new code on same hardware. Hardware will BE the same. If it still fails do some basic analysis of the code actually generated. Do some basic debugging and sanity checking. Get a scope validate timings against display documentation.
Thnak you very much for your hints.
Hardware is unchanged. It is a teaching system from hps, already in use since 2000. The LCD Modules are those which we use for the last five years.
As said, testing in parts, first without floating point, all writng to the LCD works fine. Second test floating point sqrt alone with sprintf works fine.
Combination in the old file does not longer work.
To the best of my knowledge, the compiler is unchanged. There is no auto update I believe. I have no rigths to install software. That is done by the admin.
What I can see is, that the HEX files are no longer identical in there beginnings. But I have no explanation why. It is not possible to post the complete hex-files.
The complete HEX-Files are just 12k. 11.4k or 11.5k
Old Hexfile from 2012
:0417EB004100D600E3 :10177B00E4FDFCC3ED9FEC9E5015E4FBFA0BBB00A4 :0F178B00010AEB64374A70F50DBD00010C80E4D4 :01179A00222C
Old Hex File >b>2013
New Hexfile 2013
:10150D002531342E3666004265727566736B6F6CCD :10151D006C65672048696C64656E002031352E203E :10152D004E6F76656D626572203230313420002049 :10153D0020204B72656973204D6574746D616E6EFC :10154D002020002020202049542D41627465696CB3 :10155D00756E67202020002020204D696B726F630F :10156D006F6E74726F6C6C65722000092044696730 :10157D006974616C746563686E696B20200000206E :10158D005363686CFC7373656C7665726661687223 :10159D00656E0020202020202020202020202020CB :0715AD002020202020200077
to the best of my knowledge, the compiler is unchanged try to deoptimize, set it to 2. If your timing stinks, that could be the cause. If it is, fix your code.
Erik
Shouldn't this be an sprintf(zeile8 , "%14.6f" , x)? If not, take a look at your implementation of printf.
The "printf" & "sprintf" functions can be troublesome on some controllers. Like for example, yesterday nite, i was using the function to convert integer into ascii on an 8051controller. And the unfortunately, the converted string was never displayed on the LCD. An extra 30mins or so, was wasted in figuring out that problem. I, then wrote own itoa function and instantly everything was working. (I has downloaded the latest evaluation version of keil c51)
So, if the other strings are being displayed on the LCD, and only the converted string is not being printed then you know where the problem is.
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.
Nonsense. Just because a change removed a bug doesn't mean that the thing that changed actually was the problem. And it definitely doesn't mean the problem is the same in every single case that shows vaguely similar symptoms.
...doesn't mean that the thing that changed actually was the problem. Well, i didnt mean that the "sprintf" or "printf" is/was the problem. But the bug will be solved by looking into the implementation of the function.
Shouldn't this be an sprintf(zeile8 , "%14.6f" , x)?
Seconded.
Cursing. Yes it has to sprintf.
And the difference in the Hex File is due to the order of the object files linked. Reverse order of linking the object files I get the beginning as form the 2012 Hex file. lcd functions linked first. Very interesting.
I am aware of difficulties arising from functiosn with variable lengt of parameters and reentrant due to memory size and how parameters are handed to functions. But i am not an expert on it.
Can't test it on the hardare until 4. November due to holidays. The hardware remains at school.
Thnak you very much for your suggestions. Helps to consider things under a different point of view.
why do you answer in other threads when you can not even answer a simple question in your own well i have tried to answer all the questions and also accepted my mistake on that thread. I answered this thread coz, as pointed, i had just faced a problem that looked identical to me.
Many a times it happens that the bug is solved but not due to assumed reasons. And there are expert people over here how correct the assumptions. (like Hans-Bernhard Broeker pointed out).
I think its ok to make mistakes, if you are willing to correct them.
PS: The SSP interrupt routine is now working successfully for few frame transfers. Though a thorough testing is required.
well i have tried to answer all the questions I still do not see what chip
Well, the project compiles and links without error and rus on the target harware as intended.
There is one disturbing detail. I have not found, what the real error was.
As it is a small project, I have ratianed the sourcefile for the lcd functions and the headerfile for the lcd function.
I have completely rewritten the source of the main function manually. I changed xdata to idata and selected the small memory model and Code optimatization 0.
#include <reg515c.h> #include "lcd.h" #include <math.h> #include <stdio.h> idata char zeile0[20] = "Berufskolleg Hilden"; idata char zeile1[20] = " Kreis Mettmann "; idata char zeile2[20] = " 30. November 2013 "; idata char zeile3[20] = " IT-Abteilung "; idata char zeile4[20] = " Digitaltechnik "; idata char zeile5[20] = " Microcontroller "; idata char zeile6[20] = " Telekommunikation "; idata char zeile7[20] = " Kryptologie "; idata char zeile8[20] = " "; data float wert; void main(void) { char select; wert = sqrt(2.0); sprintf(zeile8,"%15.6f ",wert); init(1,1,0); display_on_off(1,1,0); entry(1,0); home(); clrscr(); lcdadr(0); datschreib(zeile0); lcdadr(64); datschreib(zeile1); lcdadr(20); datschreib(zeile2); do { switch(select % 6) { case 0 : { lcdadr(83); datschreib(zeile3); warte(2500); break; } case 1 : { lcdadr(84); datschreib(zeile4); warte(2500); break; } case 2 : { lcdadr(84); datschreib(zeile5); warte(2500); break; } case 3 : { lcdadr(84); datschreib(zeile6); warte(2500); break; } case 4 : { lcdadr(84); datschreib(zeile7); warte(2500); break; } case 5 : { lcdadr(84); datschreib(zeile8); warte(2500); break; } } select++; }while(1); }
So perhaps you should look carefully at your xdata implementation - again, timing would be prime suspect...
Is the LCD connected to the data/address bus...?