How to reduce the size of an executable file?

[msu7xi]

Hello,

I have modified the central_uart example to make the nRF52832 communicate with an ESP32 in MessagePack. After having disabled the logger configuration in the proj.conf file the size of the *.bin file is 225.8 kB which is too large for an nRF52805 (flash of 192 kB). Is there any way to reduce the bin file size?

Below the proj.conf file:

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# Enable the UART driver
CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_UARTE0=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

# Enable the BLE stack with GATT Client configuration
CONFIG_BT=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_SMP=y
CONFIG_BT_GATT_CLIENT=y

# Enable the BLE modules from NCS
CONFIG_BT_NUS_CLIENT=y
CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_FILTER_ENABLE=y
CONFIG_BT_SCAN_UUID_CNT=1
CONFIG_BT_SCAN_ADDRESS_CNT=1
CONFIG_BT_GATT_DM=y
CONFIG_HEAP_MEM_POOL_SIZE=2048
CONFIG_BT_MAX_PAIRED=1
CONFIG_BT_MAX_CONN=1

# This example requires more workqueue stack
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Enable bonding
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

# Enable use of the non-minimal C functionality (stdio.h).
CONFIG_NEWLIB_LIBC=y

# Config logger
CONFIG_LOG=n
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=n
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=n
CONFIG_BT_DEBUG_LOG=n
CONFIG_BT_GATT_DM_DATA_PRINT=n

CONFIG_ASSERT=y

# Config I2C
CONFIG_GPIO=y
CONFIG_I2C=y
CONFIG_I2C_NRFX=y

CONFIG_SHELL=y
CONFIG_I2C_SHELL=y

Regards,

Marco

[JamesDougherty]

Hey Marco,

Just curious, have you tried using CONFIG_SIZE_OPTIMIZATIONS=y so GCC optimizes for size? That may work. Also, have you tried using the minimal C library (CONFIG_MINIMAL_LIBC=y) instead of Newlib (CONFIG_NEWLIB_LIBC=y)?

[msu7xi]

Hello James,

Yes, I'm using CONFIG_SIZE_OPTIMIZATIONS=y but I have not tried CONFIG_MINIMAL_LIBC=y yet. Should this be configured in the prj.conf file?

[JamesDougherty]

Hey Mohamed,

Hope your morning is going well. I would start by getting rid of the compiler warnings. You can remove CONFIG_NEWLIB_LIBC_FLOAT_PRINTF since you're using the minimal library now. UART_CONSOLE requires that CONFIG_SERIAL is enabled, do you have that enabled? I'm not sure about the I2C one. Those won't resolve your issues, but it's always good to have a clean compile. 

Another idea is to try and use Ozone. When you run your code from Ozone it will give you a stack trace when it crashes. This may point to where to core issue lies. You can also set a breakpoint on the address where it's faulting, you can look at the disassembly where that address is to pinpoint where it's crashing, etc. Ozone has helped me figure a lot of obscure bugs out. You should also be able to step through your code, which is always helpful. It's very simple to setup in VS Code, but I'm not sure about SES since I don't use it. Also, it should give you a free license since you're using Nordic.

As mentioned, I unfortunately do not use SES (I use VS Code). I would try the above and see what happens. If that doesn't work I would open a new ticket and then hopefully a Nordic engineer can jump on and give some ideas too. A lot of people may not be seeing this since the original question was answered and we're buried in the depths of comment land.

[Learner]

Thank you James for the valuable pointers.

JamesDougherty said:

UART_CONSOLE requires that CONFIG_SERIAL is enabled, do you have that enabled?

No, it is not. This is because of a hardware constraint I think.

#CONFIG_UART_CONSOLE=n

CONFIG_SERIAL=n

Notice, UART_CONSOLE is commented out in my prj.conf. Does it default to 'y' or 'n'?

JamesDougherty said:

Another idea is to try and use Ozone.

Ozone was going to be my next move because SES does not support data breakpoints.

I Will keep you posted.

Kind regards

Mohamed

[JamesDougherty]

Here is the definition for it:

config UART_CONSOLE
	bool "Use UART for console"
	depends on SERIAL && SERIAL_HAS_DRIVER
	select CONSOLE_HAS_DRIVER
	help
	  Enable this option to use one UART for console.

So it's possible that the console isn't defined. I would check the dts file and see if it's defined there. Here is a snippit of what I use. We use a custom board that's based on the nRF52840 SoC, but it should be the same for yours as well. I'm not 100% sure if this is the issue, but I would try this:

/ {
    chosen {
        zephyr,console = &uart0;
    };
};

If you're using the DK and it's not defined, then you can always add it to your overlay file (or create an overlay file).

[Learner]

Yes, I have the same definition in my zephyr.dts file. 

[Learner]

Hi James,

Ozone is pointing to this static buffer @ address 0x2000440C

#define CONSOLEDRV_INPUT_BUFFER_SIZE ((uint8_t)100) /**< The maximum number of bytes that can be read */

static char inputBuffer[CONSOLEDRV_INPUT_BUFFER_SIZE]; /**< The console input buffer */

This buffer is used in the implementation of a BLE console.

Level, Function,Stack Frame,Source,PC,Return Address,Stack Used
0,"<MemManage Exception>","32 @ 0x2000CA60","fault_s.S:80",0x00017330,"[0x2000CA78]: 0x20004410",32
0,"@ 2000?440C"," 0 @ 0x2000CA80",,0x2000440C,"<no symbols>"," 0"
0,"Top of stack - no unwinding symbols at 0x2000440C",,,,,

I am not sure what the two lines in red above are telling me. Am I running out of stack space?

See attached screen capture showing the call stack.

Kind regards

Mohamed

[JamesDougherty]

MemManage Exception. I have a hunch that something is definitely getting called outside of memory bounds. Do you have any callbacks? If so, is there a null one somewhere? It's so hard to tell from the screenshot what that could be though. Are you able to share the source code to this or source code that can reproduce it?

[Learner]

JamesDougherty said:

something is definitely getting called outside of memory bounds.

Not sure what you mean.

JamesDougherty said:

Do you have any callbacks?

Yes, mainly BLE 

JamesDougherty said:

If so, is there a null one somewhere?

What do you mean?

But the last known code address in the call stack prior to the crash is 0x2000440c which corresponds to the address of the inpuBuffer[] I mentioned earlier. You don't think this anything to do with accessing this buffer.

[JamesDougherty]

Read a similar situation here: https://stackoverflow.com/questions/52234155/what-can-cause-an-arm-memmanage-exception-with-all-bits-in-the-mmsfr-register-ze

I'm heading out for the day, best of luck on your hunt.

[Learner]

Have a great day! 

[Learner]

Good Morning James,

I thought I ought to let you know how it all unfolded ...

It was a silly mistake from my part when I switched from using sscanf() to strtol().  I was calling strtol() with the wrong number of parameters and I was ignoring the compiler warning "Implicit definition of function...". Once I fixed this the problem disappeared.

long strtol(const char *nptr)

instead of 

long strtol(const char *nptr, char **endptr, register int base)

In fact, I am now using atoi() because it is more appropriate in my case.

Morale: Get rid of all warnings first!

Thank you for your help. Have a great day!

Kind regards

Mohamed