Bluetopia, SPP Mode Continuous Data Sending

Hello Naofumi,

What is the baud rate that you are using the device at? Can you also let us know the revision of the MSP430 chip that you are using? It should be on the top of the chip.

We know about this issue and are trying to reproduce it and are trying to find the root cause.

Best Regards,

Stonestreet One.  

Thank you for your reply.

i'm using the device at 115200 bps and the revision of the MSP430 chip is rev.D.

Naofumi.

P.S.

How can the device recover from the state in which data sending has stopped ?

Should I reset the hardware, reopen the SPP port or initialize the BT stack? 

Hi Naofumi,

See my post here http://e2e.ti.com/support/low_power_rf/f/660/p/218858/782348.aspx#782348

I have exactly the same problem but until now I didn't  found any solution...

Stonestreet please try to help us, we can't deliver any product as is.

Thanks

Mikael

Hi Naofumi,

We are suspecting that these issues are caused by a UART issue that the non Rev F and Rev H parts have. We have some Rev F parts now and we can verify if this is indeed causing the issue that you are seeing by comparing the behavior of the same code with different parts. 

I have also asked Mikael and would like to request you as well. We may have to get a sample binary/code from you that is able to reproduce this issue if possible. If not we will need some detailed instructions for reproducing so that we are sure that we are seeing the exact same issue that you are seeing and compare the behavior with different parts.  Last night we sent 100MB data from our Rev D to a windows SPP server and it did not show any error. So we may need your help to reproduce the exact issue that you are seeing.  Please let us know if it is possible.

Thanks,

Stonestreet One. 

Hi Stonestreet One,

I want to cooperate with you, but I can't give you my original source code. So please wait a little for remaking the code which I can show to you.

In addition, tell me in detail about a period to send data and a routine to call SPP_Data_Write in your test program.

Naofumi.

Hello Naofumi,

We wanted to check if you can send us a sample stripped down application/code that we can use to recreate the issue you are seeing. We are trying but are not sure if we are seeing the same issue. We will also need the steps you are taking on both ends to reproduce the issue. Any help would be greatly appreciated. 

We try to write data as fast as possible and when the function does not return the number of bytes that we tried to write, we wait for tPort_Transmit_Buffer_Empty_Indication in SPP callback and try writing the remaining data there. Whenever the write function returns bytes less than what we tried to write, it means the buffers are full and you have to wait for this event to retry sending more data.

Thanks,

Stonestreet One. 

Hi Stonestreet One, 

I'm ready to send you a sample code. How can I send you it ? There are about 4500 lines in that sample code made based on SPPDemo.c.

Naofumi.

Hi Naofumi,

You can send the sample code to us at support@stonestreetone.com

Thanks,

StonestreetOne.

Hello Naofumi,

Can you mail me the values you are using in HCITrans.c for

#define HCITRANS_RX_THREAD_STACK_SIZE 
#define DEFAULT_INPUT_BUFFER_SIZE 
#define DEFAULT_OUTPUT_BUFFER_SIZE 

#define XOFF_LIMIT 

#define XON_LIMIT 

Best Regards,

Stonestreet One. 

Best Regards,

Stonestreet One. 

Hi Stonestreet One,

the values are as follows:

#define HCITRANS_RX_THREAD_STACK_SIZE (450)
#define DEFAULT_INPUT_BUFFER_SIZE 512
#define DEFAULT_OUTPUT_BUFFER_SIZE 126
#define XOFF_LIMIT 128
#define XON_LIMIT 256

Best regards,

Naofumi.

Hello Naofumi,

Can you please change the values above to 

#define DEFAULT_INPUT_BUFFER_SIZE 128
#define DEFAULT_OUTPUT_BUFFER_SIZE 64
#define XOFF_LIMIT 32
#define XON_LIMIT  64

And let us know if you seen an improvement?

If that is still showing issues with reliability, please make sure that you are running the latest release and then make the changed to the values shown above. You may only have to change the XON_LIMIT.  The other customer who was having similar issues, had good results with these values in the release that they are running.

Best Regards,

Stonestreet One. 

Hello Stonestreet One,

I tried changing the values, but I couldn't solve the issues. In addition, I used a msp430F5438 Rev F chip and updated the Bluetopia_SDK to ver.1.3, but the results didn't change. Did you see issues in the source code which I sent before? Please let me know if there is anything I should do.

Best Regards,

Naofumi. 

Hello Naofumi,

We compiled the sample code you gave us but got an error of too few argumemts in function call when compiling Main.C in Line 182: HAL_Lowpowermode(); After commenting this line out and compiling we were able to test it against our windows sample app and managed to transfer data for about 3 hrs without any issues. We also ran several smaller tests sending data for about 20-30 minutes and the data was transferred without issues. We'll do some more testing on this but can you tell us about the remote device setup(the device that you are connecting to?).

Best Regards,

Stonestreet One.

Hello Stonestreet One,

I'm connecting to a windows desktop PC via a USB Bluetooth adapter dongle. The driver software of the Bluetooth adapter is the Motorola Bluetooth software Version 4.0.14.324. The Terminal program running on the windows PC and receiving the test data is Tera Term.

Best Regards,

Naofumi.

Hello Naofumi,

We are trying hard to reproduce the issue with your code but have not been able to so far after the changes described in Mikael's thread(That we mentioned earlier in this thread as well).  We are using default Baud rate and default config params. Today we will bump up the baud rate higher and try again. 

With the default setting:

We tested the sample code on a Rev-D MSP-430 and were not able to replicate the issue. We ran 5-6 tests where we would send data using Teststart for around 40 minutes. We also ran an overnight test where it was sending data continuously for around 14 hours. The MSP-430 was able to send the data without any issues. A IOGear Bluetooth 4.0 dongle with Teraterm Pro was the setup used to receive the data.

We will update with our tonight's test results tomorrow. 

Best Regards,

Stonestreet One.

Hello Stonestreet One,

I found one of causes of the communication issue. I could send data without any issues when I changed a Bluetooth receiver device. (I am using an Intel Centrino Bluetooth adapter and a Microsoft device driver instead of Buffalo Bluetooth dongles and Motorola device drivers) The driver software may be not good because  the communication issue occurred when I tried some Bluetooth dongles whose driver software were made by Motorola. The test result may change if you try changing the data receiver side.

Best Regards,

Naofumi.

Hello Naofumi,

It sounds like some receiver devices and stack may be closing the port after not being able to handle data for the time you are sending it. That would explain why the sending stops with PORT NOT OPEN error. 

This does not sound like an issue on our side.  Please let us know your comments.

Best Regards,

Stonestreet One. 

Hello Stonestreet One,

I doubted that a receiver device automatically sent a port close command. So I researched the Call Satck calling the SPP port close callback function.The left side of the following image is the Call Stack of the time sending manually port close command, and the right side is the time of the data send error. What do you think about this difference?

Best Regards,

Naofumi.

Hello Naofumi,

What I meant was the port close was triggered by the remote device. You are right, it is not an explicit port close but the remote device most likely has stopped responding. This results in the link supervision timeout getting triggered which in turn shows up as an HCI disconnect event with a timeout. This must be the HCI Event callback in the error case. Although it was triggered by an error, this looks like a graceful shutdown on our side. To confirm that, you can try connecting to another remote device in a clean state and we should be able to connect. We can also try to trap the HCI Event and see what the error code was in the error case. I will send you some code when I get in to work tomorrow so that you can register an HCI callback and print out if that was a disconnect event and what the reason was. 

Best Regards,

Stonestreet One