BLE_CLI generates a "SOFTDEVICE INVALID MEMORY ACCESS." error

[mectronicsinc]

Hi all.

For debugging my app (SD s132, V5.0, SDK 14.2), I'm using the NRF_BLE_CLI (I use Nordic the example with an external PCA10040, the Python script and PuTTY).

Unfortunately, randomly, I got an NRF_FAULT_ID_APP_MEMACC, that mean wich a "SOFTDEVICE: INVALID MEMORY ACCESS" error has been raised.

Observating the Stack pointer, ia == R12 = 0x00031389  (note that the call stack is empty...), I found that the responsible is the function "cli_ble_uart_read", used when a new command is received

Here the address of the function cli_ble_uart_read:

As you can see in the pictures, the MWU->PERREGION register are all 0, apparently, there are not a SD violation:

Here the CPU registers:

Please, can anyone help me?? I'm going crazy!

Thanks a lot!

[Vidar Berg]

Hi,

When you get the NRF_FAULT_ID_APP_MEMACC, can you check the value of the info variable passed app_error_fault_handler()? Also, if any of the MWU->EVENTS_* register is set.

Thanks,

Vidar

[mectronicsinc]

Hello Vidar, thanks for you reply. 

In order:

• info is always 0;
• no one MWU->EVENTS_* register is set

Any idea?

Many thanks,

Francesco

[Vidar Berg]

Hi Francesco,

It doesn't make sense to me that there are no MWU events when you get the NRF_FAULT_ID_APP_MEMACC assert. Have you tried the same with a newer SDK version, 15.3.0 for instance? That said, we have a bug in the Softdevice that may wrongfully trigger this assert if critical regions are being used. Please try the following workaround to see if it makes any difference: "replace __NRF_NVIC_SD_IRQS_1 with the following in nrf_nvic.h , and recompile the user application:

#define __NRF_NVIC_SD_IRQS_1 ((uint32_t)(1U << (MWU_IRQn - 32)))

[m.reynal]

Hi Vidar,

I had NRF_FAULT_ID_APP_MEMACC and use the solution with __NRF_NVIC_SD_IRQS_1  (I found this solution in the documentation, as you suggested here) and it seems ok

But I'm wondering if there any drawbacks with this workaround?

Because I downloaded the last SDK with the last SD, and we still need to apply this workaround... Why do we still have to do it? It could be already done in the last version... unless there is drawbacks with this workaround?

thanks

Moana

[Vidar Berg]

Hi Moana,

Glad you found the solution  This is also documented as a "known issue" in the Softdevice release notes where the same workaround is proposed. There is no obvious drawback with this as far as I can tell. We will hopefully be able to address this in a future release.

Best regards,

Vidar