Kindly attach the project.
The only thing that would change depending on how long you leave the unit off is whether a potential battery/capacitor discharges within that time frame. Are you sure the unit is turning off in the first place, and not just having the power source disconnected? (The unit might have enough power stored to hold data for 7 minutes for example before the capacitor/charge runs out).
File attached to original message.
I did think of the power held up by a cap but with power off there remains only about 1mv of noise on vdd. To be sure, though, I connected a short wire from vdd to Gnd (with power disconnected) and it had no effect.
Thinking more about this, it seems like the power being held up by a cap, etc. shouldn't keep it from reconnecting when power is reapplied. Unless, somehow, that erased the stored bonding info from flash.
I would like to bounce another thought off of you: According to several things I picked up on the net it sounds like iOS decides to store bonding information only after it figures out the peripheral wants it to by reading a secure characteristic or service. It also seems like that may mean that my PSoC4 BLE Component has to be set for bonding and authentication with encryption. It doesn't seem like this is possible when it doesn't have input/output for authenicating it. What do you think?
Interesting thought; Yeah, powering stuff off is usually straight forward, but it was a thought
Bonding information has to be explicitly stored by both parties for it to work. I assume you are already storing it on the local PSoC4, so we can rule that out. And from the sounds of it, the iPad Air 2 holds the bond information for 7 minutes before wiping the bonding data and not using it.
One of the two devices needs to either: Request bonding when they connect together, or you need to access bonding-restricted attributes with the Central device when connected to initiate a bonding sequence (you should have code for handling this already).
You can still do bonding/authentication without input/output, BUT you will need to determine how you want it to truly authenticate then, as the easiest way is to have the human user verify both sides of the device for confirmation (OutOfBand key passing using a human).
You can either do this with a first device bonds, some button/procedure to initiate bonding for a new device, some alternative human interface to bond, etc. The software can be written to handle custom bonding/authentication with no Input/Output, but it makes it much harder than it would be otherwise
1 of 1 people found this helpful
I fixed it! The problem turned out to be that the module I was using (CYBLE-2140009-00) was built to support BLE 4.1 and the iPad, running iOS 11.3 supports BLE 4.2. The pertinent difference is that 4.2 handles resolvable private addresses (RPA) in the Link Layer and in 4.1 it's done in the host which requires programming to be done by the developer. There are other differences that may or may not affect the problem. If I was smarter at coding maybe I could have made it work. It appears that what was happening is that iOS changes the RPA randomly on some schedule (maybe every 7 minutes??) expecting the server to know how to resolve the new number in it's link layer. When it can't, the connection can not be re-established without re-bonding. To solve the problem I changed to the CYBLE-214015-01 module which does support BLE 4.2, and is a drop-in replacement for the first one.
[At least this explanation is what I think was going on. In any case, it works now.]