Structure of C_INITSEC

No, you don't have to.

You could, instead, just provide all the initialisation in your own source code.

Given that Keil don't document the feature, it's probably best not to rely upon it!

If you want a specific response from Keil, you need to contact Keil support direct.

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

Jürgen

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 ;-)

Jürgen

"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...