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-Q1: The CC2642 device operating in host mode randomly triggers Hwi_excHardFault() exceptions

Part Number: CC2642R-Q1

Tool/software:

Subject: Watchdog Reset Issue with CC2642 Multi-Role Base Project

Hello, we encountered a watchdog reset while using the CC2642 Multi-Role as the base project for the CC2642.

Details of the issue:

  • We set up two advertising channels, each broadcasting at 100ms intervals.

  • After enabling scanning, the device connects to a peripheral once detected.

  • The connection lasts for 10 seconds, followed by a 2-second disconnection, then resumes scanning.

  • This cycle (scan → connect for 10s → disconnect for 2s → repeat) continues indefinitely.

At a certain point, this process triggers Hwi_excHardFault().

  • The longest test ran for 19 hours before failure.

  • The shortest failure occurred in just over 10 minutes.

  • Failures also happened at other intermediate times, making the issue appear random.

Follow-up Investigation:
I disabled the watchdog and ran the system in debug mode, waiting for the issue to occur. Upon each failure, I observed that the SP (Stack Pointer) value was consistently 0x20013A94.

Further Analysis:

  1. Checked the MAP file but found no reference to this address.

  2. Examined the memory window and confirmed that this address falls within the HWI (Hardware Interrupt) task stack.

  3. Monitored the stack usage of each task and tracked the memory poolno stack overflow or memory leaks were detected.

    • Memory leak verification: The allocatable memory size in the pool remained consistent between connection establishment and disconnection.

The SDK version we are using is simplelink_cc13xx_cc26xx_sdk_7_10_00_98

Below are some critical screenshots captured when the issue occurred:

 

All peripherals were verified to be properly initialized before use 

Could you please assist in troubleshooting this problem?

  • Hello,

    Thank you for your thorough explanation of the issue. I will try to reproduce this tomorrow.

    Details of the issue:

    • We set up two advertising channels, each broadcasting at 100ms intervals.

    • After enabling scanning, the device connects to a peripheral once detected.

    • The connection lasts for 10 seconds, followed by a 2-second disconnection, then resumes scanning.

    • This cycle (scan → connect for 10s → disconnect for 2s → repeat) continues indefinitely.

    Do you have a project that you can share for this? If not, do you mind providing some information on how you’ve implemented this scenario:

    1.  Are any drivers used? For instance, timers for the duration of the connection?

    2. Are there any other processes?

    3. How does the multi_role determine which peripheral to connect to?

    4. Are there any other active connections when this issue occurs?

    Best,

    Nima Behmanesh

  • Hi Nima

    Due to project confidentiality restrictions, I'm unable to share the complete source code. However, please find below the detailed implementation scenario:

    1. Task Architecture

      • Modified TI's multi_role reference project

      • Created a dedicated task with priority level set to one level below the main multi_role task

    2. Real-time Data Processing

      • Implemented a 1ms software timer within my custom task

      • Timer callback handles periodic:
        ‣ SPI communication with TCAN4450 CAN transceiver
        ‣ CAN bus data processing

    3. Peripheral Connection Logic

      • Target device selection:
        ‣ MAC addresses received via CAN bus data
        ‣ Forwarded to CC2642 host controller

      • Post-connection sequence:
        ‣ Immediately enables Notification by writing to CCCD

      • Connection duration:
        ‣ Actively disconnects after 10s using API call

    4. External Trigger Mechanism

      • External system sends connection commands at 12-second intervals

      • Current test environment:
        ‣ No other concurrent BLE connections

    5. Issue Characterization

      • Failure occurs randomly:
        ‣ May happen during active connection
        ‣ Or during disconnected state

      • No deterministic reproduction pattern

  • Hello,

    Have you been able to reproduce this on an unmodified multi_role example? With the second task doing data processing, and the 1ms interrupt, there may be some issues between the stack and the data processing.

    Because I can't match your project 1:1, I can still try to reproduce the issue, but it may not reproduce if it's not related to the BLE stack.

    Best,

    Nima Behmanesh

  • hi

    I can try to reproduce the phenomenon by adjusting the retry attempts in the example. Regarding the 1-millisecond trigger interrupt issue you mentioned - if there are indeed problems, I can attempt to adjust the timer to 5 milliseconds. This is the minimum interval requirement and cannot be extended any further.

    Additionally, have you tried running the example code on your end? If you observe any results, please share them with me.

    Additionally, I would like to raise another question, as illustrated in the diagram below.

  • Hello,

    I'm still looking into this and will need more time. Regarding your second question, I see you've attached a picture of the specification, but may have left out the question. What was your question?

    Best,

    Nima Behmanesh

  • Regarding the second question: My query is whether the functionality described in the diagram is supported in the CC2642 SDK. My understanding is that the diagram illustrates:
    "After a pairing failure, the same device cannot attempt pairing again for a specific time period; it must wait until the timeout expires. If consecutive pairing failures occur, the waiting time after each subsequent failure increases exponentially."

    What is the base value of this exponentially increasing time duration?

  • Hello,

    I apologize for the delay, I will need some more time to look into this, and will have a response by EOD Monday.

    Best,

    Nima Behmanesh

  • Hello,

    I apologize, I haven't had time to look into this at the moment. I will prioritize this next week to close these issues.

    Best,

    Nima Behmanesh

  • Hello,

    From what I see, the section you are referring to is for BR/EDR or Bluetooth Classic. I believe what does apply to Bluetooth Low Energy is captured in Vol. 3 Part H. In the case of a pairing failure, a connection would have to be re-established before initiating pairing again. 

    Best,

    Nima Behmanesh

  • Hello,

    I still haven't been able to reproduce this issue on my side. On the application side, what are you using to malloc and free memory? Are you setting the pointer to NULL after it's been free'd?

    Best,

    Nima Behmanesh

  • First Point: Regarding the Host-Slave Connection Entering Hardware Error Interrupt
    I think I've identified the issue.
    The problem likely lies in the MOVE function—it may cause an error when the length parameter passed to it is 0. After I added a check to prevent zero-length parameters, the system ran continuously for 48 hours without any issues.

    Second Point: Regarding the Content in the Image
    Can I confirm that the current SDK does not include the functionality shown in the image? Does this mean that reconnection is required to restart pairing, regardless of timing?

  • Hello,

    Yes that's correct. This functionality is not part of the Bluetooth Low Energy Controller, but is a requirement for classic Bluetooth. In Bluetooth Low Energy, the SMP timer is used, and if pairing does not finish/fails during after the SMP timer has triggered, then no pairing operations can occur until a new physical link is established. 

    Best,

    Nima Behmanesh