CC2640R2F: My application is getting stuck at HAL_ASSERT_SPINLOCK default case

Hey Rohit,

I apologize for the delay, we're all coming back from the holidays here.

Can you summarize what application level changes were made? More specifically, at what interval does the device scan/advertise? Is there anything you do that makes the issue more reproducible?

It would help if you can provide some steps to reproduce the issue, although I understand some issues are truly intermittent and hard to reproduce.

Hi Ammar,

Thanks for the response.!!

// Scan parameters
#define DEFAULT_SCAN_DURATION 130 ///4000
#define DEFAULT_SCAN_WIND 208
#define DEFAULT_SCAN_INT 208

and scanning happens once in 1200 msec,so for every 1.2sec for 130msec it scans and for rest of the period it will be off.

and device will be not advertising when scanning is turned on ,so i have 2 different slots for advertising and scanning ,for 15 seconds it will be 

continuously in scanning mode,in which for every 1200msec once it will scan for 130msec like this till 15 seconds it will be scanning and later 

for next 15sec it will be in advertising mode for 15 seconds with 100msec advertising interval.

so when device is in scanning state it will scan for available devices and connect to device with specific name and send all the data and when device is in

advertising mode other 2640R2F will connect to this advertising device and send the data.and  same repeats over the time.

after few hours of continuous operation it enters spin lock.

nothing else it does apart from this.  

Regards,

Atul

Hey Atul,

There's a few things we can try to narrow down the issue. Are you testing on custom HW or on a LaunchPad, I would recommend testing on a LaunchPad first.

A few further debug steps I would follow are to:

• Try seeing the impact of increasing the rate at which you scan/advertise (i.e. switch every 5 seconds instead). If it's a memory related issue, the device should enter the spin-lock faster, making it easier to reproduce.

Rohit Karekar said:

connect to device with specific name and send all the data and when device is in

• Does the issue only happen when connecting to the other device? Try removing this step and strictly scan/advertise to see if the lockup occurs without a connection.

Additionally, can you provide application code showing how you are enabling/disabling scanning/advertising?

Rohit Karekar said:

I am using SDK4_20_00_04 from that multirole example from blestack(4.2),and CCS 9.3.0,

Based upon the backtrace in the Debug view, the problem is that the multi_role_processStackMsg() function has received a HCI_BLE_HARDWARE_ERROR_EVENT_CODE (albeit the line numbers reported in the backtrace don't seem to match simplelink_cc2640r2_sdk_4_20_00_04).

You can verifying by selecting the multi_role_processStackMsg line in the backtrace in the Debug view and see if at the following:

          case HCI_BLE_HARDWARE_ERROR_EVENT_CODE:
            AssertHandler(HAL_ASSERT_CAUSE_HARDWARE_ERROR,0);
            break;

If so, see Decoding Hardware Error Reason for how to get more information on the cause.

Hi Ammar,

There's a few things we can try to narrow down the issue. Are you testing on custom HW or on a LaunchPad, I would recommend testing on a LaunchPad first.

• Yes i am testing on custom hardware ,Okay will check again on launchpad for same.

Try seeing the impact of increasing the rate at which you scan/advertise (i.e. switch every 5 seconds instead). If it's a memory related issue, the device should enter the spin-lock faster, making it easier to reproduce.

• Yes i have started testing by disabling connection and reducing the window to 5 sec for Scan/advertise i will update you the results soon.

       Additionally, can you provide application code showing how you are enabling/disabling scanning/advertising?

• Below is the code for your reference:

code to maintain window for scan/advertise switch:(timer runs with 1 sec period)

if(five_seconds_wait==0)
{
        five_seconds_wait_count++;
       if(five_seconds_wait_count>=5)
      {
             five_seconds_wait_count=0;
             five_seconds_wait=1;
             if(device_connected==0)
            {
                turn_on_advt();
            }
     }
}
if(five_seconds_wait==1)
{
       five_seconds_wait_count1++;
       if(five_seconds_wait_count1>=5)
       {
            five_seconds_wait_count1=0;
            five_seconds_wait=0;
                 if(device_connected==0)
                 turn_off_advt();
         }
}

code to start scanning: each second this will be called when scanning is on

          uint8_t i;

for (i=0;i<DEFAULT_MAX_SCAN_RES;i++)
{
          devList[i].addrType=0;
          devList[i].eventType=0;
          memset(devList[i].addr,0,GATEWAY_DATA);
}
// Start or stop discovery
if (linkDB_NumActive() < maxNumBleConns) //if we can connect to another device
{
      if((!scanningStarted)&&(ten_seconds_wait==0)) //if we're not already scanning connecting_state
      {
           scanningStarted = TRUE;
           scanRes = 0;
           GAPRole_StartDiscovery(DEFAULT_DISCOVERY_MODE, DEFAULT_DISCOVERY_ACTIVE_SCAN, DEFAULT_DISCOVERY_WHITE_LIST);
     }
    else //cancel scanning
    {
         GAPRole_CancelDiscovery();
         scanningStarted = FALSE;
    }
}

code where we stop scanning:

    case GAP_DEVICE_DISCOVERY_EVENT:

           scanningStarted = FALSE;

break;

void turn_on_advt()
{
       uint8 initialAdvertEnable = TRUE;
       GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t),
               &initialAdvertEnable, NULL);
}
void turn_off_advt()
{
        uint8 initialAdvertEnable = FALSE;
       GAPRole_SetParameter(GAPROLE_ADVERT_ENABLED, sizeof(uint8_t),
              &initialAdvertEnable, NULL);
}

Regards,

Atul

Hi Chester Gillon,

okay i will verify this time i have added breakpoint in the case you have mentioned i will update after reproducing the issue with the results. 

Regards,

Atul

Thanks for the feedback. I'll run this by the team internally and will wait for your results in the meantime.

EDIT: If you haven't taken a look at our Simplelink Academy Modules, I would highly recommend doing so here: https://dev.ti.com/tirex/explore/content/simplelink_academy_cc2640r2sdk_4_30_01_00/modules/blestack/ble_scan_adv_basic/ble_scan_adv_basic.html#advertising-task-3-ndash-change-advertising-interval-at-runtime 

If you can follow this approach and wait for GAPROLE_WAITING before disabling advertising, perhaps this will ensure you're not actively advertising when you attempt to stop an advertisement.

Please note: I will be out of the office until 1/4/2021 Monday of next week. My responses will be delayed until I return.

Hi Ammar,

I have changed my scanning/Advertising for 5 seconds each and disabled the connection part,now only device i scanning for 5sec then advertising for next 5 sec as per your inputs,

in this case i have kept device in debug for overnight testing still the device is working without an issue same will continue the same to check any further issues,

but previously when my scanning/advertising was kept for 15 sec with connection enabled it was going in spinlock.

without connection it didn't enter spinlock till now even with 5 sec scan/advertise.

If you can follow this approach and wait for GAPROLE_WAITING before disabling advertising, perhaps this will ensure you're not actively advertising when you attempt to stop an advertisement.

• If i stop advertisement it will enter the GAPROLE_WAITING state right? ,i didn't get this point.

Regards,

Atul

Hi Ammar ,

the same setup just disabling the connection in all cases,only advertising/scanning every 5 seconds still the device is running from 31st dec till now without any issue.

Regards,

Atul

Hey Atul,

Thanks for the feedback. This is good. From here, would you be able to connect to the device more frequently and capture a sniffer log of the traffic over the air?

It may help to reproduce the issue faster if you connect/disconnect more often than your default approach.

Hi Ammar N,

I was unable to get the sniffer log ,but same issue got reproduced when i had enabled the connection,

i have ROV capture for the Callstacks if this can help by any means to rectify the issue 

 

Please let me know for any inputs further.

Regards,

Atul

Hey Atul,

Thanks for that info. Without a sniffer log, it's tough to say what's going on over the air to determine the cause. What I would recommend next is to go through our Debugger's Guide and try the steps and approaches outlined there. In particular, the HAL Assert Causes and Explanation section. Try to figure out what the cause of the assert is, it should be passed in. I believe another community member mentioned this as well.