WARP Project Forums - Wireless Open-Access Research Platform

vick wrote:

I've been testing the 802.11 reference design (1.7.5) and running wlan_mac_high_ibss over wlan_mac_low_nomac successfully.

I'm now making changes to wlan_mac_high_ibss and adding new code/functionality, but have now hit a point where SDK complains about the size of my new larger code:

:::
c:/xilinx/14.4/ise_ds/edk/gnu/microblaze/nt64/bin/../lib/gcc/microblaze-xilinx-elf/4.6.2/../../../../microblaze-xilinx-elf/bin/ld.exe: wlan_mac_high_ibss.elf section `.data' will not fit in region `mb_high_ilmb'
c:/xilinx/14.4/ise_ds/edk/gnu/microblaze/nt64/bin/../lib/gcc/microblaze-xilinx-elf/4.6.2/../../../../microblaze-xilinx-elf/bin/ld.exe: region `mb_high_ilmb' overflowed by 19080 bytes

The linker script in use is the one in the release, i.e., ".../wlan_w3_high/lscript.ld", and the code is being compiled with size-optimization as recommended (i.e., -03 flag).

Is there a simple way to allocate more space for my expanding code?

Some low hanging fruit is the size of the heap. It's currently 8kB of space set aside. You could safely cut this to 4kB or 2kB. It might even be safe to lower it further, but keep an eye on any errors that might print to UART if malloc fails. The amount of heap needed is a bit of a soft requirement -- it depends on how much activity your node sees around it. In a busy environment with lots of other WiFi traffic it will need more.

vick wrote:

Alternatively, is there an easy way to remove unused functionality from wlan_mac_high_ibss? I've tried removing the experimental framework files, i.e., wlan_exp_* files, but wlan_exp seems to be quite entrenched in the code and this resulted in lots of errors from calls in other (non wlan_exp_*) files.

We've made this easy for exactly this reason. wlan_mac_high_sw_config.h lets you select which parts of the code are compiled in. Turning some of those off will free up a decent amount of space.

A final thing you can do is change the optimization in the compiler option to "-Os". This will optimize for size rather than speed.

Last edited by chunter (2018-May-23 09:32:17)

Another useful tool when optimizing code size is the map file written by the linker. The 802.11 projects write this to <proj>/Debug/executable.map in the SDK workspace. The map file lists every linked object with its offset in the .elf and, more usefully, its size. The software projects are configured to generate separate objects per-function (-ffunction-sections) and per-global (-fdata-sections), so the map file will have an entry for every function/global in the .elf. This is a great way to find unexpectedly-large functions or variables. We've used this to track down forgotten debug variables (things like "u8 tmp_array[1024]") wasting code space.

Be sure to copy the "--gc-sections" linker option too. That instructs the linker to omit (gc = garbage collect) unused code/data sections.