Other Parts Discussed in Thread: MSP430F5438A
Hello,
I am experiencing a vexing problem with the Stonestreet One Bluetopia
stack, v1.3, on an MSP430F5438A using the LSR TiWi-UB2 Bluetooth
module.
In this application the MSP430 is opening the stack as a SPP server
stack->serverPortID = SPP_Open_Server_Port(stack->bluetoothStackID, stack->sppPortNumber, SPP_Event_Callback, (unsigned long)stack);
and then waiting for a connection from the PC. After the PC connects
(as a master, and without pairing), the MSP430 begins streaming
continuous data to the PC at a rate of about 20 kilobits per second.
The PC Bluetooth dongle is about 3 feet from the TiWi-UB2 antenna, so
we should be getting close to full data rate out of the SPP
connection.
I am running a Bluetooth transmit "task" every 8 milliseconds via the BTPS scheduler
BTPS_AddFunctionToScheduler(TaskBTTX, &application, 8);
During the transmit task I am checking if all bytes of the previous
message was sent
if (bttxMessageState.bytesWritten == bttxMessageState.length)
and if so, I send the new message, saving the return value from
SPP_Data_Write()
{
...
bttxMessageState.bytesWritten = SPP_Data_Write(application->stack.bluetoothStackID, application->stack.serialPortID, bttxMessageState.length, (uint8_t*)&bttxMessageState.message);
...
}
If not, I try to send the rest of the previous message:
else
{
bytesToWrite = bttxMessageState.length - bttxMessageState.bytesWritten;
bttxMessageState.bytesWritten += SPP_Data_Write(application->stack.bluetoothStackID, application->stack.serialPortID, bytesToWrite, ((uint8_t*)&bttxMessageState.message + bttxMessageState.bytesWritten));
}
The problem is that, at some point, the SPP_Data_Write() function
begins returning zero all the time and I am never able to send any
more data.
This behavior is unexpected. I would expect, at this relatively low
rate (20 kbps), I could send data continuously without any problem.
One possible theory is that the master (receiver) buffer fills up
and that overflow is reflected back through the SPP interface to
the slave (transmitter). Does SPP operate this way?
Otherwise I am at a loss to explain this, and of course our product
cannot function this way. Any clues on why this could be happening
would be greatly appreciated.
--Randy
