where do I set the “available” memory for managed app in the scatter file ? I have tried different locations but none of them do increase the total memory given by GC.GetTotalMemory(true)
what’s the meaning of the deployment sectors in define.h ? I have set it to #define DEPLOYMENT_SECTORS { { 0x0A, 0x080C0000, 0x00020000 }, { 0x0B, 0x08100000, 0x00010000 }, { 0x0C, 0x08110000, 0x00010000 }, { 0x0D, 0x08120000, 0x000E0000 } } and it gives me a nice message when flashing the board : Assemblies deployed. There are 1 078 600 bytes left in the deployment area. And the program just runs fine.
But what are the real implications of this setting ? In my example above, I am eating up all the flash memory for deployment but perhaps I could use less for deployment and give more room for other things ?
An important thing to keep in mind is the scatterfile is not something TinyCLR has a prescribed format for. The ones we provide are useful starting points that you can feel free to customize to your needs. To dive a bit deep into your specific questions:
The memory available to your application is controlled by the range passed to TinyCLR_Startup_AddHeapRegion. In our provided main.cpp you can see that we extract that information from {target}_Startup_GetHeap. For STM32F4, that function is implemented using the global symbols HeapBegin and HeapEnd which are defined in the assembly file to the regions SectionForHeapBegin and SectionForHeapEnd. Other devices may follow a different implementation. So looking in the scatterfile you can see those regions set to use whatever given addresses at ER_HEAP_BEGIN and ER_HEAP_END. For the FEZCLR in this release, it’s 0x20006C00 and 0x20016000.
GC.GetTotalMemory is a measure of memory used by your program, not available to it. Unfortunately there is no measure of remaining memory available at this time (even if there were fragmentation would still complicate things). You can do a test of memory available as you change the scatterfile by adding a bunch of arrays like new byte [1024] to an array list.
For deployment settings, it is very device specific. Again, sticking with the FEZCLR, DEPLOYMENT_SECTORS is used to initialize the variable deploymentSectors of type struct DeploymentSector in STM32F4_Deployment.cpp. This file uses the internal flash of the processor as its storage area, but only the sectors specified by the define in question. The parameters are, in order, id, address, and size. The latter two are pretty obvious, the sector address and its length. id just refers to the sector number specified by ST. You can find the available sectors from the specific processor datasheet. Which you use are up to you, it depends on how big the firmware you are using is and if you have any sort of bootloader. So you need to consider both the scatterfile for the firmware itself and this define for deployment when setting your regions. You certainly could allocate less space for deployment if you have use for the space elsewhere.
Just to add a simple rule of thumbs, analyze the .map file generated by gcc compiler and you have an idea of the tinyclr compiled code size, it gives you exact locations where code ends. Then you can estimate what sectors are free for program deployment. You need obviously a reference for your device MCU memory/flash configuration available.
Ps: same apply to ram to adjust .ldf file for device.
Thank you very much to both of you !
I think I have enough information to dig a little bit deeper in this area.
I still have one last question (at least for now) : can RLP be located in Flash ? Right now, it is located at the top of SRAM (STM32F427) for a little 4KB.
