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.

CC2652R7: SDK BDB reporting code starts event timer with timeout of 0

Part Number: CC2652R7


Tool/software:

Hello,

We enabled BIOS asserts in syscfg in our app, and it immediately asserted on startup. The assert is from the TI-RTOS clock module (knl/Clock.c):

Assert_isTrue(!((params->startFlag != false) && (timeout == 0U)), Clock_A_badTimeout); // Clock.c ln: 651

The cause is the the BDB reporting functionality trying to start a clock with a timeout of 0. The offending code is here and is present in the samples and older SDKs:

//
// bdb_reporting.c
//
static void bdb_RepStartReporting( void )
{
  //Stop if reporting timer is active
  if( !OsalPortTimers_getTimerTimeout( bdb_TaskID, BDB_REPORT_TIMEOUT ) )
  {
    //timerElapsedTime is zero
    OsalPortTimers_stopTimer( bdb_TaskID, BDB_REPORT_TIMEOUT );
    bdb_reportingNextEventTimeout = 0;  // <== SET HERE
    bdb_reportingNextClusterEndpointIndex = BDBREPORTING_INVALIDINDEX;
    //Start Timer
    bdb_RepRestartNextEventTimer( );
  }
}

What happens is:

- bdb_reportingNextEventTimeout is set to 0, and then bdb_RepRestartNextEventTimer is called
- bdb_RepRestartNextEventTimer calls OsalPortTimers_startTimer( bdb_reportingNextEventTimeout )
- OsalPortTimers_startTimer (0)
  => createTimerEntry
     => Clock_P_create
        => Clock_create
           => Clock_construct
              => Clock_Instance_init
                 ASSERT

The docs are silent on whether a 0 timeout is allowed, but given the asserts, it's clearly not supported and the expected behavior is presumably undefined.

We changed the initialization form 0 to 1, which resolved the asserts.

Can you please advise that there are no adverse consequences form this fix?

Best regards,

  • Hello Kenny, 

    Thank you for raising this.  Your proposed fix would just be starting BDB reporting a second later than originally intended, so otherwise there are no adverse consequences.  You could change the units of bdb_RepRestartNextEventTimer and all instances of bdb_reportingNextEventTimeout if you wanted to make the timeout even shorter.  I've alerted the Zigbee R&D Team so that the F2 SDK can be improved for a future release.

    Regards,
    Ryan