We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Parts of the address area where are not used by the application are not zero (0x00000000)?
e.g. memory areas for CS signals, which were not used?
best regards Joe
There is no reason for the tools to do anything with memory areas that are not used - so you should regard their contents as undefined.
For specific details, you're going to have to state what toolset(s) you're using...
If you want to specifically set otherwise unused areas to some specific value(s), then that's probably best done via the startup code.
Ì'm using the MDK version for ARM.
I only take a look into the memory window and I was a little bit surprised about the values in unused memory areas.
Joe
"I was a little bit surprised about the values in unused memory areas."
Why were you surprised?
What did you see?
What were you expecting?
What contents do you think unused memory has in your PC? Do you think the PC will clear potentially several GB of RAM when a little tiny tool is started?
Some memory technologies will always start in a fixed state on power on. Some memory technologies will result in a semi-random state on power-up. The tools are - according to the C standard - required to give all global variables a fixed startup state. Either initialized to zero or to a predefined startup value. A good multi-user OS is also required to clear any allocated memory block assigned to a process, to make sure that information may not leak unintentionally between users.
An embedded system is not a multi-user system, so there is no need to clear all accessible memory to protect from information leakage between different users.
All tools intended for embedded development allows specific variable areas to be uninitialized - to allow some variables to survive a reboot.
But, the C rule about initialized variables is _only_ applicable for defined variables, i.e. the part of RAM that you are using. The Keil tools don't know how important it is that your application boots quickly, so a reasonable assumption is to do just the minimum work needed. You can then configure the tools to zero-initialize a larger memory area, or add own memset() code.
When a development tool (or any other tool for that matter) doesn't do what you expect, there are basically three roads to take:
1) Complain that something is wrong with the tool.
2) Ask why the tool behaves as it does.
3) Spend some time figuring out if the tool behaviour may be meaningful and hence intentional, or if the only reasonable solution is that there is an error in the tool.
At least 99% of people choosing the #1 road will be wrong. Most errors are misconceptions or user errors.
#2 may sometimes be a quick way to get an answer, but it is also normally a way that very slowly increases knowledge. The difference between asking and accepting an answer without questioning it, and yourself figuring out a solution is very big. Spending time figuring out solutions means that you get the knowledge to transfer experience directly to future problems. Living on canned answers means that you don't have an idea when the answer is applicable, so whenever you get a new problem, you have to ask new questions.
Next time something doesn't work as expected, I recommend that you spend some time figuring out a reasonable explanation for the behaviour. Then post the problem and what you think is the reason (including why you think so). You can then improve by comparing your reasoning with the answers from other posters.
"The Keil tools don't know how important it is that your application boots quickly"
They also don't know if there might be certain areas of memory that are mapped to some hardware, or if there are other reasons why writing to it might be a Bad Thing...