App_sched_queue_full error, using nRF51-BLE-Driver-Win + connectivity_s130.hex

[andlier]

I'm using the pre-compiled nRF51-BLE-Driver-Win driver (v0.5.0) on win7 64b with python2.7 and an nrf51 dev kit dongle running the precompiled 115.2k s130 connectivity firmware.

The python application is really simple, it is just listening for advertising packets from any advertising peripheral. Pretty much exactly like the heart rate collector example, but without the connectivity part. I collect the data in the "on_adv_report" callback, put it in a list and process later.

The problem is that after a while (1 minute to 2 hours, fairly random) the firmware on the dongle hangs with error_code 0x0004 from app_sched_event_put(), which means app-sched-queue is full.

My questions are:

1. Can this happen if I don't process the "on_adv_report" callback on the PC quickly enough? (I'm trying to do it at least within 100ms or so.)

2. Would it help to increase the queue-size, I read that there is a bug in the readme.md file about buffer overflow, is this the same issue?

3. I'm looking for specific length adv-packets, is it possible to filter the packets in the firmware to work around this buffer overflow error?

4. Could be a good idea to detect that the firmware throws an error on the PC-side? Send some error code over uart from the error-handler, would be a nice feature.

-Anders

[Anders Strand]

Hey.

1. Yes, it will help you to process these event as soon as they arrive.
2. As advertisement reports often comes in bursts when you scan, a larger buffer will help you deal with these bursts. However, if the average arrival rate of events is higher than the rate in which you handle them, you will get the same problem only at a later time.
3. Yes, you could customize the firmware running on the nrf device for this purpose. What you do, is to check the length of the advertisement packet before putting the event in the scheduler with app_sched_event_put.
4. I agree, this is a good idea :) Such a feature is unfortunately not planned in the near future from our side.

What method are you using to check what makes the firmware hang on the nrf device?

[andlier]

Thanks for the answers, I'm still debugging here. I was detecting the issue by using the jlink with a breakpoint in the error_handler. It is stuck in while(1) there with no_mem error code and call_stack pointing back to app_sched_put function.

Now I have moved the whole application on to the nordic chip. Used the hrs_central heart rate collector example again, removed all the connection code and just parse advertising packets. Unfortunately this example was without app_scheduler, so I still have some issues with the firmware hanging after a while, I suspect the on_ble_evt callback takes too long to process. I'll look into moving the parsing of adv packets to the main_loop.

Any idea how long the execution time of the callbacks and how frequent they can happen before causing problems?

Any similar examples using the app_scheduler with s130 as central device?

[andlier]

I circumvented the issue I was having by moving the whole application to the firmware on the dongle. Figured out how to use the app_scheduler as well. Thanks for the quick response on my original questions.