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.

CC2530: Z-Stack 3.0.0 BDB reporting bug

Part Number: CC2530

I think I have found a bug in bdb_Reporting.c.  The constant 1000 is not treated as a uint32 so the compiler builds the wrong code, which causes the calculations to not work properly.  My fixed code with the added "L" on the constants is below:

static uint16 bdb_RepCalculateEventElapsedTime( uint32 remainingTimeoutTimer, uint16 nextEventTimeout )
{
  uint32 passTimeOfEvent = 0;
  passTimeOfEvent = nextEventTimeout*1000L >= remainingTimeoutTimer? nextEventTimeout*1000L - remainingTimeoutTimer: 0;
  uint16 elapsedTime = passTimeOfEvent / 1000L;
  elapsedTime = elapsedTime + ((passTimeOfEvent % 1000L) >0 ? 1:0); //roundup
  return elapsedTime;  
}

Also, in bdb_RepChangedAttrValue() if trying to send another report before consolidatedMinReportInt has passed, it just completely discards the report.  I think a better behavior would be to just wait until consolidatedMinReportInt has passed and then send the report, rather than discard it.  I have changed my code to reflect this modification as well.

  • Hi Ryan,

    1.- I have done some tests with the reporting attribute functionality and have not notice anything wrong with it, can you describe what was the behavior of the calculations before your fix?

    2.- Can you describe the change you did?, because I can think that if you trigger a report at MinReportInt due to a delta change during this time, you must read the attribute again before actually send the frame, otherwise you have the risk that the attribute goes below the delta and then you would be sending a confusing report attribute that has not pass the delta.
  • Is it possibly related to IAR version?