This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bluetooth stack stops sending data

Other Parts Discussed in Thread: MSP430F5438A

The setup:

  • At the device side: MSP430F5438A, Buetopia V1.4, uBleu2 Bluetooth SIP Module.
  • At the PC side: Buetooth dongle, USB hub, windows application.
  • A UART  rate 460800 8N1 is used.
  • The Bluetopia code is from the SPPDEMO without any change.
  • I’m working without operating system

After a connection session and some commands run at the application level, an endless steam is generated at the MSP and sent to the windows application.

The stream is sent on packets of 260 bytes every 40 milliseconds.

In between every second, additional packet is sent and can be at variable length ans can reach the 1Kbyte.

There is no any hand shake at the application layer and the windows application does not send any data at this time.

 

The problem from user experience:

The windows application stops receiving data.

More details:

After a while, the SPP_Data_Write() return value is less than required.

At this time, as explained at the comments of this function, I stop try to send and wait for the etPort_Transmit_Buffer_Empty_Indication event.

But this event does not receive at all.

I’m using the SPP_Event_Callback() to catch the event. That set as a callback parameter when _open_server()  is called.

The BTPS_ProcessScheduler() is called from the main loop.

  • Hi,

    Our partner SSO is looking into it and provide feedback.

    Thank you,

    Miguel

  • I investigated it more and I have more details:

    I inserted some debug print:

    [Debug] LoadTransmitBuffer 90
    [Debug] LoadTransmitBuffer 90
    4 13
    5 1 1 0 2 0
    [Debug] LoadTransmitBuffer 90
    [Debug] LoadTransmitBuffer 90
    4
    13 5 1 1 0 2 0 2 1 20 9 0 5 0 42 0
    B FF 1 4 86
    [Debug] LoadTransmitBuffer 90
    [Debug] LoadTransmitBuffer 90
    [Debug] LoadTransmitBuffer 90
    [Debug] LoadTransmitBuffer 90
    [Debug] u8UartStat 25
    4 13 1 0 2 0 4 13 5 1 1 0 1 0
    2 1 20 9 0 5 0 42 0 B FF 1 4 86
    4 13 5 1 1 0 1 0
    [Debug] spp_send_data pause
    30

    explanation of the printout:

    [Debug] LoadTransmitBuffer 90 - message transmitted from the BT stack to the UART. 90 is the message length on hex.

    2 1 20 9 0 5 0 42 0 B FF 1 4 86  - the message as it received by the uart before receive to the BT stack. I beliave it the ack for the message sent.

    [Debug] u8UartStat 25 - the status register value on hex when ther is an error.

    [Debug] spp_send_data pause - a debug message means that the Spp_write_data received positive but less then required bytes.

    In addition there is a print out of buffer empty that did not print out.

    Note: The printout are from the main loop and not from interrupt handler.

    What we see:

    The transmission is OK till the time there is an error at the ack side.
    The meaning is that the system is not overcome error at the ack side.and the system is stuck.

    More details about the system:

    The UART used is UART 3. The meaning is the interrupt priority is lower.

    In addition I have UART 0 in massive use. Actually the message received by UART 0 is routed to BT stack.

    UART 0 works using DMA. The interrupt to re-arm the DMA to receive the next message is a little bit long.

    I will try to handle itto reduce the possibility of BT UART will receive an error. But it will not promise that it will solve it.

    Can you help me to improve the system so it will be robust and will overcome this situation?

    Thanks a lot...

    Itsik Hadar.

  • Itsik,

    If you are dropping packets on the Bluetooth UART there will be issues. You will have to fix this. The only way around that is if you use H5 (With CC2564B). 

    Regards,

    Stonestreet One.