Discconnect issue using Bluetopia with SPP profile

Hi,

Is your host baud rate same as chip baud rate? if so this should not cause any problem.

Do you have some logs that you can share?

Hi Sundeep,

Thank you for your reply, we change the buadrate after intialisation with the following command:

VS_Update_UART_Baud_Rate(BluetoothStackID, 9600);

Does this change both the baud rate on UART of the MSP and also of the PAN1326? Or do i need to change them speratly?

We have no logs, but i can generate some logs, what do you want to have logged?

Many thanks for your reply!

Hi,

This command only changes the baud rate of CC256x module. 

The default baud rate used for MSP in bluetopia is 115200, please check the Hal.c file

Logger logs along with the sniffer will help.

Hi Sundeep,

Thank you for your reply, i have looked in the hal.c file and found the following line:

#define BLUETOOTH_STARTUP_BAUD_RATE                              115200L

If we change this to 9600L would this resolve (maybe) our problem? By that i mean if we set te chip baudrate also to 9600?

Or how do we change the msp430 baudrate after the bluetooth initalisation?

Could you explain what you mean "with the sniffer?" How do we do this?

Hi,

I meant logger logs + air sniffer.

As far as I know, In file main.c,  in the function MainThread(), the below macro call will set the MSP430 side baud rate  HCI_DRIVER_SET_COMM_INFORMATION(&HCI_DriverInformation, 1, 115200, cpHCILL_RTS_CTS); 

Hi Sundeep,

With that macro you set the data struct with the driver information, am i right? The BSC_Initialize(HCI_DriverInformation, 0) uses this struct, does function also sets de baudspeed on the MSP side? Or which other function is responsible for this?

With a sniffer do you mean a separate packet sniffer device? Or a mode of the PAN chip?

Thank you for your reply!

Hi,

Yes we set the COM/Serial Driver Information in an HCI_DriverInformation_t structure, and after that we call InitializeApplication() which will call OpenStack() and that will intern call BSC_Initialize() and in BSC_Initialize we call HCI_OpenDriver() with these parameters.

Packet sniffer device.

Hi Sundeep,

Once again thank you for your reply! We found out that when we send rappid events (which are around 32 bytes in size) to our device(from our Android phone) and the device is handeling other events that this can cause a disconnect (we think). 

So when the device is handeling other intererrupt events from e.g. a sensor and then we receive several events via Bluetooth we get a disconnect. The communication direction from the phone to the device gets broken, the communication from the device to the phone is still alive.

Do you (or someone else) have a idea what this cause this? Can it be that the rx buffer is full and that this can cause a disconnect? The rx buffer and tx buffers have a size of 500 bytes and the dataframe size is 250.

Is there a way to reset the SPP connection when a disconnect happens? We have seen a function called  SPP_Send_Break(unsigned int BluetoothStackID, unsigned int SerialPortID, unsigned int BreakTimeout), can we use this to reset the connection in case of a disconnect?

Futhermore we have seen a function called. SPP_Line_Status(unsigned int BluetoothStackID, unsigned int SerialPortID, unsigned int SPPLineStatusMask), can we use this funciton to check the SPP connection status?

Unfortiatly we dont have a sniffer device, is there a model that you can recommend?

We are working on the logs, is there a way to use printf, to create console output?

Many thanks for your help so far!

Hi Sundeep,

After some more research we have resetted to the default rx and tx buffer size and also to the default maximum data frame size. All have now the value of 58 bytes.

We are curently running a long indurance test (just started) but we have no disconnect yet. Do you know of any problems when changing the sizes?

Hi Sundeep and others,

We have done a 1 day test and altough there where some disconnects we see that the connection is recoverd. This is with the default settings. But some times we see that the transmition from the device to the phone we see that some thimes the event is not recieved on the phone side (no disconnect when this happens). 

If we increase the TX buffer e.g.  3 times the maximum frame size will this have any effect? What is the general effect of using the default maximum frame size in stead of using a custom framse size of 250 (bytes)? Is there a reason why this causes a disconnect?

Hi,

I am checking this internally, I will update you once i have an update.

Could you please clarify, if you are referring to the uart tx buffer (BT_DEBUG_UART_TX_BUFFER_SIZE)  or tx buffer (DEFAULT_OUTPUT_BUFFER_SIZE) ?

Hi Sundeep,

Thank you for your reply and actions, what kind of logs do you want to see? On what places/actions? Today we are going to start a test with the following settings:

Framesize : 58;

Rx and TX buffer: 232 ( 4 times the frame size).

It is worth mentioning that or phone runs a app that uses both bluetooth and wifi at the same time, but think  this should not matter.

Many thanks for your help so far!

Hi Sundeep,

Just a follow up question, with SPP, can we send and receive at the same time? This is not possible right? Since it is a serial connection? And the data will be buffert and send or received when the other side has done sending/receiving?

When we use spp_write function, and send some data while the other side is receiving (earlier data) or sending, then the new data will be buffert right? And sent when the other side is done? Could this be causing a disconnect (when this happens a lot).

We tested with a the following settings:

Framesize 58;

TX and RX buffer 580.

This has the same result, we get a disconnect, this is not really a disconnect (no remote close port event) but one side, the phone or the device can't sent or receive the data anymore. The communication is broken in one direction: e.g. The phone can't send any data or the device can't receive any data.

Could a simultaneously send on both sides (or receive) be the problem? And could we reset this or break from this state? Or could it be an other cause?

Hi,

Logger and sniffer will help. 

As I understand we see a disconnection error is "remote close port", which seems like remote device initiating the disconnection. 

Usually we don't have to bother about what is enabled on the remote device. But To be on the safe side, to rule out the odds (like if the remote device has any issue, running WiFi and bluetooth together). You can try to reproduce with only BT enabled on the remote device. (Or) even before collecting the logs you can give it a try with a different remote device. 

HI Sundeep,

We don't see a remote close port event, but we see that the connection is still there(we get no close event) but the communication is broken in one direction. Do you know what the cause might be? 

UPDATE:

This morning we where checking which Bluetopia binarys we use, we saw that we use the defaultmtu library, in our case is it possible that using the largemtu binary that this will have a possitive effect on the connection?

Hi,

Ok, Do you have some logs you can share.

defaultmtu library is the correct one to use. I think we already had a discussion related to data model earlier see  http://e2e.ti.com/support/wireless_connectivity/f/660/p/368972/1313250.aspx

Hi Sundeep,

Thank you for your reply, that discussion was about large data model, not MTU size in relation to our problem. We are wondering if we should use the large MTU when sending larger data (framesize over 200 bytes).

Also what is the easiest way to generate logs? We where thinking about a console output, on code composer, is this possible? our is there a better/easier way?

Hi,

I dint think it is related to MTU size. Anyway if we can have the sniffer logs it will be easy for us to see what is going on between DUT and the remote device.

I have sent you a mail on how to capture the logger logs, I don't think the issue is with the module, but to make sure you can provide this firmware (logger) logs.

Hi Sundeep,

Thank you for the information we have passed it on to our superior, we will get back to you when we hear from him. We runned the same test today with a older bluetopia binary (1.4 R1 instead of 1.5 R1) and it runned for 5,5 hours instead of the normal 30 to 50 minutes. This is a much better result, we did not change the code only the the Bluetopia binary, and then a clean project build. 

Are there any SPP changes in the 1.5 R1 release that might explain this? We have just started the test again and we hope it runs longer again.

Also we saw that there are "service packs" for the PAN1326 chip, do we need to upgrade it? And how do we check the current version?

Hi,

That is strange, Bluetopia core library was updated with few fixes related to audio. But nothing specific to SPP.

How about using Bluetopia 1.5 R2?

If you are using PAN1326 then v2.14 is the latest version available, If you are using PAN1326B then v1.0 is the latest available. See http://processors.wiki.ti.com/index.php/CC256x_Downloads

In the file MSP430_Experimentor\Bluetopia\btpsvend\CC256X.h (or CC256XB.h), Depending on the chip and what you are downloading you can check what is the "BT SP" version.

Hi Sundeep,

We are currently starting a weekend test, that runs with the following parameters:

TX and RX buffers and maximum frame size: 250, we did a short test with this and it seems more stable. We will get back to you when we have the results.

Hi Sundeep,

Last friday we had started a test with the following parameters: 

TX, RX buffers and data frame size: 250. Today we got back at the office and we found out that the test was still running. It seems like that changing the parameters had a positive effect! Can you explain why this might be? I had looked at a troughput test that was done and found out that there where tests done with much greater sizes.

http://processors.wiki.ti.com/index.php/CC256x_MSP430_Bluetopia_Basic_SPPDemo_APP_Improving_throughput_v14

Is there any explanation why greater sizes don't run at our platform?

Hi,

It’s hard to tell. It shouldn't make any difference, but I would need to look at air capture + BT FW (logger) log to give you a better answer.

Hi,

I have received one additional input internally, may be it will help.

Do you know if the MSP430 gets stuck when this happens? It maybe that you did not reserved enough Stack or Heap memory.

Hi Sundeep,

When the connection is broken the MSP is not stuck, we still can sent or recieve events in the other direction. Could there be another cause? We are still running tests with the settings i mentioned earlier and so far we have seen no disconnect of broken connection anymore.

Hi Sundeep,

Last week we have runned a lot of tests with the new mentioned settings, so far we have not seen the disconnect and broken connection anymore. Still wondering why these settings work and others don't. We have not heard back from our supervisor about getting a sniffer or the log chip. Hope will get a reply soon, in the mean time do you have any other idea?

Hi Roy,

Without the logs no.