This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Link static library, RAM gets corrupted

Hi, I developed a static library including drivers for spi, twi, gpio, adc and few others. Now when I create application and link my library it works ok as long as I am using functions from library. Now I need to add FreeRTOS support so I added to application makefile dependencies - all freertos files and drv_clock. Now when I try to run the same code as for freertos blinky application It wont blink. When I debugged code I see that static variable *m_clock_cb* from nrf_drv_clock is not filled with '0' . There is some data which causes to fail drv_clock_init and leads to app_fault. I tried and if I create application that instead of my library it includes sources in makefile everything works fine.

I am using GCC and for writing makefiles I reused from SDK makefile for uecc (for library) and one makefile from examples (for applicaiton).

Regards,

Michał

Parents
  • Just thinking out loud:   it could be a name clash.  If both of the libraries (RTOS or your library) defines a function with the same name, then which function is linked depends on the order the libraries are listed in the link command.  In linker terminology, one of the function definitions "resolves" the call to it, which is known as an "undefined symbol" until it is resolved.  If the function that is not linked was doing something important (like initializing m_clock_cb) then there are problems.  I don't think the linker would give you any errors (it would not say "multiple definitions")  I could be wrong, and maybe you already thought of this.  I probbably am wrong, because when you compiled all the files together without libraries, you should get a "multiple definition" error.

    More generally, it would not surprise me if you didn't get much help here.  To get help, you should probably include a small example, which would take a lot of your time to produce.  Anyway, you have found a workaround:  don't use a library.  Few people here will be motivated to to help you with a problem that is about compiling and linking in general, and not specifically about Nordic software.  I sympathize deeply, I use libraries and hate to use huge monolithic projects without libraries.

Reply
  • Just thinking out loud:   it could be a name clash.  If both of the libraries (RTOS or your library) defines a function with the same name, then which function is linked depends on the order the libraries are listed in the link command.  In linker terminology, one of the function definitions "resolves" the call to it, which is known as an "undefined symbol" until it is resolved.  If the function that is not linked was doing something important (like initializing m_clock_cb) then there are problems.  I don't think the linker would give you any errors (it would not say "multiple definitions")  I could be wrong, and maybe you already thought of this.  I probbably am wrong, because when you compiled all the files together without libraries, you should get a "multiple definition" error.

    More generally, it would not surprise me if you didn't get much help here.  To get help, you should probably include a small example, which would take a lot of your time to produce.  Anyway, you have found a workaround:  don't use a library.  Few people here will be motivated to to help you with a problem that is about compiling and linking in general, and not specifically about Nordic software.  I sympathize deeply, I use libraries and hate to use huge monolithic projects without libraries.

Children
Related