This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CHECK_RAM_START_ADDR always use sec count = 0 ?

Why does the macro CHECK_RAM_START_ADDR only check for C_LINK_CNT and P_LINK_CNT and not the SEC_COUNT? It is always set to 0 in the macro.

I have increased the central_sec_count to 2 and have 1 peripheral and 3 central links so I guess i should use: APP_RAM_BASE_CENTRAL_LINKS_3_PERIPH_LINKS_1_SEC_COUNT_2_MID_BW to verify the RAM settings?

The reason I have increased the central_sec_count is because I have had trouble with pm_conn_secure returning NRF_ERROR_NO_MEM occasionally, most likely when 2 peripherals connect to it at "almost the same time". Is it correct that increasing the central_sec_count will reduce the chance of sd_ble_gap_authenticate returning NRF_ERROR_NO_MEM?

I'm using SDK11 and S132.

Best regards Erik

  • Hi,

    The macro should have taken a third parameter to successfully expand into the last part of the macro _SEC_COUNT_x_MID_BW, instead of just defaulting to _SEC_COUNT_0_MID_BW. In SDK 12 the macro is empty, and the macro will be removed in an upcoming release. See here for more information about this.

    When sd_ble_gap_authenticate() returns NRF_ERROR_NO_MEM it means that there isn't enough SMP instances to handle the security operation, so the correct fix to this is to increase the central_sec_count.

Related