CC2564MODA: SPP issues on CC2564B / CC2564MODA using classic Bluetooth

Hello,

Please give me time to look into this.

Jesu

We are looking forward to your reply. This is somewhat urgent.

Hello,

I've ran the SPP example on an MSP432 and I don't run into problems. I noticed you made a comment about using an MSP430 in the past but now you are not. What host MCU are you using? 

Jesu

MSP430F5438A

Were you using service pack v1.8 for the CC2564B?

If there were a patch / service pack initialization problem, is it possible that pairing would work correctly but SPP would not?

We get no error when starting SPP server on other board using:

SerialPortID = SPP_Open_Server_Port(BluetoothStackID, 4, SPP_Event_Callback, (unsigned long) 0);

I'm not sure as of now. I'm trying to test the SPP example with an MSP430F5529 and CC2564B. I will need some time to setup HW and SW. Will get back to you ASAP.

Jesu

Hello,

I've having trouble bringing up the demo using MSP4305529 (I don't have 5438). I will try with MSP432 but the CC2564B version of the Bluetooth stack to work. In the mean time could you tell me if you have made any modifications to the SPP demo example?

Jesu

Yes, since this is our final product and not a breadboard, it does not have USB or other I/O necessary to run the demo, and the demo software is designed to be a demo, not a product (tons of "demo" baggage we don't want in a final product). So we traced through and extracted the calls from the demo and made the same sequence of Bluetopia calls as the demo did. Those for the client are stated above, in an earlier post. Those for the server are listed below, most of them being the same, except that at the end the server is initiated. A minor difference is we do not set HCI_LINK_POLICY_SETTINGS_ENABLE_SNIFF_MODE in the call to HCI_Write_Default_Link_Policy_Settings() since we do not enable this low-power mode. Though not shown below, each function's return value is checked for errors, and would break if an error occurred (none did). One other minor difference is that we used:

SPP_Register_Raw_SDP_Record(BluetoothStackID,ServerPortID,NULL,ServiceName,&SDPServiceRecordHandle);

instead of:

SPP_Register_Generic_SDP_Record(BluetoothStackID, ServerPortID, ServiceName, &SPPServerSDPHandle);

since SPP_Register_Generic_SDP_Record() is just a macro which inserts NULL as the 3rd argument of SPP_Register_Raw_SDP_Record().

Below is our actual sequence for the SPP server initialization:

BluetoothStackID = BSC_Initialize(&HCI_DriverInformation,BSC_INITIALIZE_FLAG_NO_SCO);

HCI_Register_Event_Callback(BluetoothStackID, HCI_Event_Callback, (unsigned long)NULL);

GAP_Set_Connectability_Mode(BluetoothStackID, cmConnectableMode);

GAP_Set_Discoverability_Mode(BluetoothStackID, dmGeneralDiscoverableMode, 0);

GAP_Set_Pairability_Mode(BluetoothStackID, pmPairableMode_EnableSecureSimplePairing);

GAP_Register_Remote_Authentication(BluetoothStackID, GAP_Event_Callback, (unsigned long)0);

SerialPortID = SPP_Open_Server_Port(BluetoothStackID,4, SPP_Event_Callback, (unsigned long) 0);

SPP_Register_Raw_SDP_Record(BluetoothStackID,SerialPortID,NULL,"Serial Port 4 Server",&SDPServiceRecordHandle);

It would be interesting to know whether, using the latest v1.8 service pack with a module using the CC2564B, and the library "libBluetopia.a" (CCS\DefaultMTU\coffabi) for Bluetopia  v1.5 R2, you are able to successfully connect a board configured as SPP client to a board configured as SPP server with no errors.

Hello,

I will need to consult our CC2564 about this. Unfortunately he has been OOO on holiday so this will have to be continued next week.

Jesu

Thanks for letting me know. We look forward to hearing from him as early as possible next week. Happy Thanksgiving.

Looking forward to hearing from you on this.

Hello,

Just to update you - I plan to meet with our CC2564 expert today. I will respond with his input near end of day. 

Jesu

Hello,

So because this was working before and it stopped working since you've added all your features, you might be experiencing some kind of side effect that does not allow the client to work properly. Our BT expert recommended you capture HCI logs to give us more insight as to what might be the problem. Unfortunately the error you're getting does not tell the full story so the HCI capture would give us a better idea if it is a problem with the client or the server.

Details on how to capture this can be found here. 

Jesu

Jesu, it has never worked using CC2564B with service pack patch file v1.8, which is what our product is now using.

It worked years ago using CC2564 (non-B) with a much earlier service pack, on an LSR TiWi-uB2 module, running on the MSP430F5438A experimenter board with Bluetopia v 1.3.

Have you been able to get SPP to work using the CC2564B (on a module such as CC2564MODA or CC2564MODN) with service pack 1.8, and Bluetopia v1.5 R2 MSP430 SDK?

Meanwhile, I will attempt to implement the full HCI logging per the document you referenced on our embedded product.

Thank you.

Jesu, upon reading the document you referenced, it states:

***

HCI Logging in the MCU Host Environment

Because of a lack of a file system and limited CPU processing power on the MCU, it is untenable to do
stack-level HCI logging in an MCU environment. This leaves two options for logging:
• External HCI/UART line sniffing with either Ellisys, Frontline, or custom probes
• Using data tracers with DWT/ITM on Cortex-M based MCUs

***

The HCI logs I sent you above logged all of the calls to HCI_Event_Callback(). Is this not good enough, because it does not log *ALL* HCI traffic?

Does the document state that stack-level HCI logging is untenable in an MCU due to RAM limitations? We have 16K of RAM in the MSP430F5438A, and most of the RAM not used by Bluetopia can be made available for this debugging. If RAM is the limiting factor, we could choose to log in stages, first the chip initialization (patch file service pack), then subsequent calls, a small number at a time.

In the Bluetopia v1.5 R2 MSP430 SDK would this be the correct function call to use to log ALL HCI activity?

BSC_RegisterDebugCallback(BluetoothStackID, BSC_DebugCallback, CallbackParameter);

where BSC_DebugCallback is a function prototype of type BSC_Debug_Callback_t

Please let me know:

1) If the HCI_Register_Event_Callback() will not log ALL of the HCI traffic that you need logged,

2) if the BSC_RegisterDebugCallback() WILL log all of the HCI traffic that you need,

3) if you have had any success getting SPP demo running on a CC2564B with service pack 1.8 using Bluetopia v1.5 R2 MSP430 SDK, using library libBluetopia.a under v1.5 R2\MSP430_Experimentor\Bluetopia\lib\CCS\DefaultMTU\coffabi. In the Service Pack v1.8 the conditional assembly  __SUPPORT_LOW_ENERGY__ and other sections were not compiled since we are not running LE, just SPP over classic BT.

You should not be concerned with RAM in regards to HCI logging because you will send it over UART externally. I'm not familiar with any limitations regarding HCI event logging - the log you get should suffice as the BT expert suggested.

We have logging tools that can be configured to receive this data. More details and documentation can be found in the link below.

http://www.ti.com/tool/WILINK-BT_WIFI-WIRELESS_TOOLS

Jesu

Jesu, thank you for your reply, but we already have logging firmware in place in our embedded system which allows us to capture all HCI events in HCI_Event_Callback(). For the SPP client they were shown above (see table near beginning of this post).  Is this not the list of HCI events which you require? If you need more data within any of those events I can supply it. For example, I could capture and return the Status byte for each of those events. However, all of those events (involved with pairing) completed successfully. The problem occurred AFTER paring when SPP_Open_Remote_Port() was called.

No HCI callbacks occurred at all after the call to SPP_Open_Remote_Port() was issued. Would we need to use BSC_RegisterDebugCallback() instead of HCI_Register_Event_Callback() to see all of the HCI activity?

SPP_Open_Remote_Port() returned 0xFFB8 = -72 which is BTPS_ERROR_RFCOMM_UNABLE_TO_CONNECT_TO_REMOTE_DEVICE. Is it possible that Bluetopia returned this immediately without any HCI activity?

Finally, in response to your earlier post, we only had SPP (in Classic Bluetooth) working on the MSP430F5438A Experimenter Board demo using a CC2564 (non-B) on a TiWi-uB2 module from LSR, using Bluetopia MSP430 SDK v1.3. We have never been able to get it to work using a CC2564B on a CC2564MODA using Bluetopia MSP430 SDK v1.5 R2, with the latest CC2564B service pack v1.8. Have you been able to get it to work on the latter?

Hello,

I have not had the capacity to get the MSP430 + CC2564B SP v1.8 working. Would it help if I focus on getting this working and providing you with specifics steps to get it up and running? I can try analyzing the HCI logs you provided and make some suggestions based on that but if ultimately you're just trying to figure out how to get SPP working with the latest SP on MSP430 I can just focus on that. Let me know since my e2e capacity is limited.

Jesu

Yes, that would be very helpful, since it would determine whether there is some problem in the version of library (Bluetopia MSP430 SDK v1.5 R2 COFF library file libBluetopia.a under v1.5 R2\MSP430_Experimentor\Bluetopia\lib\CCS\DefaultMTU\coffabi) or service pack (v1.8) or hardware (CC2564B) running classic Bluetooth SPP.

If you get it running, please recompile with the following NOT defined, or commented out to be sure they are not included in the service pack which is loaded to the CC2564B:

__SUPPORT_LOW_ENERGY__

__SUPPORT_AVPR__

In our version of CC256XB.h the above conditional compilations have been deleted to be sure they are not compiled. Please do this on both the server side and the client side. We first noticed a problem on the server side when other Bluetooth clients could not recognize that our SPP server was running and could not connect with it. Then when we put together the above MSP430 + CC2564B SP v1.8 as a client (by just changing a few instructions in the server version), we found that on the client SPP_Open_Remote_Port() returned error -72 which is BTPS_ERROR_RFCOMM_UNABLE_TO_CONNECT_TO_REMOTE_DEVICE, confirming the problem which the other SPP clients we were using had indicated.

Yes, it would be very helpful if you could construct an SPP server and client (especially the server) using the above MSP430 SDK library and service pack with a CC2564B. This would give us confidence that there no problem has developed in the recent library or service pack or something else which affects operation as a classic Bluetooth SPP server.

Thank you.

Hello,

Apologies for the delay. I was out of the office 12/5 and 12/6 because I was sick. I am going to work today with our BT expert to get this example working with the latest service pack. Will get back to you later. 

Jesu

Jesu, thanks for the note. I got sick 12/3, mild case of flu, but as of today have recovered and was out running again.

It is not critical what you use for the classic BT SPP client. What is critical is that your SPP server uses Bluetopia MSP430 SDK v1.5 R2 COFF library file libBluetopia.a under v1.5 R2\MSP430_Experimentor\Bluetopia\lib\CCS\DefaultMTU\coffabi with service pack v1.8 and CC2564B running classic Bluetooth SPP. We are using only classic Bluetooth (not LE), so the sections of the service pack for __SUPPORT_LOW_ENERGY__ and __SUPPORT_AVPR__ should *not* be compiled, to simulate our scenario.

What we would very much like to know is, can the SPP server using the above libraries/files be connected to by any SPP client, and serial data passed back and forth?

We only used a Bluetopia SPP client to connect to our server because we thought we might get more descriptive errors when the connection failed. We had previously attempted connection using other SPP clients unsuccessfully but with no useful error messages.

All clients we tested could successfully pair. They just could not open a remote SPP port on our SPP server. Something with the SPP server seems not right.

Thank you.

Hello,

I'm still having trouble bringing up the SPP example. After some time troubleshooting I gave up and moved to an older version of CCS. I'm now closer to running the example but it seems like some CCS files may be corrupt that looks up the device. Out of curiosity, what version of CCS are you using? I was able to get it working with MSP432 + CC2564B and SP v1.8. 

My bring issues aside....

I think at this points it's safe to assume there must be some compatibility issue with the latest service pack. Our release notes indicate the service pack is only tested for MSP432 and STM32. I also learned that some time ago we established a standard for defining service packs in regards to MSP432 and STM32. There is a possibility MSP430 might not follow this standard considering last time the MSP430 BT stack was updated long before the standard was established. I believe this aligns closely with the symptoms you've been seeing where you can get SPP working without the SP but run into problems with it - is this correct? 

To answer your question, I don't think SPP client/server compatibility is affected by which files you're using. As long as the SPP BT profile is supported, an SPP server should work with any SPP client. Additionally, BT profiles are backwards compatible by BT spec so it should even work if you have two different versions of BT running on a client/server. 

Jesu

Jesu, thank you for your thorough response.

To answer your question, we are still using an old version of CCS just because it has worked well for us and we have not had a strong reason to change, CCS 5.3.0. We had previously (years ago on the MSP430F5438A Experimenter Board) used Bluetopia SDK v 1.3 successfully with that CCS version, but for our final product decided to use the current SDK v 1.5 R2 since it might contain some bug fixes. We have Bluetopia v1.3 archived and can return to it if necessary (some rewrites will be required).

We did not think that the version of CCS would make a difference, since the version of the build environment and compiler should not affect Bluetooth functionality if there are no build errors. One bug we are aware of in CCS 5.3.0 (which persisted to much later versions as well) is not rebuilding dependent source files when an include file is edited. We force "rebuild all" after any include files are edited to overcome this.

Another question you asked is: "you can get SPP working without the SP but run into problems with it - is this correct?" The answer is no, we have not even tried to bring up the CC2564B without loading a service pack. My understanding is that a service pack must be loaded each time the CC2564B is taken out of reset. Should we try operating the chip without loading a service pack?

I agree that the SPP server should be compatible with any SPP client. We have tried a few different clients and none can connect to our current SPP server. Pairing goes smoothly, but after pairing, the SPP clients seem to hang for several seconds when trying to determine the capabilities of our device, and do not seem to recognize it as having an SPP server. When we created a Bluetopia SPP client for testing, it also paired with no problem, but after SPP_Open_Remote_Port() it returned the error -72 which is BTPS_ERROR_RFCOMM_UNABLE_TO_CONNECT_TO_REMOTE_DEVICE. We set up timer to measure how long it took to return this code: it returned it in 10.7 msec.

FYI, we are not using HCILL or eHCILL.

In anticipation that you might find a problem with service pack v1.8, we also tested service pack v 1.7 with the same result. We have never tested a CC2564B with Bluetopia prior to the current product (the MSP430 Experimenter Board tests used the original CC2564 in an LSR module, the TiWi-uB2). Is it possible that the MSP430 Bluetopia classic BT SPP server has never been compatible with the CC2564B? Or is it more likely that we have to try a version of service pack prior to v1.7? Or is it more likely that the incompatibility is with the Bluetopia SDK, that we should revert to a Bluetopia MSP430 SDK earlier than the current 1.5 R2, such as v1.3 or v1.4?

Summarizing, if you are unable to get the current Bluetopia MSP430 SDK v1.5 R2 and service pack 1.8 and CC2564B to run a Classic Bluetooth SPP server, I see 3 main reversion paths to try to find a functional Bluetopia MSP430 SDK SPP server:

1) Revert back to an older Bluetopia MSP430 SDK.

2) Revert back to an older CC2564B service pack/patch file (older than v1.7). We may need to get that from TI because we don't have one that old in our archive.

3) Revert back from a CC2564B-based module to a CC2564-based module (which is not recommended for new designs, but is still available).

Do you have any suggestions on which path(s) to try, or could you try some of them for us?

Thank you.

Jesu, this is becoming critical for us. Would you suggest we attempt to use the MSP430 Bluetopia SDK version 1.3 library, and rewrite our calls to conform with that earlier version?

I hope this is not a CC2564 vs CC2564B hardware issue.

Hello,

Please try the following. Since the format for the new service packs are different instead of trying to replace the old service pack with the new one - leave the old one in but replace the array contents of BasePatch with the array contents of BasePatch in the v1.8 service pack. The idea here is the new format may be caused some incompatibility issues with the old MSP430 examples. Let me know if you run into any problems. 

Jesu

Jesu,

We already only extract the contents of BasePatch array, and paste that into our own source file BasePatch array.

We already tried service pack v1.7, it did not work any better than v1.8. Are you suggesting I try an SP older than 1.7? If so, you will need to send it since it is not on the website.

Neither service pack v1.7 or 1.8 causes the SPP server to work. I know that both of those service pack versions load without any error.

I was going to switch to an older Bluetopia SDK, the libBluetopia.a library from v1.3.

Regarding service packs, we only load the BasePatch array anyway, not the LE or any other conditional sections.

Please let me know how to proceed.

Are you able to get assistance from the BT expert, in getting the SPP server to work on Bluetopia MSP430 SDK v1.5 R2? The call to start the SPPP server returns with no error messages, but nothing can connect to it, and any attempts to connect to it generate no callback events of any type.

Jesu, I have captured low-level HCI traffic by intercepting the routines which transmit and receive the HCI UART. The following hex bytes were transmitted from MSP430 to CC2564B over the HCI UART after our test client called SPP_Open_Remote_Port():

The following HCI UART hex bytes were then received back from the CC2564B:

The resulting return code from the call to SPP_Open_Remote_Port() was -72 which is:

BTPS_ERROR_RFCOMM_UNABLE_TO_CONNECT_TO_REMOTE_DEVICE

I will next capture HCI activity on the server starting when the client attempts to connect using SPP_Open_Remote_Port().

Will these logs be useful to you?

Is there a way that I could email you an Excel spreadsheet attachment if the result is too long to paste in here?

Hello,

I did not know you already copied the patch this way - never mind then. Please use our logger tool to capture HCI activity from our device. You can then save this file and attach it here.

Logger user guide

If you could HCI logs for both the server and client that would be perfect. If you need additional instructions on how to capture this please let me know.

Jesu

Also if you haven't already, download our wireless tools here. Use the BT logger application to capture the logs and save them to share here later.

Jesu

Jesu, we can probably rig up a 1.8V to RS232 adapter to connect to the TX_DBG pin on the CC2564B.  This should be connected (through level shifters) to the RX_Data line on RS232 COM port of PC (or USB/COM port adapter), correct?

There is no other physical connection necessary?

Is there any HCI call that must be sent to activate TX_DBG on the CC2564B, or is it always putting out data?

Both the "BT Logger" and "HCI/LMP viewer" should be connected to that same COM port? (TX_DBG thru level-shifter to RS232 RX_Data)?

We do not change the default HCI data rate from 115.2K. Is that the data rate which will be used by TX_DBG port, or is it higher?

Yes that is correct.

TX_DBG and common GND between the CC2564 and adapter. 

No, the CC2564B is constantly outputting data.

Yes but you can only do one at a time. https://processors.wiki.ti.com/index.php/CC256x_Logger_User_Guide

You cannot change the baud rate. It is 921600.

More details in link above. Let me know if you have anymore questions.

Jesu

We will be capturing some large log files later today. How can we get them to you, so that you and your BT expert can analyze? As attachments to these posts on e2e, or private message/email?

Hello.

You can attach them here. Please let me know if you have any questions or concerns about capturing logs as it is important for us to get good logs to diagnose the problem

Jesu

Attached is Logs2019-12-17.zip which contains log files and a Readme.txt explaining the contents of each file. The only option was to "insert file", hopefully that will attach this zip file.

Were you ever able to get SPP working on your setup using any version of the MSP430 (such as the MSP430F5438A) using the current Bluetopia SDK for MSP430 (which is v1.5 R2), and the latest CC2564B service pack v1.8? We have never been able to get this configuration to work. A few years ago we had a CC2564 (non-B) with Bluetopia v1.3 successfully running an SPP server, but our final product uses the CC2564B (on CC2564MODA) with the latest SDK and service pack, and we cannot get this to run SPP. It executes secure simple pairing with no problem, but won't run SPP. Our call to SPP_Open_Server_Port() always returns a valid positive SerialPortID, but nothing can ever connect to it.

Logs2019-12-17.zip

Hello,

Looks like you captured them correctly. We are reviewing your logs now. I did not get MSP430 working - the tool chain it depends on is very old and I kept on running into problems. I did work however with the MSP432 and latest service pack but this version is updated more than MSP430.

I will let you know what we find in a bit.

Jesu

Hello,

First thing, I made a mistake - you captured firmware logs instead of HCI logs. TX_DBG gives you firmware logs which is basically the controller. HCI logs are captured from the HCI_TX and HCI_RX lines. More details in section 4.1.2 here. 

Needless to say we still learned something... we reviewed the logs and don't see any problem on the controller level. Specifically from looking at the SPP_ServerBootThenClientOpenSpp.lgr which is where you described the error, we see connection and pairing occurs successfully among other things - no problem here. 

The next step would be to look get some HCI logs. We only need a log that captures the problem (we noticed you included others that work fine). If you could get it for both the client and server that would give us a lot of insight. This should be fairly simple - just need to wire some extra pins and run a script. All the steps are described in the document linked above. Let me know if you have any questions.

Jesu

Jesu, I followed the instructions in the last document you sent, installing software and hardware, and capturing the logs you said you needed.

Now you are saying you need something else. The document you referenced above makes general statements which refer to software I have never heard of:

"Custom probes can sniff HCI/UART TX and RX lines, and post process into a BTSnoop file format. The
reformatted BTSnoop data/log can be viewed with Wireshark, FTE, or the Ellisys HCI viewer GUI to
analyze."

I currently have the Logger application from WirelessTools-4.0.0.2-windows-installer.exe installed. Will this Logger have the BTSnoop file format you require? Do you require that we also get "Wireshark, FTE, or the Ellisys HCI viewer GUI"? (what ever they are)

Do you require monitoring and logging both HCI TX and RX, by tapping into them both?

Can the HCI TX and RX logs be created one at a time, or must they be be created simultaneously requiring that we order another UART level shifter-to-USB device?

Is there anyone at TI that can get the MSP430 Bluetopia SDK v1.5 R2 running on some type of MSP430 to test a CC2564B using classic Bluetooth SPP with service pack 1.8? If someone could just verify that this works it would save us all a lot of time.

Hello,

The logs are sent over the UART lines mentioned in that section. Wireshark, FTE etc.... is not required - it is just to view the captured logs. You just need something that can send the UART data to your computer so that the HCISniffer tool can capture the data and create a BTsnoop file. It is not necessary to capture the logs for both client and server at the same time. Assuming this problem is reproducible just capture one for the server - then repeat the steps and capture for the client. The logs should be the same.

You can download the .jar for the sniffing tool in the references section of the document.

Also, I will ask BT expert to try getting this example running tomorrow. He still has an old environment setup that should avoid the bring up issues I've been facing.

Jesu

Jesu, thank you for the reply. The document swpa234.pdf you referred to only mentions the MSP432 and CC2564C, not the MSP430 and CC2564B. It seems to be a high-level overview of various tools, without getting into many specifics. I think we will wait for your BT expert to take a look as you mentioned.

We will look forward to your BT expert running a classic Bluetooth SPP server on an MSP430 using MSP430 Bluetopia SDK v1.5 R2 talking to a CC2564B (such as on the CC2564MODA or CC2564MODN), with service pack v1.8. Don't care what is used for the connecting client -- the question is, can any client connect to and exchange data with that SPP server configuration?

Hello,

I was finally able to bring up the SPP demo for the MSP430. It seems like it works with old service pack. I will try with service pack v1.8 on Monday.

Jesu

Thank you Jesu. Yes, the final test would be to have the Bluetopia MSP430 SDK 1.5 R2 work with classic BT SPP using v1.8 service pack. Please let me know if you can make this connection and send or receive any bytes through it.

We are not even getting any SPP callbacks when such a connection is attempted from any client, much less any data bytes transferred.

We look forward to your results.