8. Memory Report Script

8.1. Introduction

The DA1470x SDK offers a user-friendly way to get an analysis of memory usage of an application. Memory Report is a python script included in the folder utilities\python_scripts\mem_report. It takes as input the application’s linker map file and generates an Excel file containing the memory utilization report of it.

8.2. Running Memory Report Script

The script has been developed using Python 2.7. Besides Python 2.7, XlsxWriter package must be also installed. The procedure to install XlsxWriter in Windows is the following. Run:

> c:\Python27\python.exe –m pip install XlsxWriter

On Linux, the command to run is:

> python pip install XlsxWriter

The command syntax for the Memory Reporter python script is the following:

> python mem_reporter.py [-sub_nb subsection_number] [-hide_empty_sections] <path to map file>

The filename of the output Excel file consists of the directory name containing the map file and the name of the map file (in our case it ends up DA1470x-00-Release_OQSPI_os_app_retarget.xlsx), based on the assumption that map files are inside Eclipse’s build configuration folders. There will be implications if moving the map file elsewhere before running the script.

• subsection_number: parameter allows user to define maximum number of subsections that are reported.

• hide_empty_sections: option removes empty sections from report’s summary.

More details can be found in the readme.rst file contained in the mem_report folder.

8.3. Results Analysis

The Excel file produced by the mem_report script includes various of sheets. The first of them is called “Summary” and it is the summary of memory usage, while the rest are the memory analysis of main software parts of the application. In the “Summary” sheet, there is a matrix. The rows are all the main software blocks of the application (i.e. FreeRTOS, application, sys_man etc.) and the columns are all the memory sections, as they are defined in the linker scripts. For the example of os_app_retarget application, the columns of the sheet are the following:

○ .init_text: Initialization code, exception handling and Vector table ○ .text: non-retention code. Resides in OQSPI flash ○ .copy.table: linker script data, contains all the code and initialized data areas in RAM ○ .zero.table: linker script data, contains all the zero initialized areas in RAM ○ .retention_ram_uninit: uninitialized at startup retained area, used to keep debug info (like reset reason) over system resets, steered by the __RETAINED_UNINIT macro ○ .retention_text: retained RAM code, steered by the __RETAINED_CODE macro ○ RAM_UNUSED_THROUGH_CPU_S: dummy area, used to avoid overlapping of RAMC and RAMS areas ○ .retention_ram_init: initialized retention data, steered by INITIALISED_PRIVILEGED_DATA, __RETAINED_RW and __RETAINED_CONST_INIT macros ○ .non_retention_ram_init: initialized non-retained data ○ .retention_ram_zi: zero initialized retained data steered by PRIVILEGED_DATA and __RETAINED macros ○ .stack_section: application stack space ○ .shared_section_retained_zi: SysCPU/SNC shared zero initialized area, steered by __RETAINED_SHARED macro ○ .ram10_area_for_m33: retained data in RAM10 memory cell, steered by __IN_CMAC_MEM1 macro ○ .ram10_uninit_area_for_m33: uninitialized retained data in RAM10 memory cell, steered by __IN_CMAC_MEM1_UNINIT macro ○ .bss: global and static variables of the SysCPU application

In case RAM9 is used, the next two columns will be included in the matrix:`

○ .ram9_area_for_m33: retained data in RAM9 memory cell, steered by __IN_CMAC_MEM2 macro ○ .ram9_uninit_area_for_m33: uninitialized retained data in RAM9 memory cell, steered by __IN_CMAC_MEM2_UNINIT macro

Finally, the last 2 columns are produced by processing the rest of the columns:

○ Retention Total: the sum of the retained code and data in RAM ○ RAM Total: the sum of all code and data in RAM. This matrix shows how many bytes of each software block are placed in each memory section. In the “Retention Total” column, the sum consists of all the “retention_*” sections plus the stack section. Underneath this table, there are 2 pie charts produced by “Retention Total” and “RAM Total”, and the software blocks of the rows, depicting the memory utilization of each block. In the rest of the sheets, each of the main software block is broken down further into code files. There is again a matrix where the rows are the object files consisting each software block and the columns are again the memory sections. This python script can be used for OQSPI Flash builds only. So, in the following examples, the OQSPI XIP Flash build configuration will be used.

8.4. Example Analysis

In this section, two cases of the previous chapter, Sections 5.2.1 and 5.2.2.2, will be used as examples to analyze further the Excel produced by the mem_reporter script. Starting with the first case (Section 5.2.1), the matrix in the “Summary” sheet is presented in Figure 3.

Figure 3 Memory sections/software blocks matrix of os_app_retarget application

As shown above, the new section, .ram7_init, is added at the end of the sections and contains 4040 bytes, all of them coming from the application software block. Then, in the “application” sheet, the matrix of Figure 4 is created:

Figure 4 Memory sections/project files matrix of the “application” software block of os_app_retarget application

All “new” code and data in RAM7 memory area come from main.c.

In the 3rd case (Section 5.2.2.2), extra shared data have been added in the .snc_shared memory section. So, running the mem_reporter script for the os_snc_retarget application, there is a difference created in memory utilization. First, before the change, the size of the .snc_shared memory section is 132 bytes, as shown in Figure 5.

Figure 5 Memory sections/software blocks matrix of the os_snc_retarget application before adding extra data

After the change, the size has increased to 180 bytes, as shown in Figure 6.

Figure 6 Memory sections/software blocks matrix of the os_snc_retarget application after adding extra data

The area size increase has happened in two software parts, the “application” and the “snc”. Figure 7 and Figure 8 present the “application” sheet before and after adding the extra shared data:

Figure 7 Memory sections/ project files matrix of the “application” part of os_snc_retarget application, before adding extra shared data

Figure 8 Memory sections/ project files matrix of the “application” part of os_snc_retarget application, after adding extra shared dataa

The only difference is the new snc_extra_data structure of 44 bytes size, which is defined in the main.c file and placed in ``.snc_shared memory section. Figure 9 and Figure 10 present the “snc” sheet before and after adding the extra shared data:

Figure 9 Memory sections/project files matrix of the “snc” part of os_snc_retarget application, before adding extra shared data

Figure 10 Memory sections/software parts matrix of the “snc” part of os_snc_retarget application, after adding extra shared data

/* Set application shared space extra data. */
memset(&snc_extra_data, 0, sizeof(app_shared_extra_data_t));
snc_extra_data.size = 10;
snc_set_shared_space_addr(&snc_extra_data,
            SNC_SHARED_SPACE_APP(APP_SHARED_SPACE_EXTRA_DATA));

and the use of the extra shared data:

snc_extra_data.size = 10;
snc_extra_data.buffer[(app_shared_data.buffer[1] - 1) % 10] =
                     app_shared_data.buffer[0] * 1000;