ANCS example fails with error NRF_ERROR_NO_MEM within nrf_sdh.c, SD_EVT_IRQHandler

[Michael M]

I am using parts of the ANCS example code within a product near pre-production.  I am able to reproduce the problem in the ANCS example without modification.  Here are the specifics:

ANCS example fails with error "NRF_ERROR_NO_MEM" within nrf_sdh.c, "SD_EVT_IRQHandler".  The SDK is 15.3.0 and the SoftDevice is s132_nrf52_6.1.1_softdevice.hex.

This is easily reproduced with the following steps:

1) Have an iPhone with 30 or so text message notifications uncleared (text message icon shows red 30 number on icon);

2) Start ANCS;

3) Pair iPhone to Nordic Semiconductor ANCS example;

4) Turn Bluetooth off;

5) Turn Bluetooth on;

Upon reconnection this error will be reproduced.

[AndreasF]

Hi.

What have you defined these as (in main.c)?

Have you tried to increase them?

Best regards,

Andreas

[Michael M]

Hi Andrea. 

I appreciate the quick response.

I am using the example in virgin condition.  As I am testing against a variety of phones and some phones with hundreds or even thousands of existing notifications.  Doubling  the queue size does not solve the problem which is in essence getting more notifications than can be processed until the iPhone stops sending pre-existent type notifications.

The ANCS example is not robust enough as is for real-world phones which might have hundreds of existing notifications.  I was wondering if there are any examples of turning notifications on/off to throttle notification speed such the app_sched_event_put doesn't run into a memory full condition?  Maybe using app_sched_queue_space_get to determine queue is near full and stop notifications?

[AndreasF]

Hi.

Michael M said:

I am using the example in virgin condition.  As I am testing against a variety of phones and some phones with hundreds or even thousands of existing notifications.  Doubling  the queue size does not solve the problem which is in essence getting more notifications than can be processed until the iPhone stops sending pre-existent type notifications.

 

Have you calculated the queue size, do you know that doubling it will be sufficient? In the context of the ANCS example, the picture above shows how the scheduler operates.

The scheduler implements a FIFO queue data structure. The speed of transmission of notifications from your phone to the nRF52 is controlled by the phone, not the nRF52. So when you have thousands of notifications the amount of processor time required by the IRQ that enqueues notifications to the queue, is far greater than the amount of processor time the app_sched_execute() requires to dequeue in main.c. In other words, you pile up faster than you clear the queue. As this example works the only way to not end up with NRF_ERROR_NO_MEM would be to have a large enough queue size, equal to x (the length of the longest notification) * y (number of notifications)

Best regards,

Andreas

[Michael M]

Hi Andrea:

I think you missed my point entirely!

My point was given an unknown amount of pre-existent notifications simply increasing buffer size is not the correct solution so the ANCS example will function correctly with all iPhones it encounters.

Given the above .. can you please respond to .. 

"The ANCS example is not robust enough as is for real-world phones which might have hundreds of existing notifications.  I was wondering if there are any examples of turning notifications on/off to throttle notification speed such the app_sched_event_put doesn't run into a memory full condition?  Maybe using app_sched_queue_space_get to determine queue is near full and stop notifications?"

I look forward to hearing from you.

Best Regards,

Michael

[AndreasF]

Hi Michael.

I understood what you said, and I tried to clarify how the actual FIFI queue data structure operates.

We don't have any other examples out of the box that might work. But you could try to modify the example to not use the scheduler for SoftDevice Events, maybe that will work.

Best regards,

Andreas