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

Issue with nrf_sdh_enable_request() after adding DEBUG_NRF to project configuration

Hi

I've been working on a project over the past few months, and per a new requirement I was asked to add a debug configuration, as thus far I have worked with only a release configuration

I have a few asserts in code that I wanted to check, so alongside DEBUG I've also added DEBUG_NRF to my project, and this causes an issue where my project stops working by reaching the error while loop inside app_error_save_and_stop()

following the code in debug mode, I found what appears to be the function call that causes the error

while initializing the BLE module, I call ble_stack_init() which begins by calling nrf_sdh_enable_request()

at the end of this function is the following call: sdh_state_observer_notify(NRF_SDH_EVT_STATE_ENABLED);

for some reason I can't explain, it seems that the third iteration inside the loop fails when calling handler(evt, p_observer->p_context) inside this function, but only in this case

and as sdh_state_observer_notify() is called 3 times within nrf_sdh_enable_request() and there previous two seem to work correctly, I really have no idea what could cause this issue

The project works fine without DEBUG_NRF, it is a FreeRTOS project based on the ble_app_hrs_freertos example, though it has changed significantly

Please let me know what further information I can provide that might help determine the source of the problem, and I'll provide it as soon as I can

Thanks

Aviv

Parents
  • for some reason I can't explain, it seems that the third iteration inside the loop fails when calling handler(evt, p_observer->p_context) inside this function, but only in this case

     The handler has to be some function that is registered previously using NRF_SDH_STATE_OBSERVER. If you step into the handler function then you should get the proper context of which callback function caused the error in the third loop.

Reply
  • for some reason I can't explain, it seems that the third iteration inside the loop fails when calling handler(evt, p_observer->p_context) inside this function, but only in this case

     The handler has to be some function that is registered previously using NRF_SDH_STATE_OBSERVER. If you step into the handler function then you should get the proper context of which callback function caused the error in the third loop.

Children
  • thanks for the answer Susheel

    however, I think this problem has nothing to do with anything related to your code

    I am working on the project with a team, and one of them has decided to touch the project file and create a unified solution to hold the several project files (in SES)

    this commit caused this issue somehow

    so I think it is safe to say that I need to discuss this change with the rest of the team, and find what exactly happened that could cause this issue. so I don't think there is any reason to involve you any further, it is clearly a bug in our project locally

    please consider the issue resolved from your end

    if I do determine the cause of the issue, I'll do my best to post it here, to prevent others from making the same mistake

  • Thank you very much, Aviv, for being very honest and letting me know what you think the root cause could be. 

    I will still keep this thread open and I would request you to come back to this thread once you find out the cause just to make this thread and my curiosity end :)

  • I believe I found the real problem and managed to solve it, but it is quite bizzare

    In this project I have a specific mode that is built around the USB CDC CLI module

    This mode is enabled if a USB cable is detected at the start of the project, through a GPIO pin in our PCB

    However, because it is comfortable to test all flows with USB connected (as that is also a way to provide power to the PCB), we've added a define that allows us to disable the USB check and the related mode

    for some reason, in debug mode, if the USB CDC driver and USB CLI module weren't initialized, I would get the error I described. I am not sure why this is the case, but I managed to solve it by initializing both regardless, and if I do not intend to use these modules I just uninitialize them

    could this be because the USB CDC is based on the app_usbd module, and for some reason if it is enabled in sdk_config.h it is required to be initialized in debug mode?

    I would love to hear any possible explanations for this, as I have none myself

  • Aviv Okon said:
    could this be because the USB CDC is based on the app_usbd module, and for some reason if it is enabled in sdk_config.h it is required to be initialized in debug mode?

     It very seems to be the case. Enabling it in sdk_config.h might make the driver think that this module is in use and possibly initialized few basic states of the driver even though the application hasn't explicitly initialized it. This smells like bug, but it seems like you have a workaround for this. Thanks for letting us know. 

Related