• State Not Answered
  • Replies 1 reply
  • Subscribers 67 subscribers
  • Views 1813 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 102862
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SendData block in Master Emulator

Hugh

I'm using API 2.1.3 and I'm having problems with SendData blocking forever at the end of a process. I placed access mutexes around each method call to the library, as well as a mutex on Reset so that Reset is not asynchronous (since the documentation mentions this to be a hardware process, which I assume can cause the Master Emulator library to go out of sync with the hardware module). Here is the call stack where it's unresponsive:

[In a sleep, wait, or join]	
mscorlib.dll!System.Threading.WaitHandle.InternalWaitOne + 0x22 bytes	
mscorlib.dll!System.Threading.WaitHandle.WaitOne + 0x28 bytes	
Ulpbt.dll!Ulpbt.BackwardComp.WaitForSendBuffer + 0x48 bytes	
Ulpbt.dll!Ulpbt.BackwardComp.Pts3SendDatapacket + 0x96 bytes	
[Lightweight Function]	
emulatorlibs.dll!DLRCachedCode.SendDataPacket$323 + 0xba7 bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Default2Call3 + 0x8e bytes	
System.Core.dll!System.Dynamic.UpdateDelegates.UpdateAndExecute5 + 0x10d bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call3 + 0xea bytes	
IronPython.dll!IronPython.Runtime.Method.MethodBinding.SelfTarget + 0x53 bytes	
emulatorlibs.dll!DLRCachedCode.Write$340 + 0x386 bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Default1Call2 + 0x78 bytes	
System.Core.dll!System.Dynamic.UpdateDelegates.UpdateAndExecute4 + 0x10a bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call2 + 0xe4 bytes	
IronPython.dll!IronPython.Runtime.Method.MethodBinding.SelfTarget + 0x50 bytes	
emulatorlibs.dll!DLRCachedCode.SendWriteCommand$358 + 0x359 bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call3 + 0x5e bytes	
System.Core.dll!System.Dynamic.UpdateDelegates.UpdateAndExecute5 + 0x10d bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call3 + 0xea bytes	
IronPython.dll!IronPython.Runtime.Method.MethodBinding.SelfTarget + 0x53 bytes	
emulatorlibs.dll!DLRCachedCode.WriteWithoutResponse$728 + 0x4a8 bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call3 + 0x5e bytes	
System.Core.dll!System.Dynamic.UpdateDelegates.UpdateAndExecute5 + 0x10d bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call3 + 0xea bytes	
IronPython.dll!IronPython.Runtime.Method.MethodBinding.SelfTarget + 0x53 bytes	
emulatorlibs.dll!DLRCachedCode._sendDataRemoteStore$190 + 0x8d8 bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call3 + 0x5e bytes	
System.Core.dll!System.Dynamic.UpdateDelegates.UpdateAndExecute5 + 0x10d bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call3 + 0xea bytes	
IronPython.dll!IronPython.Runtime.Method.MethodBinding.SelfTarget + 0x53 bytes	
emulatorlibs.dll!DLRCachedCode.SendData$189 + 0xf41 bytes	
IronPython.dll!IronPython.Runtime.PythonFunction.FunctionCaller.Call3 + 0x6e bytes	
[Lightweight Function]	
[Lightweight Function]	
MasterEmulator.dll!Nordicsemi.MasterEmulator.SendData + 0x12 bytes

What can cause this problem? Is there a way to timeout or cancel the wait? Thanks.

Parents
  • 0

    Hi, the stack trace you show is caused by the Master Emulator DLL running out of available ACL data buffers. It will wait until new buffers are available. Available buffers are signaled by the reception of num_completed_packets events from the MEFW link layer over HCI. When it blocks like this those events are not being received for some reason.

    Normally there would be two main causes for this to happen:

    1. The peer device (the peripheral) has no capacity to accept more data packets and therefore the link layer of Master Emulator must keep retransmitting the same packet. This means no buffers are being freed.
    2. The Master Emulator firmware, MEFW, has asserted and does no longer respond in any way. This would cause the Bluetooth link to die, but the Master Emulator DLL would not know since it has not received any signal of this from MEFW.

    I would suggest doing a trace with a packet sniffer such as nRF Sniffer. It would show which one, if any, of these two scenarios are happening.

    Lastly, a configurable timeout will most likely be added to the next release of Master Emulator DLL. It would not fix the root issue, but it would avoid the application being locked in a infinite blocking wait as shown above.

Reply
  • 0

    Hi, the stack trace you show is caused by the Master Emulator DLL running out of available ACL data buffers. It will wait until new buffers are available. Available buffers are signaled by the reception of num_completed_packets events from the MEFW link layer over HCI. When it blocks like this those events are not being received for some reason.

    Normally there would be two main causes for this to happen:

    1. The peer device (the peripheral) has no capacity to accept more data packets and therefore the link layer of Master Emulator must keep retransmitting the same packet. This means no buffers are being freed.
    2. The Master Emulator firmware, MEFW, has asserted and does no longer respond in any way. This would cause the Bluetooth link to die, but the Master Emulator DLL would not know since it has not received any signal of this from MEFW.

    I would suggest doing a trace with a packet sniffer such as nRF Sniffer. It would show which one, if any, of these two scenarios are happening.

    Lastly, a configurable timeout will most likely be added to the next release of Master Emulator DLL. It would not fix the root issue, but it would avoid the application being locked in a infinite blocking wait as shown above.

Children
No Data
Related