Crashes and Errors using Mindtree Bluetooth Stack

I do not have access to a Bluetooth sniffer right now.  I will see if I can locate one.  The iPod Touch consistantly shows the error.  However I do see this error occasionally even with the iPhone.  Although the iPhone is much more reliable through the connection process, it does exhibit the same failure from time to time.  I suspect both devices support the spp protocol but I cannot prove it at the moment.

Regardless of the error, why would the call into the BT_hci_disconnect function cause a crash of the system?  How can I debug this crash?

Have you by any chance made any modifications to the read/write task stack sizes?

Meanwhile, we are trying to see if we can simulate and reproduce this issue at our end as well.

No, the current setting for the configMINIMAL_STACK_SIZE is as it was in the demo code.  I thought this may have been the issue early on, and I tried to increase it from 128 to 192 with a corresponding increase in the configTOTAL_HEAP_SIZE from 3250 to 3400, but when I compiled and ran that code, it crashed immediately with a DebugChk.  I assume this must be because I wasn't increasing the stack size properly, although I figured just changing the config parameter would have worked.

No, have have not added any additional tasks or semaphores to the system.  I have added all my changes to the existing user task.  There were two changes that were made to the system that are worth mentioning:

1.  The timer that triggers execution of the TIMER1_A0_ISR routine runs at a 5msec tick rate rather than the 1 second rate in the original code.  This increased tick rate was required to control a display mux line on our hardware.  Most of the time, that is all that is done in this interrupt.  Once every 200 interrupts, I permit the code to execute what was essentially the original ISR.  

2.  I have two additional ISRs in the system that get triggered whenever a capacitive touch keypad is touched.  One interrupt is the touch detection and the other interrupt is to support the SPI interrupt data transfer between the cap-touch controller and the processor.  However, during the error condition that I've previously described in this posting, I'm not touching the keypad so these interrupts should not be firing.

I don't know if this will help the investigation, but I decided to try a test using the original demo platform hardware and software.  I modified the original software so that SDK_INQUIRY_LAP would be set to BT_GIAC instead of BT_LIAC.  This was necessary so that the demo platform could find the iPod Touch.  I then changed the name of my iPod Touch to be BlueMSP-6774.  This had the effect of getting my device to appear in the connect menu.  When I attempted to connect to my iPod Touch device, the demo unit didn't crash, however it did print out an "ACL Disconnected" message.  I never got a dialog to appear on my iPod Touch that asked if I wanted to Pair with the device, which implies that the connection never got established.

I cannot perform the same test on my iPhone yet, but as soon as I can, I will attempt it to see if I get the connection/pair dialog to appear on the iPhone.

I never got a dialog to appear on my iPod Touch that asked if I wanted to Pair with the device, which implies that the connection never got established.

MindTree's Bluetooth library that you are using, supports the SSP (Secure simple pairing) feature, which allows two devices to connect securely without the need of a user input on either sides. So, you might have established a connection and might still not observe pairing.

Since we have observed, that with the original software  we don’t see a crash when trying to connect to the iPod touch, please confirm the following things, with the same setup:

1)The ACL connection is successfully established:

This can be checked by observing if control reaches the function  appl_acl_connection_complete_event in appl_sdk.c.

2)The SDP query is successful in finding SPP on the remote device:

 This can be checked by reading the value returned by the function call:

  BT_sdp_get_channel_number(data, &appl_spp_remote_server_ch) in the file appl_spp.c.

 If the value of the variable retval is API_SUCCESS( 0x00), then the check has passed.

Please also provide a memory dump of the following arrays uart_tx_buffer,circular_buf and the values of their indices, uart_tx_rd,uart_tx_wr,circular_buf_wt,circular_buf_rd when the ACL disconnection is seen.

If you are able to perform the same test using a different bluetooth device, instead of the one with MindTree stack, and if you can share your observation, this might help us too.

Regards

Ullas

Okay, I performed the test with my iPhone and iPod Touch.  The iPhone worked fine and established the connection as I would expect.  When I used the iPod Touch, i was able to hit my break point at the appl_acl_connection_complete_event, so that part succeeded.  Further, I hit my breakpoint at the return from BT_sdp_get_channel_number and the result code as 0x00.  The unit crashed before it got to the breakpoint I has set up in the sdl_pl.c where STATUS_ACL_DISCONNECT would be handled.  Here are the values of the variables/memory dump you requested:

uart_tx_rd = 380

uart_ts_wr  = 380

circular_buf_wt = 61

circular_buf_rd = 61

uart_tx_buffer:

00 00 00 01 82 fd 14 00 9c d0 d0 d0 d0 d0 d0 d0 d0 d0 da e4 ee f8 02 0c ff 00 00 01 82 fd 14 01 9c d0 d0 d0 d0 d0 d0 d0 d0 d0 da e4 ee f8 02 0c ff 00 00 01 82 fd 14 02 9c d0 d0 d0 d0 d0 d0 d0 d0 d0 da e4 ee f8 02 0c ff 00 00 01 87 fd 03 0f 0f 0f 01 76 fd 2a 01 21 54 61 57 14 05 0a 05 00 07 06 0a 04 05 08 09 0b 0c 0d 0e 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 01 80 fd 03 00 01 01 01 80 fd 04 3c f0 5f 00 01 01 04 05 33 8b 9e 0c 00 01 19 04 0a 61 56 52 a1 f1 70 01 00 19 0b 01 19 04 0a 2d be 10 94 22 00 01 00 6b 77 01 19 04 0a 33 c3 32 a1 0e 00 01 00 60 43 01 19 04 0a 74 67 1a 0d 84 90 01 00 da 13 01 05 04 0d 74 67 1a 0d 84 90 18 cc 01 00 da 13 01 01 37 0c 04 01 00 00 19 02 01 00 0c 00 08 00 01 00 02 01 04 00 01 00 40 00 02 01 00 0c 00 08 00 01 00 0b 03 04 00 02 00 01 00 02 01 00 10 00 0c 00 01 00 04 02 08 00 00 02 00 00 01 02 80 00 02 01 00 0e 00 0a 00 01 00 05 04 06 00 00 02 00 00 00 00 02 01 00 16 00 12 00 00 02 06 00 01 00 0d 35 03 19 11 01 00 30 35 03 09 00 04 00 02 01 00 0c 00 08 00 01 00 06 03 04 00 00 02 40 00 01 11 04 02 01 00 01 0c 04 06 74 67 1a 0d 84 90 01 2b 04 09 74 67 1a 0d 84 90 03 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 18 0c 02 00 32 01 0f 08 02 05 00 01 43 0c 01 01 01 47 0c 01 01 01 3a 0c 07 02 33 8b 9e 00 8b 9e 01 24 0c 03 14 28 00 01 2e fd 0d 01 2c 01 04 00 0a 00 00 00 00 05 12 03 01 02 00 22 28

circular_buf:

04 04 17 06 74 67 1a 0d 84 90 04 0e 0a 01 0c 04 00 74 67 1a 0d 84 90 04 31 06 74 67 1a 0d 84 90 04 0e 0a 01 2b 04 00 74 67 1a 0d 84 90 04 36 07 22 74 67 1a 0d 84 90 04 06 03 13 01 00 44 65 76 20 69 50 6f 64 00 00 00 0d 00 0d 00 d0 0d 0d 03 43 4d 34 d3 74 dd dd dc 71 c1 c0 00 00 00 d0 d0 dd 37 77 1d c7 07 00 00 00 d3 77 1c 00 0d 37 70 03 4c 70 dd c0 dc 7d 30 0d c0 c0 80 80 00 00 00 00 41 00 41 00 00 00 00 00 34 00 d3 4d 34 34 0d 00 d0 34 d3 40 34 31 d3 40 37 71 c7 74 00 00 0d 34 d3 77 77 74 37 07 1c 07 1d c0 13 4d 34 d3 40 c6 fe 47 71 d3 70 34 41 f0 1e 02 f6 fe 44 0d c1 d6 fe 1b f9 07 4c e0 23 78 0a fd 20 30 00 00 00 81 fb 07 f0 0f 01 0f 29 15 d1 0f 2f 06 f2 66 31 03 d1 8e b2 a4 eb 0b 04 a4 b2 95 f9 00 10 c9 01 b1 42 bc bf 70 1a 4f f0 00 09 09 db 89 1b a1 f6 f5 10 04 70 a6 f5 6e 70 00 88 a6 f5 6e 72 20 f0 0f 00 10 80 a6 f2 be 30 87 f8 50 93 3c 70 00 88 a6 f2 be 32 20 f4 40 60 10 80 81 f8 ff 9f 36 04 0f 04 00 01 05 04 04 03 0b 00 01 00 74 67 1a 0d 84 90 01 00 04 1b 03 01 00 05 04 0e 06 01 37 0c 00 01 00 04 13 05 01 01 00 01 00 02 01 20 0a 00 06 00 01 00 0a 03 02 00 02 00 02 01 20 10 00 0c 00 01 00 03 01 08 00 00 02 40 00 00 00 00 00 04 13 05 01 01 00 02 00 02 01 20 12 00 0e 00 01 00 05 02 0a 00 40 00 00 00 00 00 01 02 80 00 02 01 20 10 00 0c 00 01 00 04 04 08 00 40 00 00 00 01 02 00 01 04 13 05 01 01 00 02 00 02 01 20 21 00 1d 00 40 00 07 00 01 00 18 00 15 35 13 35 11 09 00 04 35 0c 35 03 19 01 00 35 05 19 00 03 08 04 00 04 13 05 01 01 00 01 00 02 01 20 0c 00 08 00 01 00 07 03 04 00 00 02 40 00 04 0f 04 00 01 11

I hope this helps...

Are you using the original software with a modification only to SDK_INQUIRY_LAP ?
From your previous post, i was of the opinion that the setup disconnected, but did not  "crash"  even while connecting to iPod Touch.

So, with this original setup, check if we reach the below line (sdk_handle_spp_connect_error();), in the beginning of the function appl_spp_notify_cb, under the below condition, after executing BT_hci_disconnect

if(API_SUCCESS != result) {
    BT_hci_disconnect(sdk_status[rem_bt_dev_index].acl_connection_handle, 0x13);
 >> sdk_handle_spp_connect_error();

}

At this point, please collect the dump of the arrays and variables i had mentioned earlier.

Put a break point at the switch case HCI_DISCONNECTION_COMPLETE_EVENT, in function sdk_hci_event_indication_callback,
in the file appl_cb.c.When you get to this point, you should see a message on the LCD: "ERR:RECONECT SPP".

After this if you continue executing, you should see the message "ACL Disconnected" on your LCD.

You will reach this stage if the lower layer connections in stack are not happening, either because of the MSP device or because of the iPod touch.

After this experiment, you could also try connecting from iPod touch to the MSP board and share your observations.

Oh, sorry, I misunderstood.  I did the previous test and data captures on my real target device, not the MSP Development platform.  I will collect the data again using the MSP Development platform.  I should be able to get the setup changed and the new data collected within the next few hours.

Okay, here is the new dump data that was collected when I hit the sdk_handle_spp_connect_error() call in the appl_spp_notify_cb function:

uart_tx_rd = 82

uart_tx_wr = 82

circular_buf_wt = 312

circular_buf_rd = 312

uart_tx_buf:

02 06 00 00 01 00 00 00 00 02 01 00 16 00 12 00 00 01 06 00 01 00 0d 35 03 19 11 01 00 30 35 03 09 00 04 00 02 01 00 0c 00 08 00 01 00 06 03 04 00 00 01 40 00 01 11 04 02 01 00 01 0c 04 06 74 67 1a 0d 84 90 01 2b 04 09 74 67 1a 0d 84 90 03 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 18 0c 02 00 32 01 0f 08 02 05 00 01 43 0c 01 01 01 47 0c 01 01 01 3a 0c 07 02 33 8b 9e 00 8b 9e 01 24 0c 03 14 28 00 01 2e fd 0d 01 2c 01 04 00 0a 00 00 00 00 00 00 00 01 82 fd 14 00 9c d0 d0 d0 d0 d0 d0 d0 d0 d0 da e4 ee f8 02 0c ff 00 00 01 82 fd 14 01 9c d0 d0 d0 d0 d0 d0 d0 d0 d0 da e4 ee f8 02 0c ff 00 00 01 82 fd 14 02 9c d0 d0 d0 d0 d0 d0 d0 d0 d0 da e4 ee f8 02 0c ff 00 00 01 87 fd 03 0f 0f 0f 01 76 fd 2a 01 21 54 61 57 14 05 0a 05 00 07 06 0a 04 05 08 09 0b 0c 0d 0e 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 01 80 fd 03 00 01 01 01 80 fd 04 3c f0 5f 00 01 01 04 05 33 8b 9e 0c 00 01 19 04 0a 33 c3 32 a1 0e 00 01 00 57 09 01 19 04 0a 74 67 1a 0d 84 90 01 00 0e 0b 01 19 04 0a 61 56 52 a1 f1 70 01 00 d1 63 32 01 05 04 0d 74 67 1a 0d 84 90 18 cc 01 00 0e 0b 01 01 37 0c 04 01 00 00 19 02 01 00 0c 00 08 00 01 00 02 01 04 00 01 00 40 00 02 01 00 0c 00 08 00 01 00 0b 01 04 00 02 00 01 00 02 01 00 10 00 0c 00 01 00 04 02 08 00 00 01 00 00 01 02 80 00 02 01 00 0e 00 0a 00 01 00 05

circular_buf:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 31 29 02 d0 00 30 33 04 0f 04 00 01 05 04 04 03 0b 00 01 00 74 67 1a 0d 84 90 01 00 04 1b 03 01 00 05 04 0e 06 01 37 0c 00 01 00 04 13 05 01 01 00 01 00 02 01 20 0a 00 06 00 01 00 0a 01 02 00 02 00 02 01 20 10 00 0c 00 01 00 03 01 08 00 00 01 40 00 00 00 00 00 04 13 05 01 01 00 02 00 02 01 20 12 00 0e 00 01 00 05 02 0a 00 40 00 00 00 00 00 01 02 80 00 02 01 20 10 00 0c 00 01 00 04 02 08 00 40 00 00 00 01 02 00 01 04 13 05 01 01 00 02 00 02 01 20 21 00 1d 00 40 00 07 00 01 00 18 00 15 35 13 35 11 09 00 04 35 0c 35 03 19 01 00 35 05 19 00 03 08 04 00 04 13 05 01 01 00 01 00 02 01 20 0c 00 08 00 01 00 07 03 04 00 00 01 40 00 04 0f 04 00 01 11 04 04 17 06 74 67 1a 0d 84 90 04 0e 0a 01 0c 04 00 74 67 1a 0d 84 90 04 31 06 74 67 1a 0d 84 90 04 0e 0a 01 2b 04 00 74 67 1a 0d 84 90 04 36 07 22 74 67 1a 0d 84 90 04 06 03 13 01 00 30 5f 30 36 5f 31 34 00 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

As you suggested, I put a break point in the switch case HCI_DISCONNECTION_COMPLETE_EVENT in function sdk_hci_event_indication_callback, in the file appl_cb.c.  I did hit the breakpoint and I did observe the text on the LCD that you described:  "ERR:RECONECT SPP".  When I let the debugger run again, I saw the "ACL Disconnected" message briefly, and then the display went back to the "CONNECT PEER" menu and continued to cycle between the BlueMSP-6774 name and the address for my device.

I cannot attempt to initiate a connection from the iPod Touch to the development board since the development board never shows up in the list of devices on the iPod Touch.  (Yes, I did have "Visible" set to YES on the development board while the iPod Touch was searching).

I cannot attempt to initiate a connection from the iPod Touch to the development board since the development board never shows up in the list of devices on the iPod Touch.  (Yes, I did have "Visible" set to YES on the development board while the iPod Touch was searching).

-This could be because the iPod touch and the MSP board belong to different CODs (Class of Device).Look into the file BT_assigned_numbers.h, and set the  SDK_CONFIG_COD in the sdk_config.h to an appropriate value for iPod Touch.

Will look into the memory dump, and try to spot the problem.

I've been doing some more digging into the interface requirements for Bluetooth devices and iPhone/iPod Touch devices given your question about the CODs.  There are a few requirements that I'm not sure are implemented as I could not find them clearly called out in the code or the documentation.  It appears to be a requirement that the Bluetooth Protocol Stack support the "Device ID Profile"?  I saw there were two constants in the BT_features.h file called DID_CLIENT and DID_SERVER but both were commented out.  Further, this was the only place I found those constants.

In addition, one of the documents I was looking through said that the "Bluetooth Core Specification v2.1 + EDR or higher" was required.  Does this protocol stack meet this requirement as well?

This article is a few years old but perhaps it hints at part of the problem?

http://www.popularmechanics.com/technology/gadgets/news/4272628

Yes, the Mindtree Bluetooth stack supports Bluetooth Core Specification v2.1 + EDR).

The Device ID Profile is not  a mandatory feature and hence it is not part of the stack that you are using.

Hi Chris,

     I see two issues you are facing:

1)  SPP connection failed with IPod Touch (IPhone is OK): From the Apple Support webpage (Updated on September 09, 2010, http://support.apple.com/kb/HT3647), I got the following:

Interestingly, the IPad and IPod Touch do not support the same profiles as the IPhone. Furthermore, the supported profiles by the IPad and the IPod Touch do not require the SPP profile as an underlying profile, but the IPhone does (i.e. HFP uses the SPP profile as an underlying profile). Therefore, I believe the issue is that the IPod Touch and IPad do not enable/support the SPP profile. An easy check would be to try to connect the IPod Touch and the IPhone using the SPP Profile.

2)  When porting the code to your board, the HCI_Disconnection fails (not seen with demo apps in TI platform): I noticed that you added couple of interrupt service routines to your program. Could you check that within those ISRs you have disabled the RTS at the beginning of your routines (UART_DISABLE_BT_UART_RTS();) , please? Also, please check that the commands to force a context switch if a Higher Priority occurs are in the ISRs? (if (xHigherPriorityTaskWoken)....). You can find examples of this in the user ISRs provided as part of the demo apps, i.e. TIMER1_A0_ISR, PORT2_VECTOR_ISR.

Please do let me know your findings.

~MS

Hi Miguel,

I'm still researching the Bluetooth connection requirements from the Apple MFi documentation that I have here that would make the our device discoverable by the iPhone/iPod/iPad devices.  So, I can't really comment yet on your point 1 from above.

With respect to your second point, I have not added the UART_DISABLE_BT_UART_RTS() call to all my ISRs yet.  However, none of my ISRs are being called at this point in the code.  My ISRs would only get invoked following a successful SPP connection when I needed to actually start communicating with the authentication co-processor to provide the apple authentication information.  The part about the xHigherPriorityTaskWoken yielding would only apply if my ISRs did something to one of the existing semaphores that was intended to trigger a task execution.  None of my new ISRs do this.

Chris.

I now have the device appearing in the search list for the iPhone/iPod Touch as a result of my modification to the SDK_CONFIG_COD value.  The device is obviously "not paired" yet.  The next step called out in the documentation that I have is that the device must look for a specific UUID in the iPhone or iPod's SDP record.  Further, I must set a specific UUID value in my SDP record.  Is there an example in the current demo code where this is done?  When is the iPhone/iPod SDP Record available?

Hi Chris,

     To look for a specific UUID in the peer device, you can use the BT_sdp_servicesearchattributerequest API. There is an example under the appl_spp_sdp_callback funtion in the appl_spp.c file.

      Regarding the second question, the current stack contains the supported local UUIDs already pre-compiled in the provided libraries. The user cannot modify them. Will this UUID be used for discovery purposes only? There is no protocol attached to it, correct?

Rgds,

Hello Chris,

        I will recommend adding the UART_DISABLE_BT_UART_RTS() line to your ISRs to avoid any problems in the future. You are right on the semaphores. Then you should be ok on this aspect.

       When you said that your code crashes when executing the HCI_Disconnection command, what is the specific behavior that you observed? Does it get stuck? If I understand correctly, the API does not even return the retval value, am I right? Have you checked if a HCI_Disconnection_Complete_Event response is received in the callback? The switch case for this event is part of the sdk_hci_event_indication_callback function in the appl_cb.c file.

Regards,

Miguel,

I modified the UUID in the section of code you pointed me to and then I set a break point on that code to see if it ever got executed.  In my situation, the code was never run.  So, to press on with the debug, and try to figure out the flow of things, I decided to attempt the pairing operation from the my iTouch and from my iPhone, both of which now discover the BlueMSP-nnnn demo board.  When I tried to pair with my iPhone, the HCI_DISCONNECTION_COMPLETE_EVENT was fired in the code and a message on the LCD of the demo board was displayed that said "SPP Connection from non BlueMSP device is not allowed".  So, I decided to try to connect with my iTouch (which I renamed to BlueMSP-6774).  Now, I still hit the breakpoint at the HCI_DISCONNECTION_COMPLETE_EVENT but the display only showed something like "ACL Disconneted" very quickly after I allowed the system to run from the breakpoint.  The iTouch displayed the message: "Pairing Unsuccessful 'BlueMSP-4D35' is not supported".

Do you know what section of code would be getting invoked in this demo when the iPhone initiates the pairing sequence?  There are so many callback functions and layers in this software, it is difficult for me to know where to look.  Just setting breakpoints at random sections of the code is not going to be a very efficient way to figure out how this whole system is supposed to work.

It is also interesting that on both my iPhone and iTouch, the result of the Bluetooth search yields a display where the device is shown as "Hands Free" briefly and then the name is replaced by the "BlueMSP-4D35".  So, there are some data transfers occurring here at some low level.

Miguel,

The apple documentation says that to communicate using it's special service, the accessory must establish an RFCOMM protocol connection to the iPod or iPhone.  The accessory must look for a specific UUID in the iPhone or iPod's Service Discovery Protocol record and the accessory must set a corresponding UUID value int its SDP record.  I cannot share the specific details of the UUIDs with you or any other specific information regarding names of services in this public forum as this information is covered under the MFi licensing contracts we have with Apple and must remain confidential.  This is one of the reasons why trying to resolve this issue in the public TI forum is somewhat cumbersome.  I need to be very careful with how much information I share so as not to violate our agreements with Apple.

Chris,

         There are many steps during the connection process. The first steps are at the HCI level and all the events are coming through the sdk_hci_event_indication_callback function in the appl_cb.c file. Keep in mind that not all the Events are defined by default on the example code. However, you can define the events you need to handle under the switch cases according to your application. After that, there may be some Security Manager messages, which are handled thru the sdk_sm_ui_notify_cb function the appl_cb.c file. Finally, the SPP level messages are handled through the appl_spp_notify_cb funtion in the appl_spp.c. Note that during discovery, the SDP messages come to the stack thru the appl_spp_sdp_callback function in the appl_spp.c.

      From your description, it looks like the iPod Touch is terminating the connection. This could be due to many reasons. Most likely, it could be because the desired UUID is not discovered. 

Rgds,

~MS 

Chris,

         As mentioned previously, the current stack does not allow changing the local UUIDs. We are working on it internally.

~MS

Hi Miguel and Chris,

Chris and I are actually in the same boat (working to interface Apple devices with this stack).  I'm really not an expert on the bluetooth protocol, but I believe that UUIDs can be exposed via the extended inquiry response records (EIRs).  I took a crack at this awhile back (and failed) and was pulled on to something else more urgent.  I plan to revisit this soon.

Do either of you believe this would be a valid place to declare UUID records (a place we can actually hook into for the mindtree stack) as opposed to trying to get certain entries into what seems to be a hard-coded SDP table?

Thanks

-Freddy

Hi Freddy,

I'm certainly no expert either.  I guess it is unclear to me how the EIR could be used to override entries in the SDP table.  If the Apple device is searching the SDP table for a specific UUID and comes up empty, I would think that the Apple device would give up and close down the connection.  I guess I don't understand what the relationship is between the EIR and SDP table.

Chris.

Chris, Freddy,

          The EIR is completely different from the SDP descriptors. They relate to different layers in the BT solution, HCI and SDP, respectively.

          As described in a previous post, the current stack does not allow changing the local UUIDs. We are working on the possibility to enable them on future releases. We will communicate our resolution soon.

           FYI, here are some useful links:

BT Standards: http://www.bluetooth.com/English/Technology/Building/Pages/Specification.aspx

 Our Developer's Guide: The MSP430BT5190+CC2560 Developer's Guide

Rgds,

Hi Miguel,

My apologies with not getting back to you on this sooner.  I've been tied up with various other items on this project.  What I was referring to was something that is in the bluetooth specification that you linked to.

8.1.1 Service Class UUIDs
A list of service class UUIDs (see Section 2.4, “Service Class,” on page 215)
may be included in the extended inquiry response data packet. There are three
types of UUIDs that may be returned: 16-bit Bluetooth UUIDs, 32-bit Bluetooth
UUIDs, and global 128-bit UUIDs. Each size is assigned two data type values.

Generic Access Profile
In addition to the size, the data type values also indicate if the list of UUIDs is
complete or there are more UUIDs available via SDP. An extended inquiry
response shall not contain more than one list for each size of UUIDs. If a
device has no service class UUIDs of a certain size the corresponding field in
the extended inquiry response shall be marked as complete with no service
class UUIDs. An omitted service class UUID list shall be interpreted as an
empty incomplete list.
The format of the data is defined in Section 18.2.

It appears that it may be possible to show that you support certain services in the EIR data, which I believe we can modify in the current stack.  I can't say for sure that this is sufficient though for the devices in question though...

Is there an any more information on the resolution?

Thanks

-Freddy

Freddy,

          The EIR should show supported UUIDs. There is a new release coming which permits modifying the local UUIDs.

Regards,

Miguel, 

 When will the new release be available? 

chico

Hi Chico,

      It is targeted for the next month.

Rgds,

I'm look forward to it.

Thanks!

  Chico

Hi Miguel,

Now that the stack is released, what documentation should we be be looking at to add new entries to the SDP tables.  I'm assuming we have to make modifications to db_gen.c and possibly db_gen.h.  Could you please point me at the proper documentation to get started?

Thanks

-Freddy

Hello,

I am looking for a connectivity with iPhone, So is this stack is different from the stack downloadable from TI site?

Can you sent me the path from where you have downloaded this stack?

Thanks,

Amol

Amol,

Connecting to the Apple devices requires additional resources for most Bluetooth profiles.   There are a few audio profiles that do not need Apple's authentication but all the rest of the profiles (like SPP) do for traditional Bluetooth.   Bluetooth Low Energy in now supported in new Apple devices (iPhone 4S, iPad3) and I've heard they have lifted the authentication requirements.  If you're trying to work with the older Apple devices you will need to join the Apple MFI (Made For iPod??) program to get access to the technical information and authentication IC.

The stack was updated to support the Apple authentication process but you may need the additional authentication hardware in your traditional Bluetooth device to use it.  What is needed depends on what version of Bluetooth, what profiles, and what generation of Apple devices you want to support.

HI George,

I have a similar question like Anmol. I have the mentioned chip and am able to pair with the apple device. I am having trouble with the following 2 parts:

1. Adding the UUID and local name in the EIR. I am able to add any one, but not both

2. Adding a new attribute list for the apple UUID in the SDP. I followed the instructions on page 139 of the guide, but I am not able to see any change on the traces. 

Is there any sample code to do this, or an updated guide?

thanks,

Umang