FDS not able to write in SDK 14

[Chris]

Dear all,

I'm struggling writing 32 bytes with FDS in SDK 14.

This is what I do:

Init

(void) fds_register(fds_evt_handler);
fds_init();
while(!is_init) {
    sd_app_evt_wait();
}

Write

fds_record_t        record;
fds_record_desc_t   record_desc = {0};

record.file_id              = FILE_ID;
record.key                  = key;
record.data.p_data        = data;
record.data.length_words      =  (length+3)/ sizeof(uint32_t);
fds_record_write(&record_desc, &record);

I do see that the header is written and on next startup fds_stat returns one more dirty record, but fds_evt_handler is never called with FDS_EVT_WRITE. It is called with FDS_EVT_INIT though, so it seems to basically work. I've read in other posts (mostly concerning older SDKs) that one should check that a soc_evt_handler forwards events to fds_evt_handler, but after

NRF_SDH_SOC_OBSERVER(m_soc_observer, APP_SOC_OBSERVER_PRIO, soc_evt_handler, NULL);

soc_evt_handler is never called.

Any help?

[Anne van Rossum]

I also encountered this. Nice catch.

[Anne van Rossum]

Why is this file actually required? What does it do? In the code I see the following:

* registering for logging
* registering nrf_sdh_soc_evts_poll as a NRF_SDH_STACK_OBSERVER, is this to forward stack events to the SOC observers?
* a section definition, wasn't this already done using the linker actually (this is just my ignorance)?
* in the poll function itself it forwards stuff to the SOC observers and prints the events

Correct?

[Shawn N.]

I am seeing this problem here (needs a dummy init function to function as intended). I am using arm embedded gcc 6-2017-q2 with sdk 15.2.0.

I was linking all the Nordic SDK files into a static library and then using that library in the final linking step with my executable.

When nrf_sdk_soc.c was linked into the static library, it only worked when I added the dummy init to the main.c compilation unit.

When I linked nrf_sdh_soc.c directly against the executable (all other nordic file still in the static library), it worked without using the dummy init hack.

It must be something about visibility of the event handler to the nrf_sdh_soc.c during linking?

[Shawn N.]

I uploaded a hacked up ble_app_beacon (for PCA10040) example here: https://drive.google.com/open?id=1wk3kneAHq2x-fu3SpNUjovHQtUIVGJLo

You can build it with a command similar to:

mkdir build && cd build
cmake -DNRF_SDK=$HOME/devel/nrf5-sdk/15.2.0/ -DCMAKE_TOOLCHAIN_FILE=../NRF52832.cmake ..

In the initial state, it works due to the

nrf_sdk_soc_dont_kill_init();

at line 315 of main.c (you must also add the empty function definition to the nrf_sdh_soc.c file).

If you comment out this line, the example fails. LED4 stops blinking eventually due to a CANCELLED or BLOCKED timeslot and the event handler never runs requesting another.

Leaving that line commented out and commenting out line 171 of CMakeLists.txt and modifying line 173 to read

add_executable(${PROJECT_NAME}.elf ${SRC} ${NRF_SDK}/components/softdevice/common/nrf_sdh_soc.c)

Makes it work again by directly linking against the application

[arthare]

Chris's and Jukka's answer fixed me!  I just want to add my symptoms so this might come up earlier in searches:

• An application run would either never get its FDS_EVT_INIT callback or would get it immediately.
• Each time I started my application, my FDS pages (m_pages in fds.c) would be one state closer to inited.  So I could start->stop->start->stop->start->stop, and eventually they'd hit the `ALREADY_INSTALLED` return in fds_init(), which would get me my `FDS_EVT_INIT` callback and my app would start.
  
  • The fact the pages changed each time I started the app seemed to show that the writes were _happening_, just that some callbacks weren't happening
• Further debugging in `nrf_fstorage_sd.c` (fstorage's softdevice implementation) seemed to show that it never got its `nrf_fstorage_sys_evt_handler` callback, which seemed likely to be needed in order for FDS to eventually get the callback it needed.  Since `nrf_fstorage_sys_evt_handler` is registered with `NRF_SDH_SOC_OBSERVER`, that's what got me on the scent of nrf_sdh_soc, and what led me to this answer.

Fixed for me just by adding nrf_sdh_soc.c to my makefile - I didn't have to add a stub, but I also don't have any optimizations on.  I had missed adding it to my makefile while migrating from SDK 11.0.  Now I'm worried there's other files I've missed...

I'm using Softdevice S332 5.0.0, API 14.2 (17b948a)