• State TI Thinks Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 426 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.

CC2642R: Stack reports hardware error

Martin Reichelt
Prodigy 230 points
Part Number: CC2642R
Other Parts Discussed in Thread: BLE-STACK

Hi,

I have a application based on the multirole example with SDK 5.10. In very rare cases when a Samsung Galaxy S8 smartphone is connected as a central device and writes data to a characteristic, the BLE-stack reports a hardware error with error code 0x8c which is HW_FAIL_INADEQUATE_PKT_LEN.

The Samsung Galaxy S8 supports BLE 5.0. The connection uses DLE with length of 251 Bytes, ATT MTU is negotiated to 251 Bytes.

The S8 sends 52 Bytes data via ATT write command but the attribute callback isn't called for this messag and after that the hardware error is raised.

The BLE record with an Ellisys BLE Tracker shows me a conspicuous behavior. Only one Link-Layer packet would be necessary for the data transfer, but 2 packets are used (a retry was also necessary for the first packet). The first packet consists only of 2 bytes data and this is only L2CAP header data length field (0x0037 = 55 Bytes -> 52 Bytes ATT payload data + 3 Bytes ATT Header). The second Link Layer packet contains 57 bytes of data: the remaining 2 bytes of the L2CAP Header (the Destination CID 0x0004 = ATT), the ATT Header (3 Bytes) and ATT Payload (52 Bytes).

Is this the reason for the hardware error?

  • 0
    TI__Mastermind 42290 points

    Hi,

    I have assigned an expert to help with your query. In the meantime, I have a few questions that may be helpful in resolving this issue as efficiently as possible. Are you able to observe this on other devices or just the specified android device? You mention that this occurs in very rare cases, do you have an estimate of the frequency? (once every 5 minutes? once every 10 minutes?) Does this behavior occur in every connection eventually or on some connections?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 230 points

    Hi Jan,

    I've observed this particular error code only on the mentioned device so far and very rarely, maybe 1 in 10 connections or rarer, but I can't really name it. Mostly in cases where the smartphone has sent a lot of data.

    With the smartphone Google Pixel 5 I've observed the error HW_FAIL_PKT_LEN_EXCEEDS_PDU_SIZE (0x8B). But right now I can't provide any BLE log for this.

    I've found this bug ticket https://sir.ext.ti.com/jira/browse/EXT_EP-10433?page=com.atlassian.streams.streams-jira-plugin%3Aactivity-stream-issue-tab. In my case the connection isn't terminated.

    In general, do you have information if it's necessary to do some special handling for a specific hardware error, for example to reset the BLE stack? Or can I ignore the errors without that the BLE stack crashes? Per default the asset handler is called and results in a spinlock.

    Thanks for your support.

  • 0 in reply to Jan
    Prodigy 230 points

    I have an additional question for the bugticket https://sir.ext.ti.com/jira/browse/EXT_EP-10433?page=com.atlassian.streams.streams-jira-plugin%3Aactivity-stream-issue-tab:

    What has been fixed? That the BLE-stack doesn't run into the hardware error anymore or that the BLE-stack still can't process messages with fragmented L2CAP header but the connection isn't terminated anymore? In my case the connection isn't terminated although we use the BLE-stack 2.02.01.00!

    I've adapted the assert handler that it doesn't run into the spinlock for this hardware error code and the BLE-stack still works after it has reported the hardware error.

  • 0 in reply to Martin Reichelt
    TI__Guru** 101460 points

    Hi,

    Thank you for reaching out. The description of your issue is pretty close to EXT_EP-10433 (also called BLE-AGAMA-3297). As you have mentioned, in your case, no disconnection is issued, but this is the only difference. (Side note: when looking closer to the issue - using some details available internally only - it looks like the disconnection occurs because of the spinlock)

    EXT_EP-10433 has corrected the issue caused when by this particular packets fragmentation preventing the error HW_FAIL_PKT_LEN_EXCEEDS_PDU_SIZE (0x8B) to occur.

    I would recommend to migrate to a newer SDK (SDK 5.40 is currently the newest) and see if it resolves your issue.

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    Prodigy 230 points

    Hi Clément

    thanks for your response. I will check it with the new SDK.

    Best regards,

    Martin

  • 0 in reply to Clément
    Prodigy 230 points

    I'm a bit confused by your answer: HW_FAIL_PKT_LEN_EXCEEDS_PDU_SIZE is already fixed but maybe not HW_FAIL_INADEQUATE_PKT_LEN, which is also caused by the packets fragmentation? So is the main issue with the packet fragmentation during the L2CAP header fixed or not?

    Additonally: How should hardware errors, reported by the BLE-stack, be handled in general? HW_FAIL_INADEQUATE_PKT_LEN and HW_FAIL_PKT_LEN_EXCEEDS_PDU_SIZE can be ignored because the BLE-stack will keep working. But there are a lot of other hardware failures that can occur. How to proceed with them? Is the BLE-stack able to recover from all hardware errors and the application can just continue or is a reset necessary?

  • 0 in reply to Martin Reichelt
    TI__Guru** 101460 points

    Hi,

    Please refer to the ticket for further details: EXT_EP-10433.

    There is no general guidelines when receiving Hardware Failure Status. Actually, we cannot guarantee the stack can continue the execution without a reset. In other words, I encourage you to test these scenari and assess if, in your specific case, the reset is required or not.

    I hope this will help,

    Best regards, 

  • 0 in reply to Clément
    Prodigy 230 points

    The link doesn't work for me

  • 0 in reply to Martin Reichelt
    TI__Guru** 101460 points

    I have updated the link

  • 0 in reply to Clément
    Prodigy 230 points

    Ok this is the link we already talked about ;-) However, there is no information about whether the stack can now handle the fragmentation of the L2CAP header.

  • 0 in reply to Martin Reichelt
    TI__Guru** 101460 points

    Hi,

    I guess both HW_FAIL_PKT_LEN_EXCEEDS_PDU_SIZE and HW_FAIL_INADEQUATE_PKT_LEN errors could be raised because of the header fragmentation. For the conditions we have tested, none of these errors occur.

    I'll let you run the tests you need to assess if the issue is solved or not when using the newer SDK.

    Please don't hesitate to comeback to us afterwards.

    Best regards,