Resetting device via python bindings

RE: Resetting device via python bindings

Hung Bui — Tue, 04 Aug 2015 15:18:49 GMT

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.

RE: Resetting device via python bindings

Jim Dattolo — Tue, 04 Aug 2015 14:39:08 GMT

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

RE: Resetting device via python bindings

Hung Bui — Tue, 04 Aug 2015 11:11:20 GMT

Hi Jim,

I haven't seen the Segger COM port being changed when being in-use. Sometimes, I saw it changed when I unplug and plug it into another USB port. But there maybe different behaviour on other machine.

From my point of view there are some situations when Windows remunerates the USB-COM port that can cause the issue:

When BLE is active and waiting for a reply call from the application. Then a time-out can happens.
When the stack throw events, but the application fail to get the event out (because of the COMport switching), most likely again end up with a procedure timeout on the connection.

I can't think of anything other than these.

RE: Resetting device via python bindings

Jim Dattolo — Mon, 03 Aug 2015 14:32:27 GMT

Thanks for the response. I'll probably use nrfjprog as long as I can link the com port to the serial number via the registry. That was the part that was missing for me. I'll look forward to seeing the updated python bindings with the API exposed to do the reset as that would be the cleanest way for me to use. I have other questions that I will be posting about the com ports. Windows often renumerates USB serial devices and moves port numbers around while keeping power on the device. My old system would chase the port around and reconfigure the port to allow the retry manager to start working again. With moving over to the S130/Python stack the com port management is different and I want to know what Nordic is recommending as the correct way to keep chasing windows. Can I just setup the serial connection again while leaving the stack alone and will it keep working?

RE: Resetting device via python bindings

Hung Bui — Mon, 03 Aug 2015 11:09:04 GMT

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.

RE: Resetting device via python bindings

Jim Dattolo — Fri, 31 Jul 2015 14:25:30 GMT

I thought I was quite clear. I'm using the python bindings to the device which means that it's running the connectivity app. It's has to be by definition. I cannot change languages (which you are suggesting by telling me the solution is to call the C function in nvic) I have multiple years of python codebase that is currently talking to a different BLE solution via python wrappers that I developed years ago and that cannot change to accomodate a lack in the python bindings that are currently being used. There is no sd_nvic_SystemReset in the python bindings like I already mentioned. Without a way to reset the device via the bindings I cannot configure the stack again since it's already configured from a previous run (which can be from a different tool using different settings)

RE: Resetting device via python bindings

Hung Bui — Fri, 31 Jul 2015 09:20:54 GMT

Hi Jim,

I am not quite sure I fully understand your setup. Could you tell a little bit more on:

Which firmware do you use on the nRF51 that you mentioned has S130 ?
You mentioned that "dev has been going for years on the tool chain via a different chip supplier for BLE. " I don't understand this and how it's related to the Python code running with the nRF51 dongle.
What is the issue you are having ? You mentioned "it's already running in a state that I cannot guess ". What is that ?

To reset the chip, you can call sd_nvic_SystemReset() API.