Shutov,

This all depends on how you are building your images. If you are getting the "error, RAM overlaps ROM" at 16 Mbytes, then you are probably trying to build a RAM image. A RAM image means that both the OS's RAM and ROM space are going to be physically loaded into the 32Mbytes of SDRAM. Therefore, we simply split the available memory allowing about 16M for ROM and 16M for RAM.

Now, notice that I said 32Mbytes of RAM. Your kit ships with 64 Mbytes of SDRAM however, due to a couple of issues with the way Platform Builder manages memory during linking and with the way the A40x SDRAM controller is set up, accessing all 64 Mbytes of SDRAM within Windows CE takes some special work. This has been documented many times on this discussion board. If you need more explanation, please contact our support team and they can walk you through the issues.

Finally, we have just discovered a bug that slipped through our A400 LogicLoader release. This bug prevents customers from burning more than 16 MByte images into Flash memory. Look for a patch to come out soon. This will allow you to create 32 Mbyte images and execute them from flash whilst opening up all 32 Mbytes of SDRAM.

--mikee

Thank you mikee,
It explained a lot. But I still have some follow up questions.
For RAM image is it possible to split 32MB of SDRAM somehow else to have more memory for OS image and less for OS RAM?

Also I don't understand how all other people debug their projects since it is very hard to have less than 16 MB in Debug configuration (it means it must be less than 8 MB in Release configuration) with support for LCD and Networking. Burning >16MB into Flash also doesn't work yet, as you mentioned. Does everybody else have much smaller images?

shutov,

All memory mapping is done within the file WINCE420\Platform\xxx\files\config.bib. Look in the Platform Builder help and it will explain to you the format of a bib file. In particular, our config.bib file includes a C-language header file. Typically this is in; WINCE420\Platform\xxx\inc\card_engine\xxx_config_bib.h. We use the header file so we can share memory map information between the linker and source code.

The most common thing to do is to include all of the components that you need in your image. Then, within the final generated ce.bib file, comment out the big libraries and executables. This way, those items will be built and placed in the release directory, however they won't be included in the final image. As long as you have a KITL connection, the CE image will pull whatever it needs from the release directory if it wasn't included in the image. So, it is possible to build a small kernel and have most everything else stored on the host.

Also, you might want to step back a bit and really think about what it is you are trying to debug. If you are debugging an application, you probably don't need a debug build of your operating system. Likewise, if you are specifically working on a single driver, you don't need to debug the entire operating system, just that driver. To do this, go ahead and build a retail version of your image, but include KITL and the debugger (Platform => Settings => Build Options).

You can also mix and match debug and retail builds. That is to say, you can build a retail version of the entire image, then switch to command line and build a debug version of your application, driver, whatever, and then re-link your final image. This will keep the image small but give you full debugging information on those components you are interested in.

For more information and advice, you might want to google the newsgroups:

http://groups.google.com/...oft.public.windowsce
http://groups.google.com/...indowsce.platbuilder

Regards,
--mikee

Another related question. When I build and run RAM image, when I open Control Panel/System/Memory I see that available memory is evenly divided between Storage Memory and Program Memory.

[img:3ksu06zl]http://webpages.charter.net/stellar/sys1.jpg[/img:3ksu06zl]

If I continue to use the system, very soon I get a message about low memory and my Remote Display halts.
But I can move the slider left on System page to add more Program Memory since I don't almost use Storage Memory.

[img:3ksu06zl]http://webpages.charter.net/stellar/sys2.jpg[/img:3ksu06zl]

This way the system is more stable.
Question: How can I set different balance between Storage and Program memory at the build time?

I don't know the answer off hand. But I'm pretty sure that there is a registry setting somewhere that allows you to specify these percentages.

Try searching through the newsgroups.

--mikee

OK, I found it. I'll post it here for somebody else.

Quote:

Question: In control panel there is a way to select how much memory is for storage and how much is for program memory. Whenever I create my image, it defaults to 50%. I there a way to change the default value?

Answer: There certainly is! You can add FSRAMPERCENT to config.bib under the CONFIG section. The format is like this:

FSRAMPERCENT = 0x40404040

The low byte of the number is the number of 4KB blocks per Megabyte in the first 2MB of memory that gets attributed to the file system. The second byte is the number of 4KB blocks for the file system in the second 2MB of memory. The third byte is for the third 2MB of memory. The fourth byte is for the remaining memory.

In our example, there would be 25% of available RAM reserved for the file system.