Building problem: 4.2 OSHW Ethernet firmware for Cerberus with MDK-ARM

I have tried building the Ethernet firmware by changing the TinyCLR.proj file per the post on building the Hydra firmware.
As expected that throws a build error that the LR_TARGETLOCATION is too small.
It builds with that increased to a code size of ox08000

But it doesn’t run. A quick look at the .map file reveals that


      Code (inc. data)   RO Data    RW Data    ZI Data      Debug   

    454592     195716      43348       2836      62296      92704   Grand Totals
    454592     195716      43348       2836      62296      92704   ELF Image Totals
    454592     195716      43348       2836          0          0   ROM Totals

==============================================================================

    Total RO  Size (Code + RO Data)               497940 ( 486.27kB)
    Total RW  Size (RW Data + ZI Data)             65132 (  63.61kB)
    Total ROM Size (Code + RO Data + RW Data)     500776 ( 489.04kB)

This won’t fit in ER_RAM_RW as that it in CCM after the stack which is set to 16K leaving 48K; so this will go over. Indeed looking at the map shows it placing items outside the address range of CCM.

Obviously the build uses more memory than we have. I have used NETMF PK4_2 with ghiopensource-22347. The lwip_selector.h file is not altered and I notice is the same values as the NetduinoPlus2 source.

Was the GHI OSHW Ethernet firmware built with any special options or scatterfiles? What size is the ER_RAM_RW region?
The non Ethernet firmware builds fine.

@ FGTH - Welcome to the community.

I have not built the firmware with Ethernet support so I cannot provide any insights on the build settings. I believe GHI uses the RVDS to build the firmware.

You will need ot change the size. We do not have a special build but it fits as we use commercial compilers for stock firmware, not GCC.

Gus, I am using MDK-ARM 4.20 (I state 4.13 for the build as NETMF has everything set up for that)

My point is the RW Data & ZI Data is too large and as they are variables are they not the same size (pretty much) whether MDK or GCC?
Its the sockets_pal_lwip.lib that takes so much space

I have manged to create a working version by hacking the values in [quote]C:\MicroFrameworkPK_v4_2\DeviceCode\pal\net\Network_defines_lwip.h[/quote]
You use a standard build, like me, so I shouldn’t have to do that.

What I don’t understand is how you are using just lwip_selector.h with the standard PK4_2 and not getting such a large RW Data & ZI Data

Any chance of a map file for your OSHW build? Thanks

We use RVDS not MDK so that may explain why the scatter file is wrong. I think they are deferent files.

You can try to copy scatterfile_tinyclr_rvds.xml to scatterfile_tinyclr_mdk.xml and build again. Remember to clean the existing build first.

OK Mystery solved.
I had assumed that the stock provided scatterfiles for MDK and RVDS would have the same memory scheme, espescially as the compiler is the same, MDK uses RVDS.
Surprisingly, to me anyway, the GHI provided FEZCerbersus scatter files have different memory allocations for MDK and RVDS. Gus any reason why?

The RVDS allocates much more Flash and RAM to TinyCLR. All of the CCM is dedicated to TinyCLR.
So for non Ethernet code, which fits in the MDK memory scheme, you have 128K more space for deployed code and 23K more “Ram” for the deployed solution if you build with the MDK scheme.


			MDK		RVDS	
Firmware Start		0x08010000	0x08010000	
Firmware Size		0x00070000	0x00090000	
			
Deployment Size		   0x80000	   0x60000	
			
Firmware RAM Start	0x10004000	0x10000000	
Firmware RAM size	    0xC000	   0x10000	
Firmware Stack Start	0x10000000	0x2001D000	
Firmware Stack Top	0x10003FF8	0x2001FDF8	
Firmware Stack Size	    0x3FF8	    0x2DF8	
			
			
Deployment Heap Start	0x20000000	0x20000000	
Deployment Heap End	0x2001FDF8	0x20019FF8	
Deployment Heap Size	   0x1FDF8	   0x19FF8	
			
Custom Heap Start	0x2001FE00	0x2001FE00	
Custom Heap End		0x2001FFF8	0x2001FFF8


Worth knowing for the GCC porters out there as maybe the Ethernet version will still fit with FP enabled into the RVDS scheme.

So what did you do ?

Used the MDK map for my Non Ethernet firmware and the RVDS map for the Ethernet version.
I suspect I may just chose the GHI RVDS as default though.