"How will the image file of the program be modified for each of these cases?":
If you declare it as a local variable, then the total size of your executable will remain the same, but every time you call the function, a large amount of data-copy operations will take place before the rest of the function code is executed.
If you declare it as a global variable, then the total size of your executable will increase, but there will be no additional data-copy operations during runtime, as the image values will be hard-coded into the executable itself (the executable loading-time will increase, if that makes any difference).
So option #1 is better in terms of size, and option #2 is better in terms of performance.
HOWEVER, please note that in the first option, you will most likely have a stack-overflow during runtime, which will cause your program to perform a memory access violation and crash. In order to avoid it, you will have to increase the size of your stack, typically defined in your project's linker-command file (*.lcf). Increasing the size of the stack means increasing the size of the executable, hence option #1 is no better than option #2 in any aspect, leaving you with only one choice to take (declaring it as a global variable).
Another issue, is that you might wanna declare this array as const
, for two reasons:
It will prevent runtime errors (and give you compilation errors instead), should you ever attempt to change values within this read-only array.
It will tell the linker to allocate this array in the RO section of your program, which is possibly mapped to an EPROM on the MSP430. If you choose not to use
const
, then the linker will allocate this array in the RW section of your program, which is probably mapped to the RAM. So this consideration is really a matter of - which memory you're shorter of, RAM or EPROM. If you're not sure, then you can check it in your project's linker-command file, or in the map file that is generated every time you build the project.
"When does the global array get initialized?":
It is initialized during compilation, and the actual values are hard-coded into the executable.
So there is no running-time involved here, and there is something else causing your watch-dog to perform a HW reset (my guess - some memory access violation which causes your program to crash).
NOTE:
An executable program is typically divided into three sections:
Code (read-only) section, which contains the code and all the constant variables.
Data (read-write) section, which contains all the non-constant global/static variables.
Stack (read-write) section, where all the other variables are allocated during runtime.
The size and base-address of each section, can be configured in the linker-settings of the project (or in the linker-command file of the project).