• State Not Answered
  • Replies 9 replies
  • Subscribers 25 subscribers
  • Views 238 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288337
Options

How to Create an Instance of RPC (Remote Procedural Call) using the NRF52840

user24036

Hello,

I'm using SDK 17.0.2 with S113, v7.2.0 on the NRF52840. We currently have an instance of CLI running in our executive loop, and it works fine. We'd also like to implement RPC as well for calling functions from a remote processor. 

This is what we have so far:

    // Entering executive loop. Please note, the system WILL NOT EXIT this loop
    // unless a reset occurs.
    for ( ;; )
    {

        if (getRpcActivateFlagStatus())
        {   
            // Then service the RPC bytes!
            rpcServerBytePull(); // Not working
        }
        else
        {
             nrf_cli_process(&m_cli_uart); // Working fine
        }

        idle_state_handle();
             
        // Handle all of the events that were scheduled in the EMQ per
        // iteration of our executive loop. Please note, this is an nRF
        // driver-level API, which dispatches all pushed events to the system
        // EMQ (Event Message Queue).
        app_sched_execute();

    }

Is there a special HW flag in sdk_config.h that needs to be set in order for RPC to operate on UART? My sdk_config.h already enables UART by the way. Also, are there any examples of RPC that I can follow as our SDK does. not come with an RPC example.

  • 0

    Hi,

    As far as I know, we do not have any RPC libraries in nRF5 SDK. Have you added any libraries yourself, or where do you expect this support to come from?

    If you can describe your use-case, requirements and setup in more details, we may be able to provide some suggestions.

    We do have a RPC library in nRF Connect SDK, intended for the nRF5340, but this is not supported in the old nRF5 SDK.

    Best regards,
    Jørgen

  • 0

    I think I see the issue here. Viewing the call stack, my code eventually calls "getchar()", which calls:

    __getChar();

    which calls

    SEGGER_RTT_WaitKey(); // here in lies the problem.

    I'm trying to pull a byte from UART, and not RTT. Is there a way to retarget getChar() to pull a byte from UART? I'm using SES v5.68.

  • 0 in reply to user24036

    There is an implementation for __getChar() in the stdio retarget layer in the SDK (components\libraries\uart\retarget.c):

    #elif defined(__GNUC__) && defined(__SES_ARM)

int __getchar(FILE * p_file)
{
    uint8_t input;
    while (app_uart_get(&input) == NRF_ERROR_NOT_FOUND)
    {
        // No implementation needed.
    }
    return input;
}

    I'm assuming that the call to SEGGER_RTT_WaitKey() that you are seeing is from the SEGGER_RTT_Syscalls_SES.c file:

    /********************************************************************* 
*
*       __getchar()
*
*  Function description
*    Wait for and get a character via RTT.
*/
int __getchar() {
  return SEGGER_RTT_WaitKey();
}

    If you include and enable the UART retarget layer in your sdk_config.h file, the __getChar implementation in SEGGER_RTT_Syscalls_SES.c should be excluded by the "#if !defined(RETARGET_ENABLED) || RETARGET_ENABLED == 0"

    // <q> RETARGET_ENABLED  - retarget - Retargeting stdio functions
 

#ifndef RETARGET_ENABLED
#define RETARGET_ENABLED 1
#endif

    Best regards,
    Jørgen

  • 0

    Retarget in sdk_config.h has been implemented and __getchar() is now compiling. However, I'm seeing this problem when I step through the code:

    https://devzone.nordicsemi.com/f/nordic-q-a/44397/cannot-retarget-getchar-read-getch

    This system simply gets lost and is unresponsive. Is there an inherit SDK bug or bug fix that is suggested? 

  • 0 in reply to user24036

    Can you explain in more detail what you mean by "system simply gets lost and is unresponsive"? You should be able to see where the code is stuck with a debugger. If you can provide a minimal example and instructions to reproduce this behavior, we may be able to help debug it.

    Do you have a softdevice enabled when doing the stepping through code? Stepping with the softdevice enabled will usually cause asserts, as the debugger blocks the softdevice to handle timing-critical interrupts/tasks.

Related
Terms of service