• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 53 subscribers
  • Views 400 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2640R2F: Connection timeouts after simultaneous transfer from master and slave during same connection event

Attila Szilagyi
Prodigy 10 points
Part Number: CC2640R2F


Hello,

We're switching from simplelink_cc2640r2_sdk_1_30_00_25 to simplelink_cc2640r2_sdk_3_30_00_20. Using the previous stack when there was a simultaneous transfer from central and peripheral we were getting faulty data from the stack so we couldn't recognize the higher layer message and simply didn't handle it (but on the air it looked OK). On the newer stack we get faults that are visible on the air. Not every connection event with simultaneous transfer causes issues but when an issue happens it is usually soon after such connection event. And that gets in a way when sending larger amounts of data.

I'm attaching 2 capture files sniffed from air with bookmarks:

  • New_stack_disconnection_1.cfa: bookmarks mark beginning of sending of our protocol packets with a sequence number (hence 'AA', 'AB', 'AC' in this log). Issue is visible between frame 32661 and 32665 (first advertising frame after 2s of silence). In this case stack on central reported that disconnection happened because of LL_STATUS_ERROR_CONN_TERM_DUE_TO_MIC_FAILURE (value from ll.h, via GAP_LINK_TERMINATED_EVENT).
  • New_stack_retry.cfa: only 2 bookmarks marking start of 'CA' message confirmation and a frame decoded as slave but being in master’s place and carrying data from master. Starting with frame 67398 master is resending same chunk for 2 seconds. In this case disconnection reason was reported as LL_STATUS_ERROR_CONNECTION_TIMEOUT

capture_files.zip

Is this something I can avoid by configuring the connection in a different way?

Plus we don't have this issue when we wait with sending the confirmation from peripheral util we stop receiving data from central (so when only one side is transferring data at one time).

Best regards,

Attila Szilagyi

  • 0
    TI__Mastermind 42320 points

    Hello Attila,

    I have assigned an expert to help you with your query. In the meantime, you may find the migration guide available for the CC2640R2 useful. I have linked them below.

    BLE Migration Guide

    BLE5 Migration Guide

    Regards,

    Jan

  • 0
    TI__Guru**** 171224 points

    Attila,

    Please apologize for the delay; there was a snag on the notification system and I missed your post.

    I am having trouble downloading the Frontline software from Teledyne, therefore I will try to get and analyze your logs early next week.  

    A few questions: are TI devices being used in both Central and Peripheral? If so, are they both running the SDK3.30 or a mix between SDK 1.30 and 3.30?

    Also, do you think you could try to experiment migrating to the newest 4.40, as many bugs and performance issues were improved over the years?

    Regards,

    Rafael

  • 0
    Guru 86755 points

    Hi Attila,

    There is a big change in stack from SDK 1.30 to SDK 3.30. So, I suggest you evaluate the base example programs at SDK 3.30 such as simple peripheral. Then append or add your application code "simultaneous transfer from central and peripheral", then evaluate and test.

    -kel

  • 0 in reply to desouza
    Prodigy 10 points

    Thanks Rafael, I have no problem with this delay. Migrating from 1.30 to 3.30 already took us quite some time. I can propose migrating to 4.40 but it won't be my decision if we do.

    Both devices in air sniffs are TI CC2640R2F, both using the same 3.30 stack.

    Regards,

    Attila Szilagyi

  • 0 in reply to Markel Robregado
    Prodigy 10 points

    Hi Markel, the old applications were based on simple peripheral and central from 1.30 stack. The new ones were made around simple peripheral and central examples from 3.30. But I think that is a good idea if I could run vanilla simple peripheral and central and just add things i need to push the data through and see if I end up with similar situation. I'll see if I will be able to do this in the mean time because I'm also occupied by other parts of our projects.

    Regards,

    Attila Szilagyi

  • 0 in reply to Attila Szilagyi
    TI__Guru**** 171224 points

    Attila,

    I was finally able to download and install the Frontline SW and can see the disconnect due to the loss of sync on the encryption keys (the first error) and the second retry/timeout error.

    I tried a few simultaneous data transfers here but I couldn't necessarily see any specific errors but, as you mentioned, these do not seem to happen very frequently and therefore I might need some additional testing to see if anything could be found. I am using 4.40, but more testing would need to be done. I will get back to this investigation on Tuesday.

    Regards,

    Rafael

  • 0 in reply to desouza
    Prodigy 10 points

    Rafael,

    Thanks for checking the logs. Right now it is important for me if you could verify that this is an issue in 3.30 stack. We had a decision to pause further development in wait for this. Also we won't be allowed to move to 4.40 unless it fixes something important for our project (like this simultaneous transfer). Plus we are struggling with amount of available memory so we may have problems if the new stack requires more of it.

    To test it I was sending over something like 7-11 MB file, but usually it fails quite soon. Plus we send messages and wait for response in pairs, so simultaneous transfer happens only when first message in pair is being confirmed during reception of the second message. Maybe that information could be useful for you.

    Regards,

    Attila Szilagyi

  • 0 in reply to Attila Szilagyi
    Guru 86755 points
    Attila Szilagyi said:
    the old applications were based on simple peripheral and central from 1.30 stack

    Did you use BLE5 Stack at SDKv1.30? So, this new ones using SDKv3.30, do you use any BLE5 features?

    Back then I did a CC2640R2F based product using SDKv1.40 BLE5. But, there was no smart phone that was BLE5 capable back then. There was no RF testing house that can qualify BLE5 based product. So we say our product is BLE5 capable. But actually is more of a marketing gimmick.

    -kel

  • 0 in reply to Markel Robregado
    Prodigy 10 points

    No, we don't use any BLE5 features, neither in old (1.30 based) nor new application (3.30 based). And for now we used cc2640r2f devices on both sides of connection (both with same version of the stack too).

    Regards,

    Attila Szilagyi

  • 0 in reply to desouza
    Prodigy 10 points

    Hi Rafael,

    Did you find anything new with this issue. Have you tried reproducing it with 3.30?

    Best regards,

    Attila Szilagyi