I’m new to bluetooth development and I’m working on a project that require connecting to a BLE. Currently I have multiple problem that I will list them:
The app (some times) keep disconnecting from Peripheral with three different reasons:
The first one is "The connection has timed out unexpectedly.” with error code = 6.
The second one is unclear to me, error object is null.
The last one is "Unknown error".
how can I solve such a problems? the disconnection interval between each one is ~10 sec., after the disconnection, I’m trying to reconnect again, which will reconnect then disconnect, how can I solve such an issue?
While debugging the app using xCode, the above errors does not appear, I can check these error on adhoc version or release version (from debug log from the devices that uses the app), but in xCode I can see a warning:
"[CoreBluetooth] WARNING: Characteristic <CBCharacteristic: 0x1706aab00, UUID = FFF3, properties = 0x8, value = (null), notifying = NO> does not specify the "Write Without Response" property - ignoring response-less write”
Is this warning relative to the disconnection problem? or does this warning meaning that the app will disconnect from Peripheral at some point?
If I don’t stop scanning for Peripheral, will this create an issue for me? currently I keep scanning for Peripheral despite I’m connecting to one, the only case I stop scanning is when the app is terminated.
Related
I have a problem with the lifecycle of Bluetooth on iOS.
We are using React Native and the following library (https://github.com/innoveit/react-native-ble-manager) to manage our Bluetooth devices.
The devices sends data and clears its local data when it has sent all its data through bluetooth (we are only using ble messages ACK, no internal app ACK).
The problem is, that iOS seems to maintain the ble open when the app is killed, which is making the device think that it is still sending data that is processed correctly by our app, and clears it at the end (which causes data loss).
Is this a normal behaviour on iOS ? (the fact that the ble stays open for some time after the app is killed, and no errors are sent through ble ?)
Is there a way to force close the ble when the app is killed ?
Thanks
Is this a normal behaviour on iOS ? (the fact that the ble stays open for some time after the app is killed, and no errors are sent through ble ?)
Yes, this is normal. The OS holds open the connection and shares it with apps. The apps do not hold connections directly. It can take some time (generally on the order of seconds, but sometimes a bit longer) for the OS to drop the connection after the last app releases it.
Is there a way to force close the ble when the app is killed ?
No. There is no way to do anything when the app is killed (by which I assume you for force-quit, for example by swiping up on the app switcher).
All that said, I'm a bit surprised here that you're getting a write response back to the device if the app is no longer reading. When you say "ble messages ACK," specifically which "ack" do you mean? Are you getting a Write Response packet back? Or do you mean a lower-level ack?
Lately numerous network requests with Alamofire made from our iOS device fail with the following error:
Error Domain=NSPOSIXErrorDomain Code=28 "No space left on device"
UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask
.<3>,
_kCFStreamErrorDomainKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask .<3>" ),
_kCFStreamErrorCodeKey=28}
Our app has a mechanism to send a network request if the user has moved +- 10 meters. This is checked every 5 seconds, so in theory every five seconds a call can be made. The network request fails occasionally with this message, returning no status code and the above error.
The message implies the error has to do with available disk/memory space on the device. However, after checking both there is no link to be found since there is plenty of space available. Also, the error occurs on multiple devices, all running iOS 14.4 or higher.
Is there information available regarding error code 28 and what could be the culprit on iOS devices? Even better; how can this error be prevented?
To answer the occurrence of the error itself:
NSPOSIXErrorDomain Code=28 "No space left on device"
With logs in the Xcode terminal:
2021-05-07 15:56:50.873428+0200 MYAPP[21757:7406020] [] nw_path_evaluator_create_flow_inner NECP_CLIENT_ACTION_ADD_FLOW 05CD829A-810D-412F-B86E-7524369359E8 [28: No space left on device]
2021-05-07 15:56:50.877243+0200 MYAPP[21757:7400322] Task <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1> finished with error [28] Error Domain=NSPOSIXErrorDomain Code=28 "No space left on device" UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalUploadTask <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1>, _kCFStreamErrorDomainKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalUploadTask <5504BCDF-7DFE-4045-BD4B-E75054636D5B>.<1>"
), _kCFStreamErrorCodeKey=28}
It appears to get called when there are too many NSURLSessions created, reaching a limit of (in our tests) 600-700 sessions, which are not maintained or closed properly. The error started to get thrown since iOS 14, so it is interesting to see if there was a limit introduced.
Linked is a github issue raised stating the same issues on the ktor microservices framework by JetBrains, pointing in the same direction, mentioning the invalidation of sessions to prevent this issue:
https://github.com/ktorio/ktor/issues/1341
In our own project the origin of the problem turned out to be our implementation of the StarScream websocket library. This might not be relevant for the issues others are having, but explained anyways to create a complete picture of the problem. It is the cause and fix of our specific situation.
At first we assumed it had something to do with the URLSession created by Alamofire (networking library used) since POST requests started to get cancelled, and a kill of the app seemed the only solution to do requests again.
However, we also make use of websocket connections using the StarScream library, which attempts to connect to an socket, and if failed retry to connect every two seconds for a max time of two hours. This would mean for two hours, every two seconds, we connect to the socket -> receive a failure to connect -> disconnect the socket -> connect again. Using a singleton of the socket it was thought there was no possibility of creating multiple URLSessions, since the socket was only initiated once. However calling the connect to the socket again would create a new nw_connection object every single time, since the library did not handle the disconnect properly.
image of NWConcrete_nw_connection objects generated in socket connection
The way this was validated was using the instruments app to check for the creation of new nw_connection objects. Logged as a "memory leak" there, the creation of the nw_connection objects was getting logged and the solution was to make sure we disconnect the socket (invalidate the session) properly before connecting again.
I hope to answer a big part of the issue here, and I will mark my own question answered since this was the solution to the problem at hand. I think Apple should consider giving accurate reports on the number of objects created being limited, instead of giving an error "No space left on device".
Just wanted to chime in with more info, since we're experiencing the same issue.
Based on our analytics, this issue only started happening since iOS 14. We've verified it happening on 14.2, 14.4 and 14.5. Naturally the most straightforward cause for this error would be low memory or disk storage. We've excluded this option with additional logging, as you seem to have done as well.
A possibly related SO post has attributed the issue to a network inspecting framework that was enabled in their release build. It's worth checking if you use a similar tool.
Another report of this issue, this time on the Github of AFNetworking (predecessor to the Alamofire library you use), says they were able to fix it by limiting the creation of URLSession objects.
For us personally, neither of these did the trick. We created a support ticket with Apple, but this hasn't lead to a solution. They requested a small sample project that reproduces the issue, but the error only manifested after 7 days of continuous use in our app. If you have a faster way to reproduce this, it may be worth it to submit your own support ticket.
Hopefully this helps you find a solution, if you do please add this to your post to help others!
In core bluetooth, after connecting to a device , it gets automatically disconnected after 5 to 10 seconds. Its gives error something like this:
Error Domain=CBErrorDomain Code=7 "The specified device has disconnected from us."
It just started showing suddenly. What could be the reason and how to resolve it.
Sounds like it could be two issues: either a release problem or firmware problem. For the first, ensure that you are retaining the peripheral after connection. Do this by assigning it to a strong CBPeripheral property or add it to a strong array. The second problem would involve issues with your firmware expecting a certain command to be read/written after connection which you are not sending. Assuming this firmware was written by someone else, developers add in extra security checks like this to prevent developers from using their peripherals for other purposes. If it is your own firmware, I suggest consulting your chip manufacturer's starter kit.
I am having trouble running the debugger on a STM32F205ZG using µVision4 and the ULINK2. I keep getting the error message "Could not stop Cortex-M device! Please check the JTAG cable." I am using the SW port. Any help with this would be greatly appreciated.
In my own experience I have usually seen this error when either the ULINK2 is disconnected and reconnected while in the middle of a debug session or if you have some external hardware, outside of the control of the debugger, that is acting on your processor.
If the ULINK2 was disconnected mid-debug, then usually cycling power to your device will fix the problem.
If you have something like a watchdog timer that is trying to reset the processor while you are in the middle of debugging, then you will have to disable the watchdog before you can start a debug session.
I've seen the same problem with my NXP uC.
The problem was that the code loaded in flash was faulty and was placing the CPU into a busy loop branching back to the same address, this prevented the debugger accessing the bus.
the uLink worked if I put the device into ISP mode as it never got to the user code.
it seems that uLink takes too long to halt the device after reset, the spec tells you this somewhere, so by the time uLink tries to halt the CPU it is too late as it cannot access the bus and locks up.
I had this problem on LPC4337. I tried all the solutions people are talking about but the only one that worked for me was using a lower processor clock so that JTAG/SWD interface can match/catch up with the processor before it is gone too far into executing user code. In my case I set JTAG/SWD clock in Keil uVision 5 to 10MHz and the changes the processor clock divisors to give 36MHz. With these settings, it never missed to capture on reset when I begin a debug session.
This happens for ULink2 but ULINK Pro and ULINK Pro-D support a JTAG/SWD <= 50MHz. See this link for more comparisons:
ulink comparisons
Just an other issue with this message:
We have the same error message, but the problem was the wrong state of the RESET line.
I got below warning in weblogic 9.2
Warning <Socket> <managed2> <ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel
>> <> <> <> <BEA-000450> <Unable to find internal data record for the socket 7; event received
Can it effect any performance in my application?
If it effects, please provide a solution for this.
Thanks in advance.
Regards,
Ganesan Chandrasekaran.
Is this a one-off or occurring frequently?
From the documentation
BEA-000450
Warning: Socket socket internal data record unavailable (probable
closure due idle timeout), event received event
Description Unable to find internal data record for the socket.
Cause Server already closed the idle socket.
Action If situation persists, contact Oracle Customer Support.
This is mostly a harmless message but you would need Oracle help if it is always appearing
This was also discussed on the Oracle forums
The root cause of this message is due to fixing the OutOfMemory
message being reported in an incident CR346335 for WebLogic 9.2 MP3.
Code changes were made to explicitly remove the associated objects
from memory for a given socket after the timer thread closed the
socket as OS was not reporting the error on the OS level. As a result
of the removal of the associated objects, the message starts appearing
in the log.