LMX9838 - Handling disconnection on active stream

Hi,

Your query has been assigned to a relevant LMX9838 expert. We will follow up soon.

Best regards,
Vihang

Hello Kari,

I will investigate your question and respond when I find more information.

In the meantime, is this an issue you are seeing on multiple systems, or are you seeing it on just one?

James,

This is happening on multiple devices.

brg

kd

The firmware in the modules 0212 (Patch 2).

Observation:
I have noticed that if:
1) I issue the SPP_ESTABLISH_LINK command for lp A and some remote end
2) Wait for the SPP_ESTABLISH_LINK CFM message from the lmx9838
3) Issue the SPP_ESTABLISH_LINK command for lp B and some remote end
Both connection issues will fail. I.e. The CFM message for the first command is not enough signal to start issuing further connection commands.
I must wait for the SPP_LINK_ESTABLISHED IND packet for the first connection before continue establishing connections.
This is not mentioned in the documentation.

Theory (question):
Should I block all other commands while I am waiting for the SPP_LINK_ESTABLISHED IND packet after having issued SPP_ESTABLISH_LINK command?
Is it possible if I do not do that, i.e. wait for the SPP_LINK_ESTABLISHED IND packet before shipping more commands that this is
triggering the crash of the lmx9838 chip?
Are there any other cases similar to this where a command triggers some internal processing in the lmx9838 and the lmx9838 returns and CFM packet for that command but is in reality not ready to accept other commands?

brg
kd

Hi Kari,

I received a response from one of our Bluetooth experts. I have copied it below. Does this help you?

I simulated this situation using 3 LMX9838 dongles. One of them worked as a master, creating the connections to two others working as slaves.

If one of the slaves disconnects then the message about link being lost is sent to the host after a link timeout which default value is 20s, equal to 0x7D00 (32000) slots of 625us. The link timeout can be  set in the range of 0x0190 – 0xFFFF slots. If data are still sent over broken link during this timeout period then two SPP_SEND_DATA are confirmed as performed but there is no confirmation to the third command:

 

Tx: Cmd: Send Data, Local Port: 01, Payload Data: 54657374 [first command with confirmation]

Rx: Event: Send Data, Status: 00, Local Port: 01

Tx: Cmd: Send Data, Local Port: 01, Payload Data: 54657374 [second command with confirmation]

Rx: Event: Send Data, Status: 00, Local Port: 01

Tx: Cmd: Send Data, Local Port: 01, Payload Data: 54657374 [third command without confirmation]

Rx: Event: ACL Terminated, BdAddr: 04778CE80010, Reason: 08 [link timeout passed so link broken information is sent to the MCU]

Rx: Event: Link Released, Reason: 02, Local Port: 01

 

If there is no confirmation to a SPP_SEND_DATA command, MCU shall wait and not send any other commands to the LMX9838 until link broken indication is received. When this happens the LMX9838 flushes all the data that it was not able to send on the broken link. It means that any data sent to the broken port during its timeout period shall be resent after the link is restored.

The LMX9838 reset may occur if the MCU does not observe handshake (RTS and CTS) lines and sends the data to the LMX9838 while it cannot handle them

Thank you James.

I am using RTS/CTS flow control which according to the documentation should not be necessary when not in transparent mode.
Granted that new commands can only be issued after CFM packet is received for previous command.
I have taken great care and verified that this is the case, i.e. I do not issue new commands until CFM is received.

Anyways I have restructured my code in such a way that also block new commands until the IND packet (SPP_LINK_ESTABLISHED after SPP_ESTABLISH_LINK command and SPP_LINK_RELEASED after SPP_RELEASE_LINK command) is received.
This seems to cure the problem. I do have a timeout (for 1 link timeout) on this wait though since it seems (I have to investigate further) that the IND packet is not always delivered.

My conclusion is therefore that there is an issue with issuing commands in the time windows after receiving the CFM for either SPP_ESTABLISH_LINK or SPP_LINK_RELEASED and receiving the corresponding IND packet.

Can you confirm this?

Kari,

Here is our expert's response:

The LMX9838 uses RTS/CTS all the time. If you will continue sending commands while the module is still busy performing the ones received earlier it will at certain point toggle RTS. The same works for CTS so it will not send anything to the MCU if CTS blocks the communication. Normally if you use command mode properly and you wait for the result of a command before issuing the next one, RTS will stay active.

 

The change in the code described is correct. The CFM after REQ_SPP_ESTABLISH_LINK is the confirmation about the command being understood and initiated. The link however does not exist until IND_SPP_LINK_ESTABLISHED is sent by the LMX9838. The same is true for REQ_SPP_RELEASE_LINK.

James,

Unfortunately I was too quick to report success.
This is still happening......

From our BT expert

 

Two basic things that must be done:

1.       Use hardware RTS/CTS handshake lines to prevent transmission when the LMX9838 is not ready.

2.       For all the commands that ends with an indication confirming the command was performed (like e.g. REQ_SPP_ESTABLISH_LINK) always wait for the indication before sending the next command.

 

I believe these conditions are fulfilled now but just want to state them clearly again.

 

I think that Kari still has a problem when one of the links is broken on the remote side. If this happens the master is informed about link being released after a timeout that default is 20s. If Send Data commands are issued during this period then a lockup may occur.

 

Again I used 3 LMX9838 modules to test it. My Master uses local port 1 and 2 (MLP1, MLP2) to talk to remote port 1 on Slave 1 (S1RP1) and remote port 1 on Slave 2 (S2RP1). Master has Event Filter set to 0x00 to report all the events.

In both scenarios I reset Slave 2 to break the link to simulate the error condition. The link to Slave 1 is always active. The listings below present the SB Commander master logs after the slave 2 is reset and its link is broken.

 

Scenario 1 – during the timeout the data are sent only to slave 2.

Slave2 reset

Tx: Cmd: Send Data, Local Port: 02, Payload Data: 54657374

Rx: Event: Send Data, Status: 00, Local Port: 02 [confirmed but not transmitted]

Tx: Cmd: Send Data, Local Port: 02, Payload Data: 54657374

Rx: Event: Send Data, Status: 00, Local Port: 02 [confirmed but not transmitted]

Tx: Cmd: Send Data, Local Port: 02, Payload Data: 54657374  [not confirmed because two internal buffers in the LMX9838 are full, MCU must wait here]

Rx: Event: ACL Terminated, BdAddr: 04778CE80010, Reason: 08 [ACL link broken]

Rx: Event: Link Released, Reason: 02, Local Port: 02 {SPP link broken]

 

In Scenario 1, if I connect to Slave 2 again the links work correctly.

 

Scenario 2 – during the timeout the data  are sent to slave2, slave 1 and slave 2.

Slave2 reset

Tx: Cmd: Send Data, Local Port: 02, Payload Data: 54657374

Rx: Event: Send Data, Status: 00, Local Port: 02 [confirmed but not transmitted]

Tx: Cmd: Send Data, Local Port: 01, Payload Data: 54657374

Rx: Event: Send Data, Status: 00, Local Port: 01 [confirmed and transmitted]

Tx: Cmd: Send Data, Local Port: 02, Payload Data: 54657374

Rx: Event: Send Data, Status: 00, Local Port: 02 [confirmed but not transmitted]

Tx: Cmd: Send Data, Local Port: 02, Payload Data: 54657374  [not confirmed because two internal buffers in the LMX9838 are full, MCU must wait here]

Rx: Event: ACL Terminated, BdAddr: 04778CE80010, Reason: 08 [ACL link broken]

Rx: Event: Link Released, Reason: 02, Local Port: 02 {SPP link broken]

 

In Scenario 2, if I try to reconnect to Slave 2, the command is not confirmed by the LMX9838 and it remains locked despite the fact link to slave 1 exists. It looks that the radio transmitting path of the master is locked.

 

My proposal in case a link is lost is to issue reset command to the master just after Link Released is received, wait for the link timeout to expire and reconnect to both slaves.

There is an application note (attached) that is included in the set of documentation on TI LMX website that describes the internal buffers of the module. I found the cases when some of the numbers like sizes of the buffers did not completely match the test results but I think in general it presents the internals of the module.

 

SB_UART_AN.PDF