Reconnect fails after disconnection was provoked

Hi Andreas,

I have a couple questions about your setup. When this failure occurs, the BLE master is in a connection with a slave and is scanning for other devices. The BLE connection is broken and then problems are seen in the SPI connection.

How are you terminating the BLE connection?
Is there any other BLE activity after the SPI connection is dead? Do you have a sniffer capture of this scenario?
Do you see the undefined behavior on the MISO line in other cases, not just the case where the device fails?

Hi Rachel,
I remove the slave so far from the master until the connection breaks.
I will provide a sniffer capture of this Scenario in the next days.
We didn`t see the undefined behavior on the MISO line in other cases.

best regards
Andreas

I've recorded the Scenario with a Frontline sniffer.

How is it possible to upload the files?

Hi Andreas,

Please see the following guide for help on attaching a file to an e2e post: https://e2e.ti.com/group/helpcentral/w/e2e/148.4-5-attaching-a-file

Hi Rachel,

in the attached files you can see the behaviour before and after the reconnection fails.

161103_Recon_Fail.zip

Hi Andreas,

I only see one connection event in your sniffer capture so it looks like everything is hanging after the connection is broken. Could you attach your full logic trace from your first post?

I attempted to recreate this scenario using HostTest and SimpleBLEPeripheral. I formed a connection between the 2 CC2541s, started another scan and powered off the peripheral. I was able to reconnect to the peripheral after powering it back on. Does the failure you see occur every time you disconnect from a device in the middle of a scan?

What firmware are you running on the BLE master device? Did you make any modifications to the CC2541 SPI driver?

Hi Rachel,

the failure happens in 95% of reconnection courses.

we use in the BLE master- and slave-device the TI-stack version 1.4.0.

In the attached file "SPI_modifications" you can find a file where the modification are described and the orginal and the modified source file.

I`ve also attached the full logic trace of a failure scenario.

At pos. "1" the BLEmaster (SPIslave) sends a Connection lost message.

Ar pos. "2" the SPImaster sends the reconnect-request to the SPIslave (BLEmaster).

6253.Recon_Failed.zip

Hi Rachel,

sorry I forgot the file with SPI modifications.

3603.SPI_modifications.zip

Hi Andreas,

Thank you for sending those notes and the full logic trace. I want to make sure that I am understanding the logic capture correctly:

At pos 2. the SPImaster (SPI2_MOSI) sends the reconnect request successfully. Then, shortly after, the BLEmaster(SPI1_MISO) starts toggling without a clock. However, even after this happens, there are periods of time where both sides do seem to be sending data properly. Are you sure there is nothing but the SPI communication happening on these pins?

You mentioned that you are using BLE Stack v1.4.0 on both CC2541 devices but what firmware are you running on them? Did you start with an example project?

You may want to consider updating your BLE SDK version to BLE Stack v1.4.2. There were some improvements to the SPI driver made in recent releases. We have a porting guide available on our BLE wiki page: http://processors.wiki.ti.com/index.php/LPRF_BLE_Porting_Projects   

Hi Rachel,

below you will find the answers to your last post.

- We are sure that the application Software of the BLEmaster doesn`t affect the MISO pin. (The toggling of the MISO pin doesn´t always occur when the  Reconnect Error occurs.) 

- We don't start with an example Project.

- An update to the BLEstack v1.4.2. we want to carry out if we know that thereby the REconnect Problem is fixed becaue the effort for a new series release is too large.

In the following I would inform you about our last Debug results:

If the System runs correct every time when a SPI message was received the function "spiCB((HAL_UART_SPI - 1), g_fcsCorrect) (line 776 file: _hal_uart_spi_modified.c) will be  called. (The function will be called also if chksum is not correct) 

If the "Reconnect-Error" occurs the function "spiCB" is not called. 

Consequent the reconnect message won`t be send on the BLE Radio.

What can be the reason why the function "spiCB" is no longer callled?

  

Hi Andreas,

I've numbered my follow up responses in the order of your responses above to make sure everything is covered.

1. Interesting. How often does the Reconnect Error occur with the MISO pin toggling vs without? Are you able to consistently reproduce the MISO behavior?
2. Not starting from an example project like HostTest is going to make it a little more difficult for me to reproduce.
3. That is understandable. Since I haven't been able to reproduce your issue, I can't confirm this would solve your problem or not. We can continue down the path we're on until we are certain the update would help.

New question from your most recent debugging results:

4. The only reason I can see that spiCB would not be called is if it was NULL. What is the value of spiCB & g_fcsCorrect in the fail case?

Hi Rachel,

we think we have found the cause for our Problem that the "Reconnect" message ist not processed by the CC2541.

I`ve attached a screenshot on which the SPI behaviour during "RECONNECTION" is shown.

I call the upper Picture as pic1 and the lower Picture as pic2.

In pic1 you can see the behaviour when 1 BLE-slave is linked.

In pic2 you can see the behaviour when 3 BLE-slaves are linked.

The Debug-Signal P1_0 is a DigOutputPin of the CC2541. The pin toggles in different sequences depending on which sofware parts are called.

 

Description of pic1:

Mark1: SPI-Slave (CC2541) sends "Connection Lost"-message

Mark2: SPI-Master sends Ack-message

Mark3: SPI-Master sends "Reconnect"-message

Mark4: Decryption of Pin1_0 shows that the Software processed the Ack-message

Problems of pic1:

1. The Ack-message is only processed after the "Reconnect"-message has been sent.

2. The "Reconnect"-message is not processed by the software

Reaction of the CC2541 Software:

1. CC2541 sends no "BLE-Reconnect" message.

 2. Reconnect Fails.

Description of pic2:

Mark1: SPI-Slave (CC2541) sends "Connection Lost"-message

Mark2: SPI-Master sends Ack-message

Mark3: Decryption of Pin1_0 shows that the Software processed the Ack-message

Mark4: SPI-Master sends "Reconnect"-message

Mark5: Decryption of Pin1_0 shows that the Software processed the Reconnect-message

Reaction of the CC2541 Software:

1. CC2541 sends  "BLE-Reconnect" message.

 2. Reconnection is successfully finished.

Question:

Why does the CC2541 SPI Software behave differently depending on how many BLE-slaves are linked?

Actual Workaround:

we've implemented in the SPI-master a delay-time after the Ack-message was sent.