sd_rpc_open hangs for ever if sd_rpc_close was not called

[jpo38]

I'm using Windows driver 0.5.0 with a s130 BLE USB dongle.

If my application calls sd_rpc_open on init and sd_rpc_close before exiting, everything works fine.

Now, if my application crashs, sd_rpc_close is not closed. Then, next session will try to call sd_rpc_open and this will hang forever. Calling sd_rpc_close from the second session before sd_rpc_open does not solve the problem.

The only workaround I found is to unplug and then plug back the dongle.

Could this be fixed in a coming release? Any software workaround?

[Vidar Berg]

Hi, the problem is that the transport layer looses sync with the host when not closed beforehand. The development team is aware of this. A workaround is to reset the device before you start your script. You can make a script to do the reset it via the Segger programmer.

E.g., using nrfjprog:

nrfjprog --reset

Or Jlink commander:

>JLinkExe

>device nrf51

>r //reset and halt

>g // "go" start execution

>q // exit Jlink commander

[jpo38]

I can't run those commands because nrfproj and JLinkExe are not deployed on the machine running my program. But as far as there's a plan to have it fixed, that's fine for me.

[jon]

This doesn't work for me very well. I am calling sd_rpc_close() before my program exits (and getting NRF_SUCCESS return value), but I still can't connect the next time I run my program. The behavior I am seeing is this:

1. First time running program, works fine. Calls nrfjprog --pinreset and beginning and calls sd_rpc_close() at end.
2. Second time, calls nrfjprog --pinreset (also tried nrfjprog --reset), hangs at sd_rpc_open(). Have to manually close program.
3. Third time, runs flawlessly as in step 1.

What is going on?