• State Verified Answer
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 4429 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

  • 0 in reply to Hung Bui

    when this happens my app callback for log messages gets hammered with serial error messages. Windows can and will yank port assignments around. Normally there are reservations so that the same device will always get the same number. The problem occurs if the port is yanked and the app still is connected. In come cases the port is listed in the registry still and windows sees that the reservation cannot be honored and it advances the port number by one. The other case is that the port goes down do to a hub reunumeration (ESD, etc) and the reervation is honored, however the app now has a stale handle to the port that gets errors. I have a port chaser app that keeps tabs on things and restarts various parts of my system with the new or old com port number as needed. When this happens what is going on with the S130 stack running on the dongle? Can I just re-register without restart

  • 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.

Related