Hello I am getting very serious problem, The code written for phillips 89V51RD2 , after some days the code written in keil will not work on the same hardware .If i write same code once again without copy/paste it will work . Please any body have solution for this.
Regards Santosh Hegde.
after some days the code written in keil will not work on the same hardware
... after some days doing what? Whatever the reason for this might be, the Keil compiler quite certainly has nothing to do with it. Even if it tried rather hard, there's no way it could possibly corrupt your code, just because you left it sitting on your PC's hard drive for a couple of days.
But what did Keil do to stop the code from changing? All that is necessary for bugs to triumph is for good programmers to do nothing.
Still, I'd rather blame George W. Bush.
I don't know anything about the C51 tools, but with the ARM tools, I have on three occations had projects that have totally died on me. The first two times, I had to create new projects and then add all source files unchanged.
The second and third times, I could verify that the project file had switched to a completely different processor - not even correct manufacturer.
I have not been able to find out exactly what trigged the change of processor in the project.
Per; I have had the same unscheduled changes occur in my projects. It appears that tools.ini is changed. There is one possible cause for me. I sometimes open more than one version of uVision. In one, I may be working in PK51(moving programs from 8051 to ARM) while I have MDK running in a different window. I can never predict which version of tools.ini will show up. Probably the last project to open will leave tools.ini modified. Also, I often have two uVision MDK projects open. I assume the same results are changing my tools.ini file. I hope to spend a little more time playing with different configurations to possibly identify a true cause. In the next release, I plan to build a completely different path for the two sets of Keil tools with different uV3 and different tools.ini. Bradford
I totally missed my point. The corrupted files are frequently older files pathed by the corrupted tools.ini rather than newer files changed. Re-loading the files repairs the broken paths. Bradford
Interesting. I will take a closer look the next time I get the problem.
Hello sir i think you didnt understand point.I think it is the problem related to the HEX file genarator. let me explain the steps what i did, 1. Created the project. 2.Wrote some code for My Hardware ,it worked very fine. 3. After some days later i loaded same file in the project and complied it .Now the problem occurerd for the same Hardware. 4.Then I created new source file. I typed same code. and reloaded it in project,complied it. I found it to be working fine. This what my problem.
I HAD SAME PERBLOM BUT SET IG BIT OF SCIN REGISTER
"I HAD SAME PERBLOM BUT SET IG BIT OF SCIN REGISTER"
Why did you choose to write that in ALL CAPITALS? Writing in ALL CAPITALS just makes the text harder to read, and is considered to be SHOUTING - hence rude! Please don't do it!
Are you saying that setting "IG bit of SCIN" seemed to cause your problem, or cure it?
Sorry for SHOUTING. I didnt notice my caps lock was on.
As i said I try IG bit of SCIN.
Sorry I didnot answer youre question fully.
Before I tried controlling LCD with PM bit of SMAP and RL bit of GMAP but this donot work :(
I try IG bit of SCIN and it did work :)
"I didnt notice my caps lock was on."
You didn't pay attention to the Preview of your post, then?
"...with PM bit of SMAP and RL bit of GMAP but this donot work; I try IG bit of SCIN and it did work"
So how does this relate to the rest of this thread, where the same code apparently sometimes works and sometimes doesn't?
weeeeeeep
I feel soooooo stupid ------- NOT
bcoz I had the same problem where the code sometimes did work and sometimes does not!
Also the PSU sometimes had excessive ripple