You are here

is there a working server bonding example | Cypress Semiconductor

is there a working server bonding example

Summary: 6 Replies, Latest post by e.pratt_1639216 on 31 Jan 2017 03:17 PM PST
Verified Answers: 0
Last post
Log in to post new comments.
jetro570's picture
User
27 posts

I have run the client bonding example from project #15 of 100 days of code,  however I am designing a server with no display and no keypad, and i want it to pair/bond to android app so user doesnt have to keep manually manipulating the andrio app to see the device,       according to debug uart printing to tera term the device does:

GAP_SMP_NEGOTIATED_AUTH_INFO: 33
CYBLE_EVT_GAP_AUTH_REQ: security=0x3, bonding=0x1, ekeySize=0x10, err=0x0
  GAP_CONNECTION_UPDATE_COMPLETE: 2a
  GAP_ENCRYPT_CHANGE: 29
  GAP_KEYINFO_EXCHNGE_CMPLT 2c
Authentication Complete
CYBLE_EVT_PENDING_FLASH_WRITE
Store bonding data, PENDING status: 28
  GAP_CONNECTION_UPDATE_COMPLETE: 2a

Yet if I exit the app and re enter the app,  either the pairing data is not being recovered, or the previous flash write did not execute properly. 

similarily, if I use the Cysmart PC application, I can connect, then pair, then discover all attributes, and enable all attributes, and if I disconnect, there is a key stored in the connections white list,  but when I try to reconnect, pairing fails, because it tries to use a different key.   

So I was wondering if others are seeing this,   OR is there an example project where this works properly?  I have not been through all the example codes, 

mady's picture
Cypress Employee
1093 posts

Hi,

Please find attached

Regards,

-Madhu

jetro570's picture
User
27 posts

thanks for trying, this does not work either,  here is the output, I am running on BLE kit 42 PSOC, CYBL10563-56 and running on cysmart app on android phone,     my own project works, it bonds, but doesnt pair, and then either does not do the flash write of the encryption key,  or on power cycle is not restoring the correct encryption key,   I have not figured out which one is the culprit.  but the above code doesnt work for me at all?  I even changed the BLE settings.  

Advertisement is enabled
BLE_Bonding Device ON
Starting to advertise

Advertisement is enabled
Device  Connected
Sending Security Request to Master

CYBLE_EVT_GAP_AUTH_FAILED: 15

jetro570's picture
User
27 posts

not sure exactly what is going on now.  I tried running your program and it failed,  so i reprogrammed my code/project and now it appears to work for no apparent reason.   I'll have to do more testing,  it appears to be a tool bug, or a programmer bug now?  who knows, far as I can tell, no software updates were done, unless something auto installed and I was not aware?  I will test multiple boards to see,  unless there is some unknown thing with the uart,  the only thing I did is add about 6 lines of code to be able to toggle on and off the printf statements so I can see only connection related messages on the terminal while blocking out some of the others

user_1377889's picture
User
10419 posts

Check your heap size for >= 0x0400 when using printf().

Another culprit could be when using sprintf() that the buffer is kept too short.

 

Bob

jetro570's picture
User
27 posts

thanks for trying, that wasn't it either, 

all i did was add code getchar()

if char = 'T'   skip over printf statements, xxx

if char = 'F'   skip over printf statements yyyy

etc..    not sure what the error was, if it was tool bug or operator error,  it is working now,  but I Have seen this before, where the compiled program that was actually burned in was not what I was expecting, or the most recent stuff, not sure if this is a progressive compile issue, or if I am doing something,  I have also seen trying to burn the same program into 2 different boards to give me different results as well,  

e.pratt_1639216's picture
User
380 posts

I'm not sure if this will be any help, but there is a setting under the debug & program options to only program the differences in the Flash/Hex file, or to program the entire flash chip on reprogram. This might be the issue if you are getting different results for different chips, but at a guess I would say most likely not.

Log in to post new comments.