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

No documentation for sd_rpc_* methods

Try as I might all searches for anything related to sd_rpc_* give 'no results'. Admittedly the search engine for the online and offline documentation is poor/difficult to use and I may have not been in the right place at the right time to find it.

However, I am getting a 'Failed to close nRF BLE Driver. Error code: 0x8014' on an sd_rpc_close(adapter) method and I cannot find any information about what that code means or how this method might behave.

I see just this in an h file: NRF_ERROR_SD_RPC_SERIALIZATION_TRANSPORT. But there is no info on what that means and it is not an error listed in the method doc in the h-file.

Parents
  • I assume you are talking about the pc-ble-driver, is that correct?

    If so, that is not typically documented in infocenter, that is correct. 

    If there is a particular sd_rpc_* call you want to know more information about, then I suggest that you right click it in Microsoft Visual Studio and click "Go to Declaration", that should take you to a header file that has a description of that function. 

    In the "normal" SDK, this is typically the same information that you will find on infocenter.nordicsemi.com.

    Regarding your issue to close the adapter, you received 0x8014 = 0x8000 + 0x14. If you look in sd_rpc_types.h, you can see all the error codes starting with 0x8000 (I found this file by checking where NRF_SUCCESS was defined, in nrf_error.h, and right click -> find all references, and saw the line #define NRF_ERROR_SD_RPC_BASE_NUM (NRF_ERROR_BASE_NUM + 0x8000) in sd_rpc_types.h).

    So 0x14 = (dec)20, which refers to the line:
    #define NRF_ERROR_SD_RPC_SERIALIZATION_TRANSPORT (NRF_ERROR_SD_RPC_BASE_NUM + 20)

    I believe this comes from:

    uint32_t SerializationTransport::close()
    {
        std::lock_guard<std::mutex> lck(publicMethodMutex);
    
        if (!isOpen)
        {
            return NRF_ERROR_SD_RPC_SERIALIZATION_TRANSPORT_ALREADY_CLOSED;
        }
    
        isOpen = false;
        eventWaitCondition.notify_all();
    
        if (eventThread.joinable())
        {
            if (std::this_thread::get_id() == eventThread.get_id())
            {
                // log "ser_app_hal_pc_event_handling_stop was called from an event callback, causing
                // the event thread to stop itself. This will cause a resource leak."
                return NRF_ERROR_SD_RPC_SERIALIZATION_TRANSPORT;
            }
    
            eventThread.join();
        }
    
        return nextTransportLayer->close();
    }

    // log "ser_app_hal_pc_event_handling_stop was called from an event callback, causing
    // the event thread to stop itself. This will cause a resource leak."

    So where do you call sd_rpc_close() from?

    PS: I found this in:

    sd_rpc_close() -> return adapterLayer->close(); -> return transport->close();

    Are you calling this from an interrupt created by the transport layer?

    Perhaps you can try to set a flag in this interrupt, and close the rpc from the main contect if this flag is set?

    BR,

    Edvin

Reply
  • I assume you are talking about the pc-ble-driver, is that correct?

    If so, that is not typically documented in infocenter, that is correct. 

    If there is a particular sd_rpc_* call you want to know more information about, then I suggest that you right click it in Microsoft Visual Studio and click "Go to Declaration", that should take you to a header file that has a description of that function. 

    In the "normal" SDK, this is typically the same information that you will find on infocenter.nordicsemi.com.

    Regarding your issue to close the adapter, you received 0x8014 = 0x8000 + 0x14. If you look in sd_rpc_types.h, you can see all the error codes starting with 0x8000 (I found this file by checking where NRF_SUCCESS was defined, in nrf_error.h, and right click -> find all references, and saw the line #define NRF_ERROR_SD_RPC_BASE_NUM (NRF_ERROR_BASE_NUM + 0x8000) in sd_rpc_types.h).

    So 0x14 = (dec)20, which refers to the line:
    #define NRF_ERROR_SD_RPC_SERIALIZATION_TRANSPORT (NRF_ERROR_SD_RPC_BASE_NUM + 20)

    I believe this comes from:

    uint32_t SerializationTransport::close()
    {
        std::lock_guard<std::mutex> lck(publicMethodMutex);
    
        if (!isOpen)
        {
            return NRF_ERROR_SD_RPC_SERIALIZATION_TRANSPORT_ALREADY_CLOSED;
        }
    
        isOpen = false;
        eventWaitCondition.notify_all();
    
        if (eventThread.joinable())
        {
            if (std::this_thread::get_id() == eventThread.get_id())
            {
                // log "ser_app_hal_pc_event_handling_stop was called from an event callback, causing
                // the event thread to stop itself. This will cause a resource leak."
                return NRF_ERROR_SD_RPC_SERIALIZATION_TRANSPORT;
            }
    
            eventThread.join();
        }
    
        return nextTransportLayer->close();
    }

    // log "ser_app_hal_pc_event_handling_stop was called from an event callback, causing
    // the event thread to stop itself. This will cause a resource leak."

    So where do you call sd_rpc_close() from?

    PS: I found this in:

    sd_rpc_close() -> return adapterLayer->close(); -> return transport->close();

    Are you calling this from an interrupt created by the transport layer?

    Perhaps you can try to set a flag in this interrupt, and close the rpc from the main contect if this flag is set?

    BR,

    Edvin

Children
  • That's what I had to do; I looked in the h-files but that documentation is quite limited compared to 'real' documentation which gives an explanation for how to use it and the types of errors one can get, what they mean, and how to fix. All that is missing.

    I was calling the method from the BTLE event callback and it turns out that caused the error. It was just a guess because I did not get an error when calling it in other situations. I put it in a thread and it works. I still do not understand the meaning of the error message.

  • I agree that it isn't a very informative name for this return value. I'll report that to our pc-ble-driver team. And I agree that the documentation for the pc-ble-driver is not really good either, but compared to the "normal" SDK, the softdevice calls are not a closed source binary. It is usually possible to click through the definitions to see what the functions do, and use the declaration of the functions in the header files to see some additional documentation for the behavior of functions.

    Best regards,

    Edvin

  • Okay,  I get the header declarations but I imported a pre-built library. I never succeeded in building from source. First it demanded so many installations of third party software that I did not want to do, so I tried constructing a VS project based upon the source files but could not.

Related