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

Array intialization

I'm seeing some strange behavior when initializing arrays. I'm using the following code to intialize a 256 element array to zeros:

xdata char myarray[256] = {0}

The code seems to hang when I run this using my debugging hardware. If I run this with the simulator it seems to work fine. If I reduce the number of elements to 50 it works OK, but increase it to 60 and I get it to hang again. Has anyone seen this before? Is it a hardware issue vs compiler/assembler issue?

  • Have you verified the map file against the actual fysical memory you have? Is the xdata internal or external RAM? If external - have you configured the chip to turn on external addressing?

    Another thing - I don't know exactly how smart the C51 compiler/linker is, but your variables will be zero-initialized even if you don't assign zero to them. Without an assign, you will be sure that the startup code will not have to decompress and assign any information stored in flash but will just zero-fill the memory.

  • What is your "debugging hardware" ?

    Does it allow you to see exactly where it is "hanging"; eg, by using an ICE or on-chip debug?

    As Per says, if it works in the Simulator but not the real hardware, then a hardware incompatibility and/or hardware fault must be the prime suspects...

  • The code seems to hang when I run this using my debugging hardware. If I run this with the simulator it seems to work fine. If I reduce the number of elements to 50 it works OK, but increase it to 60 and I get it to hang again. Has anyone seen this before? Is it a hardware issue vs compiler/assembler issue?
    my guess is that when using 50 you stay within the amount of XDATA your board has with 60 you exceed it.

    Erik

  • "my guess is that when using 50 you stay within the amount of XDATA your board has with 60 you exceed it."

    Quite possibly.

    As Per suggested originally, a check in the Map file would confirm that...

  • Thanks for the prompt responses. I went back and reviewed my code and noticed the watchdog timer was enabled. The watchdog is enabled by default on a reset and was timing out before the initialization could complete. This explains why seemed to hang and is why it works fine with a 50 element array, but not with 60 elements. I took Per's advice and removed the explicit zero initializations and now allow the compiler to do it for me.

    Along the same lines...I noticed a substantial decrease in the code size when I move nonzero global variable initialization into the main body of code instead of when I define the global variables. I saw a reduction of close to 130 bytes for a single variable if I go about things this way. Is there really that much "black magic" going on in the startup code? This is very surprising as it only takes 3 bytes to assign the same nonzero value in the main body.

  • When you have initialized global and static variables, then the linker will take all the initialized data and compress and store in a block in the flash. Ãou will then get a decompress function from the runtime library that will decompress this data from flash and assign to your variables.

    A non-global or non-static variable that has an assign is not considered initialied data, i.e. the compiler will generate code that assigns the value when the execution reaches that point in the code.

    The next thing to think about: Make sure that you separate initialized data that will be modified by your program, and initialized data that will never change. If the data need never change, then you should modify the source code so you don't get a RAM copy of the variables. Your program can access the values directly from the code memory (normally flash) instead.

  • The watchdog is enabled by default on a reset and was timing out before the initialization
    had you mentioned your derivative (I guess a SILabs deviate (f3x-up)) cheking the watchdog would have been the first advice you got

    Erik

  • nice to c some revent information on following web pages.
    microcontroller51.blogspot.com/
    and see also
    http://picinf.blogspot.com/

  • .. would shut down.

    It seems that waay too many figure that they can start a forum as a means of making themselves feel important, and do not give a friggin hoot that the information get spread so thin that it becomes virtually impossible to find.

    Erik

  • "nice to c some revent information ..."

    Nope. No "revent" (sic) information there.

    The good doctor, in addition to being a SPAMMER, is a dunce.

    s/c/see/
    s/revent/relevant/

  • is "doctor spam" in any way related to professor zuisti (my self proclaimed dear friend...)

  • "nice to c some revent information ..."

    Yes, it would be nice to see some relevant information - for once - in the links posted by Dr Spam...

  • is the name chosed because someone has to be Gullible to believe any of the crap.

    Erik

  • My deer freinds,

    I do'nt know who doctor spam is!

    Always your freind.

    Zeusti.

    (now approved by Geofrey Dunn)

  • (now approved by Geofrey Dunn)
    as that the same as when you claimed approval by me because I posted that one of a hundered of your posts were correct?

    Erik