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

SAADC callback never called with Softdevice

Hello, I'm having trouble to understand why the saadc buffer is not being filled.

I had already tested this functionality without the softdevice, and everything worked fine but now, with the softdevice,

I found that the "saadc_callback" function is not called at any time. 
I tried to follow some clues after reading several posts here on the blog on this subject, but they did not lead me to a solution.

Tested items:
Modify saadc to continuous mode.
Modify the saadc interrupt priority.


The timer for the PPI ist the TIMER1

Thanks
  • I can not see that you are calling nrf_drv_ppi_channel_enable
    anywhere. Could you confirm for me that this is in fact done?

    I do that in the main function.

    I think I found a solution, I changed the SAADC priority to APP_IRQ_PRIORITY_THREAD in their initialization but I don't know if it's the best (if it will cause problems in the future with the messages sent by ble)

        saadc_config.resolution= NRF_SAADC_RESOLUTION_12BIT;
        saadc_config.oversample= NRF_SAADC_OVERSAMPLE_16X;
        saadc_config.interrupt_priority= APP_IRQ_PRIORITY_THREAD;
    
        //saadc init
        err_code = nrf_drv_saadc_init(&saadc_config, saadc_callback);
        APP_ERROR_CHECK(err_code);

  • f.albu said:
    I do that in the main function.

    Thank you for confirming this.

    f.albu said:
    I think I found a solution, I changed the SAADC priority to APP_IRQ_PRIORITY_THREAD in their initialization but I don't know if it's the best (if it will cause problems in the future with the messages sent by ble)

    I would not think that APP_IRQ_PRIORITY would cause the behavior you describe - SAADC initializing but buffer not getting filled, since you are using PPI.
    What is your SAMPLES_IN_BUFFER set to?

    f.albu said:
    (if it will cause problems in the future with the messages sent by ble)

    No, you can rest assured that this will not cause any problems with the BLE communication. The SoftDevice takes priority over any application-layer task.

    Best regards,
    Karl

  • SAMPLES_IN_BUFFER

    #define SAMPLES_IN_BUFFER         128  

    When I activate the BLE_NUS Log in debug mode, it shows the following message:

    <info> app: Connected to device with Nordic UART Service.
    <debug> nrf_ble_gq: Processing the request queue...

  • Thank you for the update.
    I do not immediately see how changing the priority to APP_IRQ_PRIORITY_THREAD could resolve the issue you described, but I am happy that you have found a solution to your issue.

    Please do not hesitate to open a new ticket if you should encounter any issues or questions in the future!

    Best regards,
    Karl

  • The problem was the allocation of the PPI channels, to solve it I just modified the PPI channels that I used in another part of the program (I had configured the same channel PPI twice for different applications and with this, only the last configuration was valid)

Related