In this zip file you will find the log file names listed below, with their explanations. In all cases TX_DBG was monitored on the CC2564B on the SPP server. First the SPP server device was logged by itself, then when connection was attempted by an SPP client (also running MSP430F5438A Bluetopia SDK v1.5 R2), and then by a commercial USB dongle made by "Plugable" which supports SPP and RFCOMM. In all cases the log starts from the beginning of the deassertion of nSHUTD and the loading of the (v1.8 CC2564B) service pack. Our SPP server uses the CC2564B on a CC2564MODA.

General notes:

We used the TTL-232RG-VREG1V8-WE to connect RXD to the TX_DBG pin of our CC2564B (on a CC2564MODA), and used the current version of Logger (5.0, installer file WirelessTools-4.0.0.2-windows-installer.exe), as described in:
https://processors.wiki.ti.com/index.php/CC256x_Logger_User_Guide

The ServerPort argument in our function call:
SPP_Open_Server_Port(BluetoothStackID,ServerPort,SPP_Event_Callback,CallbackParameter)
is the integer 4.

The Bluetooth device address of our SPP server's CC2564B is (hex):
98:07:2D:37:B6:29


Log files:


File SPP_ServerBoot.lgr:
Our SPP server device (CC2564MODA) boots, but no clients attempt to connect. No mention of any SPP or RFCOMM information is made in this log (or any of the other logs), yet the SPP_Open_Server_Port() always returns a valid positive SerialPortID (here and in the following logs).


File SPP_ServerBootThenClientPairThenClientOpenSPP.lgr:

After server boots, CC2546MODA client connects and completes secure simple pairing, then after several seconds client attempts to open SPP port on the local CC2564MODA server. After several more seconds the client CC2564MODA is turned off, then after a few more seconds the server CC2564MODA is turned off.

This is the first attempted connection for the client, so it must complete secure simple pairing first (which it does successfully), then client attempts to open SPP port using SerialPortID = SPP_Open_Remote_Port(). That function returns error code -72 = BTPS_ERROR_RFCOMM_UNABLE_TO_CONNECT_TO_REMOTE_DEVICE. However, see below for what appears to be successful connection.


File SPP_ServerBootThenClientOpenSPP.lgr:

Similar to above, except link keys are found and re-used so re-pairing is not necessary. For some reason the same call SPP_Open_Remote_Port() on the SPP client now succeeds and returns a valid SerialPortID value "2". If this is repeated (again not re-pairing, re-using same link keys) it succeeds again and returns the next higher integer ("3").


File SPP_ServerBootThenPlugableClientPairedAndInquired.lgr:

A commercial USB dongle made by "Plugable", which supports SPP and RFCOMM, intiates pairing and successfully pairs with our SPP server. However, when it attempts to "control" (inquire what our device supports, and offer buttons to connect a service), it hangs for about 20 seconds, then comes up with a nearly blank window which does NOT show SPP/serial port capability.


Final thoughts:

Were you ever able to get SPP working on your setup using an 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.
