• State Verified Answer
  • Replies 7 replies
  • Subscribers 63 subscribers
  • Views 4457 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 108455
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Resetting device via python bindings

Jim Dattolo

I am developing a tool that will be using the existing NRF51 dongle to run the S130 SD and it is being written in Python. There is no way to change any of these parameters since dev has been going for years on the tool chain via a different chip supplier for BLE. Even if I close the device I cannot reconnect to it since it's already running in a state that I cannot guess since I have multiple tools. If I just power through things I run afoul of already registered base UUIDs and other things that take resources.

Is there any way from python to clear out the state of the SD back to the one from a fresh boot. I saw a thread there a SD call can be made to reset the entire device (which would be fine with me) however in 0.5.0 python swig bindings I do not see it in there. Unless there is some way to get the JLINK serial number from the python bindings I cannot simply call the nrfjprog --reset command since I have multiple jlink pods/dongles on the system and I need to target the one that I have currently selected (which is done via the COMX port number)

-Jim

Parents
  • 0

    Hi Jim,

    Thanks for the clarification. Sorry that I wasn't sure you were using the BLE driver or the Master Emulator. But you were right, you mentioned v0.5.0 and python.

    On the BLE connectivity set-up we use an extra GPIO pin to do physical pin reset on the connectivity chip. We are actually working to implement the sd_nvic_SystemReset() in the future release of the serialization firmware.

    What you can do for now if you don't plan to wait for the release that has the soft reset API provided is either:

    • Implement your own soft reset API on both the connectivity firmware on the nRF51 and the python bindings.

    • Use nrfjprog --reset with the Jlink serial number match with the COM port that you are connected to. You can find the corresponding Jlink serial number for the COM port using Windows Registry. The solution is described here. The registry section you should look into is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB. You would need to use the ParentIdPrefix to match them.

  • 0 in reply to Hung Bui

    From the nRF51 point of view, what happens on the other side, the COM port on Windows should be out of sight.

    What the nRF51 can probably see is that the UART peer (the Segger chip) stop responding or HWFC line stopping it from transmit more data. The stack will keep normal operation, and time out may occurs as I mentioned above.

    However potential issue could be some events go missing, if the HWFC is not controlled properly. So the nRF51 keeps transmitting on the UART line when there is no control over it.

    I think it's better to have a fresh start for the S130. That's safer.

Reply
  • 0 in reply to Hung Bui

    From the nRF51 point of view, what happens on the other side, the COM port on Windows should be out of sight.

    What the nRF51 can probably see is that the UART peer (the Segger chip) stop responding or HWFC line stopping it from transmit more data. The stack will keep normal operation, and time out may occurs as I mentioned above.

    However potential issue could be some events go missing, if the HWFC is not controlled properly. So the nRF51 keeps transmitting on the UART line when there is no control over it.

    I think it's better to have a fresh start for the S130. That's safer.

Children
No Data
Related