• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 486 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: getting the HW_FAIL_INADEQUATE_PKT_LEN error while running a data transfer test with the simple_peripheral example project

Henrique Nogueira
Prodigy 10 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK

Hi,

I'm running into the HCI hardware error `HW_FAIL_INADEQUATE_PKT_LEN` while running the "ble5_simple_peripheral_cc2640r2lp_app" (simplelink sdk v5.30.0-3).

In this case, the example project is slightly modified in order to test the max throughput capabilities of the system. The only changes I've made were to add support for `GATT_PROP_WRITE_NO_RSP` to one of the write characteristics, so that it can support the speedier unacknowledged writes.

To replicate the failure, I simply have to dump enough data from my central device (workstation running Ubuntu 22.04) - usually I'm consistently able to hit the error state by attempting to transfer 2MBs worth of data.

The only reference to this issue I've been able to find online is this bug report/ticket where the description indicates that the error occurs upon the reception of a fragmented L2CAP PDU, whereby something breaks upon receiving a 3-byte payload.

Upon sniffing the packets during the replication of this failure, I also observe that the last packet transmitted corresponds to the transmission of a 3-byte L2CAP fragment, equal to the one mention on the bug report.

So far, everything seems to be pointing towards an HCI software/hardware issue. Are there any known workarounds?

Henrique

  • 0
    TI__Genius 10935 points

    Hi Henrique,

    Thank you for posting on the E2E forums. I have assigned this thread to an expert.

    Best,

    Nima

  • 0
    TI__Mastermind 25810 points

    Hey Henrique,

    The issue you report should have been resolved in SDK 5.20+. Do you mind sharing your sniffer logs?

    Does this issue occur if you use other devices as your central?

  • 0 in reply to Ammar N
    TI__Mastermind 25810 points

    Hey Henrique,

    I apologize, I accidentally deleted your reply. I have received the information and will look into this further. For others reading the post, here is Henrique's reply:

    Hi Ammar,

    I'm attaching the sniffer logs, captured while replicating the issue. The failure happens at around packet number 11753.
    edit) It appears I'm unable to attach the pcapng sniffer log file straight, so I had to change the file extension name to "txt". Before opening the file, please change the file extension back to "pcapng".

    > Does this issue occur if you use other devices as your central?
    I have not yet tried to run the test on another workstation/machine.

    Thanks in advance!

  • 0 in reply to Ammar N
    Prodigy 10 points

    Hi Ammar,

    No worries! Thank you for looking into this matter Pray!

  • +1 in reply to Henrique Nogueira
    TI__Mastermind 25810 points

    Hey Henrique,

    Thanks for the logs. I saw the packet you mentioned. After looking into this, it looks like the fix for issue you linked was applied to our CC26x2 products and not on the CC2640R2 SDK.

    I've filed a ticket with RND to resolve the issue above for the CC2640R2 variants as well. Unfortunately, the fix for this issue is done in the link layer of the stack which is not open as it is provided as a library. This will be fixed in a future release.

    EDIT: The CC2640R2 device is quite memory limited when using BLE5 as the stack is not in ROM. Any fix to this issue if applied will take up more space from the user application. I would highly recommend looking into the feasibility of this part for your product. If BLE5 is a need, I would look at our CC26x2 (and onward) line of products. If further help is needed to find the right part, please reach our to a local TI Representative.

  • 0 in reply to Ammar N
    Prodigy 10 points

    Hi Ammar,

    > I've filed a ticket with RND to resolve the issue above for the CC2640R2 variants as well. Unfortunately, the fix for this issue is done in the link layer of the stack which is not open as it is provided as a library. This will be fixed in a future release.

    Is there a way I could track the status of this issue? Or is there some estimate on the timeline for the fix?

    > I would highly recommend looking into the feasibility of this part for your product. If BLE5 is a need, I would look at our CC26x2 (and onward) line of products. If further help is needed to find the right part, please reach our to a local TI Representative.

    Do you mean to say that, if the CC2640R2 is used, then the BLE4 stack is recommended instead?

    Thanks a lot for your support!

  • 0 in reply to Ammar N
    Prodigy 10 points

    Hi again,

    Just wanted to share a quick update. I tried running the benchmark test using the BLE-stack (instead of BLE5-stack), and hit upon the same problem.

    You mentioned that the BLE-stack is in ROM, or at least part of it... any chance this issue could be fixed there as well?

    Thanks again for your time!

  • 0 in reply to Henrique Nogueira
    TI__Mastermind 25810 points

    Hey Henrique,

    Henrique Nogueira said:
    Is there a way I could track the status of this issue? Or is there some estimate on the timeline for the fix?

    We do post open issues externally, but only after our RND team has done an initial analysis on the bug report. Unfortunately I can't comment on a timeline.

    Henrique Nogueira said:
    Do you mean to say that, if the CC2640R2 is used, then the BLE4 stack is recommended instead?

    If your application needs the memory (or if you'd like to use OAD), then yes I would recommend using BLE4 if BLE 5 is not a hard requirement.

    Henrique Nogueira said:
    You mentioned that the BLE-stack is in ROM, or at least part of it... any chance this issue could be fixed there as well?

    I've added the BLE-stack to the ticket as well for that to be looked at. If a fix is required for a function originally in ROM, the function is typically patched in flash since the ROM contents are not modifiable.