Putting Archive file (.a) in RTC

[jjones7432]

We want to place a 3rd party archive (.a) in RTC memory to preserve the state of the library during deep sleep.
There are no state change issues in normal running or light sleep.

Our CMakeList.txt contains:
***

Code: Select all

idf_component_register(SRCS "app_main.c" 
							"...other source files...c"
                       
                    INCLUDE_DIRS "."
                    EMBED_TXTFILES server_root_cert.pem 
                    	esp_logo.png
                    	howsmyssl_com_root_cert.pem 
                    	aol_root_cert.pem
                   	 postman_root_cert.pem
                    LDFRAGMENTS "linker_fragment_file.lf"
                    
                    )
                    

add_library(lib_iaq_2nd_gen_ulp STATIC IMPORTED GLOBAL)
set_property(TARGET lib_iaq_2nd_gen_ulp PROPERTY IMPORTED_LOCATION "${COMPONENT_DIR}/lib_iaq_2nd_gen_ulp.a")
target_link_libraries(${COMPONENT_TARGET} PUBLIC lib_iaq_2nd_gen_ulp)

***
Our linker fragment file linker_fragment_file.lf contains:
*****

Code: Select all

[mapping:main]
archive: lib_iaq_2nd_gen_ulp.a
entries:
	* (rtc)

*****
The project will link as configured above and, as expected, there are references to the archive (lib_iaq_2nd_gen_ulp.a) in the RTC sections and other sections of the linker map output file (.map). The application executes but after wake up from deep sleep the library state is still lost.

However, we have not been able to link without the add_library(), set_property() and target_link_libraries() entries.

Therefore, we are concerned that the linker may not be resolving references using the archive loaded into the RTC, that there may be one unused version of the archive in RTC memory and a second version loaded and actually used by the linker to resolve references.

Please advise how to link with just the LDFRAGMENTS entry so that we are sure that the linker loads the archive into RTC memory and uses that RTC memory loaded archive to link and resolve references as appropriate.

Thanks.

[MicroController]

Have you tried reserving ULP memory via menuconfig already?

[jjones7432]

***Update****
For completeness, below is the message when the add_library(), set_property(), and target_link_library() entries are removed from CMakeLists.txt, reporting undefined references which are defined in the lib_iaq_2nd_gen_ulp.a:
*****
FAILED: wifi_prov_mgr3.elf
...
c:/espressif/tools/xtensa-esp32s3-elf/esp-12.2.0_20230208/xtensa-esp32s3-elf/bin/../lib/gcc/xtensa-esp32s3-elf/12.2.0/../../../../xtensa-esp32s3-elf/bin/ld.exe: esp-idf/main/libmain.a(ulp_main.c.obj):(.rtc.data.9.literal+0xcc): undefined reference to `init_iaq_2nd_gen_ulp'
c:/espressif/tools/xtensa-esp32s3-elf/esp-12.2.0_20230208/xtensa-esp32s3-elf/bin/../lib/gcc/xtensa-esp32s3-elf/12.2.0/../../../../xtensa-esp32s3-elf/bin/ld.exe: esp-idf/main/libmain.a(ulp_main.c.obj):(.rtc.data.9.literal+0xe4): undefined reference to `calc_iaq_2nd_gen_ulp'
c:/espressif/tools/xtensa-esp32s3-elf/esp-12.2.0_20230208/xtensa-esp32s3-elf/bin/../lib/gcc/xtensa-esp32s3-elf/12.2.0/../../../../xtensa-esp32s3-elf/bin/ld.exe: esp-idf/main/libmain.a(ulp_main.c.obj): in function `ulp_main':
C:/Users/jjone/workspace/wifi_prov_mgr3/main/ulp_main.c:126: undefined reference to `init_iaq_2nd_gen_ulp'
c:/espressif/tools/xtensa-esp32s3-elf/esp-12.2.0_20230208/xtensa-esp32s3-elf/bin/../lib/gcc/xtensa-esp32s3-elf/12.2.0/../../../../xtensa-esp32s3-elf/bin/ld.exe: C:/Users/jjone/workspace/wifi_prov_mgr3/main/ulp_main.c:224: undefined reference to `calc_iaq_2nd_gen_ulp'
collect2.exe: error: ld returned 1 exit status
****
So in this case, there are references to lib_iaq_2nd_gen_ulp.a in various RTC memory sections in the linker map file but the functions in the archive were not resolved. It appears the linker placed the archive in RTC memory but did not use the archive to resolve references to functions in the archive.

[jjones7432]

Have you tried reserving ULP memory via menuconfig already?

Hi. Thanks for replying.
We don't have a requirement to run code while in deep sleep, so I need more detail about your suggestion.

Also, the "ulp" in the 3rd party archive is misleading and is not associated with the ESP32S3 power modes and operations.