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?
You are Santa Claus, and I claim my $5 !
(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
My deer freinds,
I do'nt know who doctor spam is!
Always your freind.
Zeusti.
(now approved by Geofrey Dunn)
is the name chosed because someone has to be Gullible to believe any of the crap.
"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 "doctor spam" in any way related to professor zuisti (my self proclaimed dear friend...)
Nope. No "revent" (sic) information there.
The good doctor, in addition to being a SPAMMER, is a dunce.
s/c/see/ s/revent/relevant/
.. 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.
nice to c some revent information on following web pages. microcontroller51.blogspot.com/ and see also http://picinf.blogspot.com/
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
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.
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.
"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...
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.
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...
View all questions in Keil forum