Hi guys,
we have triggered one interesting state of fds module… This could be somehow connected to https://devzone.nordicsemi.com/f/nordic-q-a/27259/fds-data-corrupted/107629#107629
We are using nrf51822, sdk12.3.0 and softdevice s130 2.0.1… Also we are using only one peripheral link, with one service and one characteristic which we set security mode BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM for read/write permissions.
Most of the time we were able to pair with smart device – but then after some connecting issues fails on pm_init – which cause app_error_check, we fall in never ending reset loop.
It actually fails in fds_init function, where pages_init return NO_SWAP…
After flash readout we noticed that on all three flash pages DEADCODE is written as expected but all three pages are marked as they contains data (0xF11E01FE) – during debugging and normal operation at least one page is always marked as swap (0xF11E01FF)…
Now we are wondering what could trigger that case?
As mentioned above we are using only one peripheral link which is secured – somehow we picked up configuration (app_ram_base.h configuration):
APP_RAM_BASE_CENTRAL_LINKS_0_PERIPH_LINKS_1_SEC_COUNT_0_VS_UUID_COUNT_1_MID_BW 0x20001fe8
After some calculations (difference between configurations with and without sec_count0 and sec_count1 on other configurations) we should add 456 bytes for secure connections, because APP_RAM_BASE_CENTRAL_LINKS_0_PERIPH_LINKS_1_SEC_COUNT_1_VS_UUID_COUNT_1_MID_BW is not in app_ram_base.h
Is it possible that missing those 456 bytes could impact on NO_SWAP issue?
After all we made a workaround and in case that there is no more SWAP pages – we clear those pages manually and after the reset the peer manager initialize as it should…
But we are interested in root cause, to prevent such behavior.
Thank you for info!
Best regards,
Matej