compiler ERROR UART code

[PIRHeisenberg]

Hi, i have been working on initializing the UART periferial based on the UART example in the SDK5. I got following error.

1> error: unplaced section: .log_dynamic_data_balloc_log_mempool [nrf_log_frontend.o], size=4, align=2
1> error: unplaced section: .log_const_data_app [nrf_log_frontend.o], size=8, align=4
1> error: unplaced section: .nrf_balloc [nrf_log_frontend.o], size=28, align=4
1> error: unplaced section: .log_dynamic_data_app [nrf_log_frontend.o], size=4, align=2
1> error: undefined symbol: __start_log_const_data
1> error: undefined symbol: __start_log_filter_data

I know that i probably missed a header file or something simular but i was not able to find out which.

Please help

[Einar Thorsrud]

Hi,

It looks like you are missing definitions for some sections used by the logger library in the linker configuration. If you are using SES(?) you can refer to flash_placement.xml of one of the examples that use logging. There you will see for instance this line:

    <ProgramSection alignment="4" keep="Yes" load="Yes" name=".nrf_balloc" inputsections="*(.nrf_balloc*)" address_symbol="__start_nrf_balloc" end_symbol="__stop_nrf_balloc" />

And similar for log_const_data etc. You need to add these configurations to your project.

[PIRHeisenberg]

<ProgramSection alignment="4" keep="Yes" load="Yes" name=".log_const_data" inputsections="*(SORT(.log_const_data*))" address_symbol="__start_log_const_data" end_symbol="__stop_log_const_data" />
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".nrf_balloc" inputsections="*(.nrf_balloc*)" address_symbol="__start_nrf_balloc" end_symbol="__stop_nrf_balloc" />
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".log_dynamic_data" inputsections="*(SORT(.log_dynamic_data*))" runin=".log_dynamic_data_run"/>
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".log_const_data" inputsections="*(SORT(.log_const_data*))" address_symbol="__start_log_const_data" end_symbol="__stop_log_const_data" />
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".log_dynamic_data" inputsections="*(SORT(.log_dynamic_data*))" runin=".log_dynamic_data_run"/>
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".log_filter_data" inputsections="*(SORT(.log_filter_data*))" runin=".log_filter_data_run"/>
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".nrf_balloc" inputsections="*(.nrf_balloc*)" address_symbol="__start_nrf_balloc" end_symbol="__stop_nrf_balloc" />

I added the following lines to the flash_placement folder but the error Messages are the same

[Einar Thorsrud]

Can you upload your project here so I can look at it and perhaps try to build it?

[PIRHeisenberg]

GPIOTestproject.zip

[PIRHeisenberg]

Here

[Einar Thorsrud]

Hi,

I see you are using the Segger linker, so then this would be different. I do not have any experience with that unfortunately, and it is not used in the SDK example projects (which use the GNU linker). Is there a particular reason you use the SES linker, and organize your project differently than how it is done  in the SDK? In most cases doing it the same way as in the SDK examples make sense as that will save you time, and perhaps more importantly, that is how we test the SDK.

[PIRHeisenberg]

No there is no particular reason, I've just started working with the NRF chips and i am a little confused with the workflow. I can change the linker to GNU if it helps. The reason my project is organized this way is because i included the missing header and C files according to the compiler errors,

[Einar Thorsrud]

I see. Then I suggest you start of with an SDK example project and adapt that, instead of building the project yourself. Also, starting with a project that use much of the libraries you need will save you the time needed to add all dependencies, configuration macros etc.

[PIRHeisenberg]

At some point i will have to add functions from diffrent examples, and i am going to have the same issue. On the long run its going to give problems. All across the devZone you tell people to use the examples but this doesn't seems to be a sustainable workflow, if your developing something new out of the box. Wouldn't it be a goed idea to give a list of header Files in the SDK which are nessesary to use the given SDK function? Nevertheless thanks for the support.

[Einar Thorsrud]

I see your point. To be honest the problem is that the way the nRF5 SDK is organized there is a lot of dependencies between modules, with a significant number of files and configuration macros etc, making it tedious to add everything ourselves. That is one of the reasons we recommend starting with an example that is close to what you need - to save time. You will probably have to add more yourself, and remove something, but doing it this way saves time and trouble. (To be more specific, we generate the projects automatically using an internal tool, saving us that work. But this tool is not available to customers.)

But even if you start off with a minimal example project, I still recommend you follow the same approach as in the SDK examples when adding new libraries/drivers etc, as that way you can copy-past or compare with the configuration of existing examples. Again, this will probably save you time and trouble.

[PIRHeisenberg]

Hey, a short update to the Project. I set up a new clean C Project according to the UART example in the SDK. It now seems to work. I just added all the C directory files to my project and added the headers in the preprocessor directory.