This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Start scaning right after starting advertising.

I use sdk 9.0.0, softdevice s130, nrf51422_xxac. In my application I have to both scan and advertise. When I start one of them (scanning or advertising) application starts running properly but when I start them both my application not always starts executing properly (sometimes it looks like processor is executing total mess and I have to restart it, using button, few times till it starts executing properly). In my code I call starting functions consecutively:

err = ble_advertising_start(BLE_ADV_MODE_FAST); 
APP_ERROR_CHECK(err);
err = sd_ble_gap_scan_start(&scan_params); 

The order of calling these 2 functions does not change anything. In ble_gap.h I did not realize any function for checking if softdevice is ready to start next functionality. I lack ideas what is the reason of such behaviour.

  • This should work OK, ofcourse the main factors are the ADV interval and SCAN intervals/Window size. Can you give more details about these settings. if the interval is slow then these two events will compete less with each other for RADIO and CPU resources.

  • /**< Determines scan interval in units of 0.625 millisecond. */                  
    #define SCAN_INTERVAL 0x00A0    /** < 0.1 s */  
    
                                     
    /**< Determines scan window in units of 0.625 millisecond. */                    
    #define SCAN_WINDOW 0x0050      /** < 0.05 s */                                  
                                                                                 
    static ble_gap_adv_params_t bc_adv_params;                                       
                                                                                     
    static const ble_gap_scan_params_t scan_params = { 0,// Active scanning not set  
                                                     0,// Selective scanning not set. 
                                                    NULL, // White-list not set.     
                                     (uint16_t)SCAN_INTERVAL, // Scan interval.       
                                    (uint16_t)SCAN_WINDOW,   // Scan window.         
                             0 /* Never stop scanning unless explicitly asked to */};
    
    #define APP_ADV_FAST_INTERVAL            0x0028 // 25 ms                         
    #define APP_ADV_SLOW_INTERVAL            0x0C80 // 2 sec                         
    #define APP_ADV_FAST_TIMEOUT             0 // sec                                
    #define APP_ADV_SLOW_TIMEOUT             0 
    

    I use fast advertising. Sorry Aryan I have not answered in comment but it was easier and more clear.

  • This should have worked fine, I would like to know the what errors you get. Is it possible that the problem is somewhere else? because if there is a problem with this, it should not have worked sometimes. Try to debug and tell us little more clearly what you mean by "sometimes it looks like processor is executing total mess and I have to restart it"

  • Sorry for responding so late. Ok, here is what happens. In my application I use app_uart_fifo.c and I sniff my UART communication that's how I know something is wrong. When application starts correctly I sent just one sentence but sometimes when it gets into that buggy style nordic sends the same sentence but then it sends whole RAM content and gets into Hard Fault. Debugging is rather impossible when softdevice is working and the problems does not appear when I just start one of scanning or advertising. When I stop program in buggy execution Program Counter is in Soft Device or app_uart_fifo.c or some scheduler functions and that's why I still consider it as bug in my code. So far I have added watchdog so that my application restarts when it enters buggy path.

  • you said that the uart sends the whole ram when buggy, I would very much like to know the source of this problem. Please update this thread when you find out. If you need more help, posting some code snippets will speed up our analysis.

Related