CC2640R2F-Q1: Connection issues on central (Multi Role based) after flashing new code to peripherals (Project Zero).

Hi Miguel,

Thank you for the detailed description. I had some additional questions:

- Can you please detail the specific hard coded defines you modified in the FW for the peripheral that caused this behavior to start happening?

- Do you see the same behavior (where you have to reflash the central to prevent the connection drop) when using the previous FW for peripheral?

- After reflashing, does the connection drop ever occur afterwards?

- It would be beneficial to get a sniffer log to see what is occurring when the connection drop happens.

Best Regards,

Jenny

HI Miguel,

The simple central and multi-role, works with simple peripheral example program.

-kel

Hello Jenny,

Jenny T said:

- Can you please detail the specific hard coded defines you modified in the FW for the peripheral that caused this behavior to start happening?

The changes were in the "DEFAULT_DISCOVERABLE_MODE" that was changed to Limited from General, "DEFAULT_DESGASTE_TIMEOUT" whis is the constant for timeout of my periodic task and a boolean flag that dictates wether the app goes to shutdown mode on disconnect. I dont think these are related to the BLE stack.

Jenny T said:

- Do you see the same behavior (where you have to reflash the central to prevent the connection drop) when using the previous FW for peripheral?

Yes, in fact, everytime I flash (FW update or just same FW) any peripheral that was or has been previously connected to this multi_role app I have to reflash the multi_role app for it to not drop connections to this recently flashed peripheral. I noted this because I was making some tests for another post I have in the forum and I started a debug session (which always flashes FW before starting) with one peripheral and the central started droping connections with this peripheral and only this one while having no problem with other previously connected but not flashed recently.

Jenny T said:

- After reflashing, does the connection drop ever occur afterwards?

After flashing central everything works as expected.

Jenny T said:

- It would be beneficial to get a sniffer log to see what is occurring when the connection drop happens.

Unfortunately, I don't currently have a way to get the sniffer logs. I'm planning to get one of the usb dongles that are capable of acquiring sniffer logs but I think they will get here (Chile) by mid January at least due to covid shipping issues and christmas/new year holidays 

Hi Miguel,

I apologize for the delayed response. Thank you for the detailed response!

I agree with you that these seem like it wouldn't affect the BLE stack. However, due to the lack of a sniffer log while we wait on shipping, can you perform a test to see if modifying the advertising on peripheral from limited to general advertising has an effect on this behavior? Similarly, is it possible to revert the periodic task timeout to see if modifying this value has an effect on the behavior?

The strangest behavior based on the description is that reflashing the multi_role FW which is untouched causes it to work properly.

If this is also reproduceable on the OoB examples (simple_peripheral and multi_role) with the 3 modifications you made to simple_peripheral, can you provide the exact modifications or source file(s). I can also try to reproduce it.

Best Regards,

Jenny

Jenny T said:

However, due to the lack of a sniffer log while we wait on shipping, can you perform a test to see if modifying the advertising on peripheral from limited to general advertising has an effect on this behavior? Similarly, is it possible to revert the periodic task timeout to see if modifying this value has an effect on the behavior?

Tried both these options and there was not change, the central showed disconnection and dropped the connection right after connecting a recently flashed peripheral.

Jenny T said:

The strangest behavior based on the description is that reflashing the multi_role FW which is untouched causes it to work properly.

I should be getting the USB dongle to capture sniffer logs later this week so I could be sharing them and hopefully will get and insight of what is happening.

Jenny T said:

If this is also reproduceable on the OoB examples (simple_peripheral and multi_role) with the 3 modifications you made to simple_peripheral, can you provide the exact modifications or source file(s). I can also try to reproduce it.

Will try to reproduce using OoB example and if getting same response I can handle all source files for you to have a look on them.

Hi Miguel,

As I have mentioned the multi-role works with simple peripheral example program. So you need make modify these example programs according to your requirements.

If you have 2 CC2640R2F Launchpad you can try how both example programs just to get familiar with them.

-kel

Hello Jenny,

I just got the Sniffer today and could successfully capture two sniffer logs, the first one was capture after flashing peripheral app, and since the central was not reflashed I managed to capture to connection events which resulted in disconnections. This is the sniffer log for this test:

Sniffer Log that shows 2 disconnections.psd

After that test I just reflashed central app with same FW, no changes at all, and run the sniffer again until I captured the connection event which after reflashing do connect succesfully with no problems at all. This is the sniffer for normal operation after reflashing:

Sniffer Log that shows connection success after just reflashing central.psd

Let me know if you see something that could point me in the right direction or if you need to have a better look at my FW or something.

Best regards and thanks in advance.

Hi Miguel,

I apologize for the delayed response. Thank you for providing these sniffer logs from recreating the issue. I am currently looking over them and aim to provide you with an update tomorrow. 

Best Regards,

Jenny

Hi Miguel,

Can you try disabling the DLE feature at runtime as described in the following section Disabling DLE at Runtime? https://dev.ti.com/tirex/explore/content/simplelink_cc2640r2_sdk_4_30_00_08/docs/blestack/ble_user_guide/html/ble-stack-common/link-layer-cc2640.html?highlight=dle#disabling-dle-at-runtime

Another thing to test, can you remove the boolean you added to dictate whether the app goes to shutdown mode on disconnect and see if this changes the behavior of Central terminating the connection upon first connection?

Thanks!

Best Regards,

Jenny

Just want to inform that the Project Zero will not work readily with Multi Role example program. There is no clear information that the Multi Role example program was modified correctly to connect and communicate with Project Zero.

-kel

Hello Markel, 

Thanks for the insight but unfortunately this app was developed from Project Zero because we encountered some problems while developing it based on Simple Peripheral and since we were starting using TI tools and getting used to the SDK by that time it was easier to use project zero features than to debug the problems that we had developing on SimplePeripheral. I might be able to start a new design process for a new version of the FW since we want to upgrade to BLE5 and also include some other functions and it that case I would definitely use SimplePeripheral but it wont happend for at least another whole month or so. Since I already have some field tests running on this FW and some other customer showcases planned, I would like to take all possible measures to close this issue before having to do a FW redesign.

Best regards,

Miguel Romero said:

Thanks for the insight but unfortunately this app was developed from Project Zero because we encountered some problems while developing it based on Simple Peripheral and since we were starting using TI tools and getting used to the SDK by that time it was easier to use project zero

A lot do that due to Project Zero is out of box demo and it's the example program used in SimpleLink Academy. The Project Zero is a demo example program and has its own application implementation much different from Simple Peripheral. The Simple Peripheral is the basic Bluetooth example program that is recommended in the forum to use and one reason is that works readily with other example programs such as Simple Central and Multi Role. There are other good reasons why Simple Peripheral is recommended. So, when people use Project Zero as base for their project or product development it's like what I call a pitfall. Often times developers need to redo everything using Simple Peripheral as base. I have done this a few times already so I know.

Miguel Romero said:

FW since we want to upgrade to BLE5

TI offers other TI BLE MCU that is recommended for BLE 5. It is not recommended to use CC2640R2F for BLE 5 since the BLE 5 Stack is big and you might encounter memory issues.

-kel

Markel Robregado said:

Often times developers need to redo everything using Simple Peripheral as base. I have done this a few times already so I know.

I think this will be my case but it will be handled as a FW version upgrade rather than a fix for the already developed.

Markel Robregado said:

TI offers other TI BLE MCU that is recommended for BLE 5. It is not recommended to use CC2640R2F for BLE 5 since the BLE 5 Stack is big and you might encounter memory issues.

I'm quite aware of this since right now our central based in Multi role is handling up to three peripherals connections simultaneously (max due to memory) and we want to upgrade to up to 8 or 12 as possible and for that I already ordered a few launchpads of the CC2642 and since the CC2642 is intended for BLE5 I might develop the new FW using BLE5 already.

Since we are talking about the CC2642 vs CC2640R2F, are they pin-to-pin compatible?, thus meaning that the HW already developed using CC2640 could be exactly the same for CC2642? Am I right? Does it need any different considerations?

Thanks in advance for the help and the insights.

Hello Jenny,

Jenny T said:

Can you try disabling the DLE feature at runtime as described in the following section Disabling DLE at Runtime? https://dev.ti.com/tirex/explore/content/simplelink_cc2640r2_sdk_4_30_00_08/docs/blestack/ble_user_guide/html/ble-stack-common/link-layer-cc2640.html?highlight=dle#disabling-dle-at-runtime

After doing this the problem of the disconnection seems to be solved, the central does not disconnect to any peripheral recently flashed. Thanks for the insight. Even though the app is working properly and so far haven't found any more issues regarding to the normal operation when I connect any peripheral that is DLE disabled the central shows a "Pairing Failed: error 08" message soon after starting a connection event. This seems to not have an impact on the operation. Is there any concern about the peripheral and central not pairing? They keep the connection working but not pairing.

Best regards and thanks in advance.

Hi Miguel,

Thanks for testing disabling DLE!

In regards to the error message that appears on the central, are you entering a passkey to pair or does this occur by default? If possible can you  provide a sniffer log of the central and peripheral when you see this error message please?

If you want to successful bond to store the Long-Term Keys, you will have to successfully pair to bond. If you do not require bonding, connection should be sufficient. Do you have pair/bonding enabled?

Best Regards,

Jenny