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()
Related
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.
In my current scenario, I'm using NETLIGHT Pin (Pin no. 64) of SIM800 module with my PIC microcontroller to know whether my module is registered or not?
This way I built the circuit. Just I removed LED from VBAT. Then I connect collected of NPN transistor to pic micro input PIN.
I want to know whether any easy way using AT commands to find network registration status of SIM800?
Unfortunalty it's seem not to be really possible (or in fact detecting this state in only one way)
I use SIM800 and let it run for hours and I have seen many cases of network loose, while the AT+CREG? continue telling everything is OK.
Also, even with network down, the SIM800 continue sending you the name of the operator and the strengh of the signal.
The only way I've found is to monitor the serial port: when the SIM800 loose the network, it sends two messages:
+PDP: DEACT and
+SAPBR 1: DEACT
I suggest you to have a look at the document "SIM800 Series_AT Command Manual" and especially the chapter "19.3 Summary of Unsolicited Result Codes". You'll find +PDP and other interesting code (like under-voltage warning, DNS failed...) and see some of these messages are not linked to AT command.
From the manufacturer's documentation:
When I connect to a BLE peripheral using encryption on iOS 9.1 using a iPhone 6S the BLE peripheral is immediately disconnected. I've verified that this works on iOS 8 and 9.02. I've validated that the CBCentralManager didConnect delegate method is being called and a valid CBPeripheral object is being returned.
The BLE peripheral is disconnected immediately. I'm not able to even proceed to discover any services or characteristics before it is disconnected. The CBCentralManager didDisconnect method is called, but no error is returned.
Is anyone else seeing this? This has been working correctly for over a year and like I said it's only happening when using iOS 9.1 on the iPhone 6S. Don't have any other peripherals on 9.1 to test with.
UPDATE
According to Apple the issue is happening because we're not bonding the peripheral with the iPhone. So we've updated the firmware on the peripheral and are now bonding. This is presenting different issues surrounding maintaining bonding pairs between the phone and the peripheral. Our peripheral has a limited amount of memory, so we cannot maintain an infinite amount of bond references. To handle this scenario the peripheral allows for a maximum of 8 BLE bonds to be stored. When it receives a ninth request the first bond is removed from the peripherals list of bonded devices. This presents an issue because the iPhone doesn't know this bond has been removed and when I try to connect with the first device and interact with a characteristic I'm not prompted to pair. Which from my understanding is what kicks off the encryption process.
I'm wondering if there is anyway to remove a bond / device from an iPhones list of bonded devices, other then going into the Bluetooth settings and 'Forgetting' the device.
UPDATE #2
Apple has confirmed that there is NOT a way to remove a bonded peripheral from the 'MY Devices' section within the Bluetooth settings in the application due to security issues.
Based on this the scenario has now turned into the following. The iOS device has a reference to what was once a bonded peripheral under "My Devices" however that peripheral no longer has a reference to the iOS device within it's bonded devices table.
When I attempt to connect the iOS device, which still has the bond reference in it, to the peripheral that no longer has the bond reference we can connect successfully. However, after I connect successfully I discover the characteristic, set it to notify and receive no response and no pairing message. The only solution that fixes this issue is going into 'Settings' and 'Forgetting' the device and then attempting to reconnect.
Has anyone else experience this issue? Suggestions?
Thanks!
I am working on a product with an LPC1788 which needs the following USB features:
Firmware download (from host PC to device, not through a USB
key).
File upload (from device to host).
Ideally we'd also be able to get some information from the device like serial number etc.
The device should only work with a custom Windows application, so simply using a mass-storage device as-is will not do. There are quite a lot of data to upload (200MB +), so using USB bulk transfers seem necessary to me.
What is the best way to approach this? I imagine I would need to create some sort of USB composite device(?). However, I was hoping to use nxpUSBlib or winUSB so I don't have to go through the Windows driver validation process.... What are my options? Perhaps there some way to make the mass-storage device invisible for Windows?
Thanks!
Dirk
I think you'll definitely want to go with a vendor specific bulk device and you can easily use WinUSB for all of this. This should be sufficient for everything you've specified here.
For your firmware loader I'd recommend looking at the DFU (device firmware update) specification. You'll probably want make some command for your device that when sent will cause it to reenumerate itself in to DFU mode for update (rather than a composite device that is always exposed - this restricts the issue of the other interface being in use while you're flashing your device). Then you can flash it and reset it so it will reenumerate as your vendor specific bulk device again.
I wouldn't recommend mucking with mass storage, from your requirements it will be better to implement your own protocol and create some application or DLL that consumes the WinUSB API to communicate with your device, including the firmware update.
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.