• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 130 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.

LAUNCHXL-CC26X2R1: How to locate the cause of the crash?

Nick Sun
Intellectual 2265 points
Part Number: LAUNCHXL-CC26X2R1

Hi team,

Here's the request from the customer:

The development board crashes after running for a period of time, how to locate the cause of the crash?

LAUNCHXL-CC26X2R1 with multi_role_CC26X2R1_LAUNCHXL_tirtos7_ticlang, SDK is simplelink_cc13xx_cc26xx_sdk_6_41_00_17.

Modified items:

1.Change the role to Observer, and open the GapScan_enable(0, 30, 3) after the case GAP_DEVICE_INIT_DONE_EVENT event is completed; Continuous scanning, and printing the scanned MAC and RSSI in the MR_EVT_ADV_REPORT event, after running for 3 minutes, it is stuck, similar to the crash phenomenon. (After removing the scan result printing, add the printing string to the timer (3S), but the printing in the timer in the subsequent hang-up also crashes, but it only appears after running for 90 minutes.) , suspect that the UART printing rate is too high and causes the crash? ）

2.Remove the official printing and interface, add own printing, modify the code as follows, Printf is to call the printing interface to the external task (single Task call)

Create a Uart task

Uart initialization

Task entity


To the externally provided print interface

Here's the project file:6747.multi_role_CC26X2R1_LAUNCHXL_tirtos7_ticlang.rar

Could you help check this case? Thanks.

Best Regards,                                                        

Nick

  • 0
    TI__Mastermind 30449 points

    Hi Nick,

    Thank you for reaching out. Based on your description, it does not seem like the application needs to use the multirole project. If they are implementing an observer role, then I would recommend starting with simple_central and modifying the project as needed. Can the customer try performing their changes on the simple_central project and verifying if the behavior is still present? Also, the 7.10 SDK was released some time ago, I would recommend the customer use the latest SDK at all times to ensure they have the latest bug fixes, features and optimizations.

    Best Regards,

    Jan

  • 0 in reply to Jan
    TI__Intellectual 2265 points

    Hi Jan,

    Customer changed to other project, but still printing for a while than crash.

    He wants to scan for a long time. Where should the function GapScan_enable(0, 0, 0) be called?

    What's more, the map file can locate the problem, so can this file be used to obtain the dump file after a crash? Or does the CC26x2 chip support viewing its stack (crash information) when it crashes?

    Best Regards,                                                        

    Nick

  • 0 in reply to Nick Sun
    TI__Expert 5150 points

    Hi Nick,

    First why customer want to scan for such a long time? Staying in scanning mode will consume a lot of power.

    Maybe prefer to do some period scanning to avoid this issue.

    Also make sure to call the function to scan at the right place, (check where it's called in simple_central) cause it could run into "out of memory" issue if you do not disallocate memory.

    To really understand where the crash comes from, please record some BLE traces with a sniffer, it will help a lot.

    regards,

  • 0 in reply to Guillaume
    TI__Intellectual 2265 points

    Hi Guillaume,

    Here's customer's further reply:

    As shown in the highlighted part, the system does not crash when the buf is Static, and it crashes when the static is removed. When it is a partial buf, it will not crash when the size is reduced to 32. Is it a problem with the chip stack management?

    case MR_EVT_ADV_REPORT:
    {
    GapScan_Evt_AdvRpt_t* pAdvRpt = (GapScan_Evt_AdvRpt_t*) (pMsg->pData);

    static int8_t buf[128] = {0};
    memset(buf, 0, sizeof(buf));
    snprintf(buf, sizeof(buf), "MAC: %s, RSSI: %d\r\n", Util_convertBdAddr2Str(pAdvRpt->addr), pAdvRpt->rssi);
    DoPrint(gPrintHand, "Discovered: %s", buf);
    if (pAdvRpt->pData != NULL)
    {
    ICall_free(pAdvRpt->pData);
    }
    break;
    }

    Best Regards,                                                        

    Nick

  • +1 in reply to Nick Sun
    TI__Expert 5150 points

    Hi Nick,

    Good to see that customer was able to run his application.

    Concerning the "chip stack management" I think it's related to continuous scanning, do they have the BLE traces as mentioned before? I need to have a closer look to the way they are scanning, it's possible that the device will run out of memory if they're not scanning properly.

    Regards,