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.
Related
I have a program written in Visual Basic (.NET Framework 3.0) that communicates with a power supply via a D2XX driver (over COM3) and a pump via a VCP driver (over COM2). Currently, if both USB devices are plugged in when I start the program, it tries to communicate with the pump, (COM2) when trying to communicate with the power supply (COM3). I found a temporary solution to this issue by only have the power supply connected when starting the program. Then I initialize communication with the power supply, and afterwards plug in the pump; this allows the program to communicate with both separately for the rest of the time running the program. But this process is tedious and I am hoping there is an alternative solution where I can keep both units connected via USB and the computer communicates separately. What is confusing is that this communication issue was not always the case, a week ago it worked without having to disconnect the pump (all drivers are updated, and on the device manager they are listed as their respective COM ports as well) ; I am struggling to find some correlation between what is the underlying issue.
I tried to delete other hidden additional COM ports. I made sure all drivers were updated. When the pump is communicating via the same port as the power supply, and then I try to communicate with the pump, I receive this error:
System.UnauthorizedAccessException
HResult=0x80070005
Message=Access to the port 'COM2' is denied.
Source=<Cannot evaluate the exception source>
StackTrace:
<Cannot evaluate the exception stack trace>
But again, If I start the program with only the power supply plugged in and initialize communication with the power supply, and THEN plug in the pump, this issue is evaded. I hope someone can give some sort of direction at all troubleshooting this issue because I am completely stumped. Thank you!
Most likely your program implicitly relied on the correct enumeration order. If you use devices with an FTDI product with internal flash or with dedicated eeprom, you may be lucky: Many can configured via FT_PROG to be visible only for D2XX and not as VCP. This way you can avoid the problem. Alternatively, you can try to modify your program so that it accesses D2XX first. Make sure to filter out the correct device using device informations. E.g. the serial number or the VID:PID if the device manufacturer has made the effort to aquire its own IDs. Check 3.4 FT_GetDeviceInfoList of D2XX Programmer's Guide for details.
I was able to make a working HID USB stack on my "StartUSB for PIC" board for the 18F2550 microcontroller. I based it on one of the MLA libraries, which was made for the 18F45K50 (MLA 2018_11_26, hid_custom, picdem_fs_usb_k50.x), but I converted it to work with the 18F2550 (there might have been easier ways, but only learned to work with PIC about 1 month ago). On the host side, I'm using LibUsbDotNet (also here, there might be easier ways - the documentation on this library really sucks) on a Windows 10 machine.
I'm using the HID class, full speed, and all seems to work. Although, I get some random errors on the host PC (see below), but doing one close/re-open cycle on the host side when getting the error is kind of solving it. Dirty, but it works. So I kind of ignore this now.
Win32Error:Win32Error:GetOverlappedResult Ep 0x01
995:The I/O operation has been aborted because of either a thread exit or an application request.
I'm not an expert on USB (yet). But all examples I'm seeing are based on 1) you send first a command to the device and 2) then you retrieve the answer from the device. I did some performance tests, and see that this indeed shows that I can do about 500 cycles/second. I think that is correct, because each cycle, sending command and retrieving answer, each takes 1 msec.
But do I really need to send a command? Can't I just keep reading endlessly, and when the device has somthing to say, it does send the data in an IN transaction, and when not it ignores which creates a timeout on the host side. That would mean that I can poll at 1000 cycles/second? Unfortunately, I have tried it by changing my implementation on the PIC, but I get very weird results. I think I have issues with suspend mode. That brings me to another question - how can I make the device get out of suspend mode (means that not the host, but the device should be triggering this event). I have searched the MLA library for command such as "wakeup", "resume", ... but couldn't find anything.
So, to summarize, 2 questions:
Conceptual: Can I send data from device to host without being requested for it by a command from the host?
For PIC experts: How can I have a device trigger for a wakeup from suspend mode?
And indeed, the answer is Yes on the first question.
In the meantime, I found another link on the web that contains a Visual Studio C# implementation of a USB library including all the source files.
If you're interested, this is the link
This C# host implementation works as a charm. Without sending a command to the device, I get notified immediately if a button is pressed. Great!
It also proofs that my earlier device implementation based on the original MicroChip MLA, is 100% correct. I stress tested the implementation by sending a "toggle LED command" as fast as I could, and I reach 1000 commands/second. Again great!
I think that LibUsbDotNet isn't that perfect after all. As I wrote above, I get rather unstable communication (Win32Error). But with this implementation, I don't get a single error, even after running for half an hour # 1000 commands/second.
So for me, case closed.
A little new to NRF52, so please pardon if this turns out to be a noob question. I'm using nrf52832 as a peripheral and loading the standard SDK peripheral example of GATTS ( any other does result in the same).
After configuring that device i try to connect my phone to it , which happens succesfully. But after unpairing my phone and trying to configuring again my phone cant pair with the device.
Phone shows:
Could'nt pair .Check settings of this device.
Sniffer shows:
Rcvd pairing failed: Pairing not supported.
I do understand that some thing is getting stored in persistent memory. So how do i remove it or how do i load that data again.
Mobile app Logs:
Error 22 (0x16) GATT_CONN TERMINATE LOCAL HOST
Sounds like you've triggered one of the default security features of the nRF.
The nRF knows it has an encryption key with the phone (as it's been paired before), but the phone doesn't know the key (because you unpaired it and it deleted the key), so the nRF assumes someone is trying to spoof the real phone and drops the connection as defense.
Not sure which nRF SDK you're using, but if you search for peer_manager in the initialisation routine you should see an option to allow keys to be over-written.
Here's the relivent docs. One quick-fix, if security isn't a concern, is to delete all bonding info on the nRF with pm_peers_delete()
I'm facing issues when communicating with devices over USB hub. When enumerating devices directly to host port, it does work, some devices over usb hub have issues.
Setup: STM32F103C8 - MAX3421E - LUFA (usb stack) (ported to MAX3421E (host) and STM32F103C8T6 (device)) - USB Full-Speed setup
Scenario:
When I attach device directly to host, I don't experience any issues enumerating almost all (some devices seems to be faulty and have weird/nonstandard behavior) devices. But when I try to enumerate over usb hub, devices starts to behave very strangely. I'm receiving much more NAK's from devices than when connected directly to host. Some devices are able to return Device Descriptor, but retrieving Configuration Descriptor fail. Some devices return Toggle Error after several NAK's, this could be remedied so far by delaying retry IN token. Also there is different behavior of devices when connected over different hubs. I.e. one device has no problems when connected to HUB1, but have issues when connected to HUB2. Then I have HUB3 (7 port) which internally acts as HUB in HUB. On this HUB3 device working fine on port behind secondary internal hub, but not on primary ports exposed over "root" hub.
I'm in suspicion that hub's TT could be somehow interfering with usb communication, but according to information I have found, TT should not be enabled under Full-Speed setup.
I have checked (many times) that I'm setting correct device address assigned during SetAddress phase (which is proved by returning Device Descriptor). When I step debug it seems that I can get Configuration Descriptor also, but while in normal system run, it isn't retrieved, but only over hub.
Does anyone has any ideas, what to look after? I've run out of ideas here after week of trying to find a root cause.
Thanks
so...
- as usual after searching for root cause, solution after days of trying comes naturally after asking on somewhere (this is hapenning to me always, but I do try prior asking always)
- when using hubs, make sure you don't suspend SOF generation during control transfers. LUFA just resume bus inside control transfer routines, so make sure you don"t stops and reenable SOF within (my fault as I'm using ported version to MAX)
- if you have tight main loop make sure you don"t reinitialize usb transfer without completion of previous try, but if you do so, check you don't owerwrite data which haven"t been processed yet fully (especially when using interrupt-driven transfer complete processing) [things seems to work when you have quite some debug output, as it delay that time critical transfers]
Enumeration over hub isuues are now second to none. Small glitches are subject for tweaking.
Unfortunately as I was in question for electrical issues, I had to unsolder usb host shield and soldered another one, which in light of new information seems unneeded. Nevermind, I have trained my soldering skills.
I have been working on Reachability class for a while and have tried both the one from Apple sample and the one from ddg. I wonder whether the Reachability class keep sending / receiving data after starting the notifier.
As I'm developing an app which connect to different hosts quite often, I decided to write a singleton and attach the reachability classes I need on it. The reacability classes would be initiated and start their notifiers once the app start. I use the singleton approach as I want this singleton class to be portable and can be applied to other apps without much rewriting. I am not sure if it is good idea to implement like this but it worked quite well.
However, someone reported that the battery of his device drain significantly faster after using the app and someone reported more data usage. My app does not send / receive data on background so I start wondering if it is related to the reachability.
I tried profiling the energy usage with Instrument and I notice that there are continuous small data (few hundred bytes in average) coming in via the network interfaces even I put my app in idle. However, there are almost no data sending out.
I know that Reachability requires data usage when initiate (resolving DNS etc) but I am not sure that whether it still keep using data after starting notifier. Does anyone can tell?
I am not familiar with the low-level programming, it would be nice if someone could explain how does the Reachability work.
I use Reachability, and while I haven't monitored the connections, I have browsed the code, and I can't see any reason why it would keep sending ( or receiving).
If you have a ethernet connection to your Mac, it is quite easy to check. Enable sharing over wifi of your ethernet connection. Install little snitch, it will run in demo mode for three hours after every boot. Turn off the data connection on the test device and connect it to your mac over wifi.
This will allow you to see any network access your test device is making.
If this isn't possible, you can also run your app in the simulator as the network side should be the same, so you should be able to check.
There are also a ton of other tools to track network activity, but I think little snitch is the easiest to use.