hello,
I have to initialize static variables residing in sdata after setting bit XPEN in main() by myself, because in our system it is not possible to set bit XPEN prior to the initialization loop in the startup code.
For that I have to know the structure of C_INITSEC but I could not find some info, besides info about C51 where sdata is not mentioned.
Do you have got some?
Best regards
Jürgen
because in our system it is not possible to set bit XPEN prior to the initialization loop in the startup code
That statement makes no sense. There is no such thing as "your system" in the phase of system startup before the init loops. That's Keil's, or possibly the CPU maker's system you're looking at, not yours.
If your "system" makes this impossible, then your "system" itself is, for all practical purposes, impossible.
Hello Hans-Bernhard Broeker,
you are very good in putting solutions into question but that is not what I expect from a forum like this, at least not only.
In our case we are the cpu makers and we are the OS makers and we are shure there are other solutions but thought it would be easyest to initialize sdata only "again" after setting XPEN (maybe with parts of the startup code). But therefor we have to know how to recognize sdata adresses.
Well, I think Andrew Neil is right and I will contact Keil support direct.
Thanks
But if you now have specific expectations from about this forum - don't you then think you should give us an answer to why you wrote "because in our system it is not possible to set bit XPEN prior to the initialization loop in the startup code"?
Exactly why do your project require XPEN to be set first when you reach main()?
Lots of projects requires us developers to perform changes to startup files (such as modifying clocking or powering up peripherials or memory modules etc) before we continue with the rest of the Keil initialization code. Why is this not possible for your project?
putting solutions into question
Interesting you think anybody was doing such a thing before any solutions were even mentioned.
thought it would be easyest to initialize sdata only "again" after setting XPEN
And how is that ever going to be easier than the painfully obvious choice of just setting XPEN right there in the startup code?
Why are you building obstacles for yourself that you can't cross?
To satisfy your interest I tell you that our software is running on different hardware. To detect the hardware at hand we have to check different things like input voltages but also complex things like protocols on serial interfaces. Things you really do not want to do from startup code. Unfortunately we have to change value of XPERCON register to meet the requirements to detect several interface cards. But XPERCON is not changeable after setting XPEN, so there was our problem.
I solved it by creating an assembler routine, copying the complete initialization routine into it and prohibiting writing to memory if the address is not in range 0xE000 - 0xEFFF
In doing that I did not have to understand the comlete structure of the initialization routine but only to find the writing to the target address.
CMP DPP3,#3 JMPR cc_NE,NoSdataInit JNB R3.15,NoSdataInit ; DPP3 JNB R3.14,NoSdataInit ; DPP3 JNB R3.13,NoSdataInit ; <0xE000 JB R3.12,NoSdataInit ; >0xE7FF JB R3.11,NoSdataInit ; >0xE7FF MOVB [R3],RL5 ; wirte value (1 Byte) DPP3:R3 NoSdataInit: ... ... StoreBit1: ;bits are not in sdata do not write ; MOV [R3],R4
Thank you for making me think harder ;-)
"I did not have to understand the comlete structure of the initialization routine but only to find the writing to the target address."
You are assuming that there's nothing in the "other" parts that could interfere with this...