I'm using an app_timer callback to run some potentially lengthy (could occasionally be up to 100ms or so) code every second. At the end of the callback, I call app_timer_set to restart the timer. I'm having a very intermittent issue in my application: after anywhere from several hours to several days the watchdog reset fires. I'm in the process of trying to catch the reset on the debugger to see what I can learn, but in the meanwhile I was wondering:
1) Is running that code in the callback advisable, or should I move it elsewhere (e.g. just increment a counter in the callback and process the code in the main loop after the BLE scheduler)?
2) Pertinent to #1: what context does the app timer callback run in? Is it called from an interrupt, or by the scheduler? Ditto for the callbacks defined in user_callback_config.h.
3) Is there a more preferred way to regularly execute application code?
If it helps, here's some other details on the application: I'm running the part as a central (I started from the DSPS code), and I've got it sniffing for advertisements, buffering up data from them, then sending it to a modem via UART at 9600 baud (which is where the delay could come in). Everything but the advertising data collection is occurring in the app timer callback.
Thanks!
Hi mark.bloechl,
1. Since your application can run for 100ms moving the code in the main loopin the app_asynch_trmwould be advisable.
2.The callback of the timer is called from the scheduler.
3. Since your code runs for 100 ms a good idea would be to break your code if possible in smaller execution chunks,的问题让朗的CPU占用g in one place is that the scheduler wont schedule any incoming messages so you might lose events. An idea would be to run the code through the main loop in the app_asynch_trm or app_on_ble_powered and return KEEP_POWERED or GOTO_SLEEP in order to re run the scheduler and small portions of the application or go to sleep.
Thanks MT_dialog