LP-CC2652RB: Issues with porting from SDK 6.20 to 7.41

Hello A V,

I hope you are doing well! 

For problem 1: Delete the linked files in the project (from CCS) and copy the local versions from the SDK into the same project location, then rebuild (the local files should now be used).

For problem 2: Can you confirm that all flash memory has been erased and that the v7.40 image is being programed on a blank device? There is no difference in ZCL between v6.20 and v7.40 however the NV memory configuration has changed. 

Thanks,
Alex F

Hello Alex,

Thank you for your reply.

Alex Fager said:

Can you confirm that all flash memory has been erased and that the v7.40 image is being programed on a blank device? 

That's how I tested it the first time and could never get it to work. I did a flash erase using Uniflash. On the contrary, the only way I could get the device to pair was to not erase flash memory, but overwrite the application code from SDK 6.20 with that from SDK 7.41. I suppose this worked (though I could not retrieve actual data from the board with sdk 7.41) only because the NV memory from SDK 6.20 was kept and somehow the end device could see that there was a connection to a coordinator at boot up and go on with the device announce.

I suspect this issue lies somewhere within ZStack's implementation, as the three files for device definition (_data.c, sample app.c/h) seem to be identical. 

I would very much like to proceed with device development, but I cannot get a blank device flashed with SDK 7.41 to pass the interview and assess its stability.

Hello Alex,

I've done additional tests and have some more detailed updates regarding the things I've tried. 

I've reverted both SDK 6.20 and sdk 7.41 projects to their defaults and tried pairing them again. As before, only SDK 6.20 managed to pass the interview and communicate its manufacturer and model to the coordinator. I've always made sure to erase chip memory and attempt a fresh pair. It never worked.

I've downgraded SDK 7.41 to SDK 7.40 and, again, compared it with SDK 6.20. Sample project works for SDK 6.20, but not for SDK 7.40. I then checked the zcl_sampletemperaturesensor.c/.h and _data.c files to make sure they are identical with the SDK 6.20 version and they are. I've then moved on to an updated version of the SDK 6.20 project, which has the following changes done to it:

• added OTA
• changed the linker file for the ota version
• updated the include paths and predefined symbols
• added the model identifier

I've made the same changes to SDK 7.41 (for the model identifier I copied the _data.c file from SDK 6.20 to SDK 7.41, as the core files were identical and to eliminate the issue of typos) and compared the two projects side by side by pairing them to the same coordinator setup. Again, SDK 6.20 paired with no issues while SDK 7.40 gave the same error of undefined manufacturer and model identifier.

At the moment, the sample project built with SDK 6.20 is paired with the coordinator and sends its temperature as expected, while SDK 7.40 is unresponsive and cannot complete its interview.

My question is: Have any changes been made deeper inside SDK 7+ such that I have to manually handle the commissioning process? The three files for project setup are identical, so I can only assume that the differences lie deeper inside the zstack implementation. For some reason, whatever changes have been made prevent the sample project from correctly pairing with a coordinator.

Hi A V,

Based on your Z2M log, it appears that the temperature sensor device is returning ZCL_STATUS_UNSUPPORTED_ATTRIBUTE when you attempt to read the attribute.  You could further debug zclProcessInReadCmd of zcl.c to determine what is causing this.  I have performed a comprehensive comparison between SDK v6.20 and v7.40, the only difference which stands out is inside of zclProcessInReadCmd itself.

      if ( zcl_AccessCtrlRead( attrRec.attr.accessControl ) )
      {
//        statusRec->status = zclAuthorizeRead( pInMsg->msg->endPoint,              // THIS LINE REMOVED AFTER v6.20
//                                              &(pInMsg->msg->srcAddr), &attrRec );// THIS LINE REMOVED AFTER v6.20
// START of ADDED for V7.40
        if ( zcl_AccessCtrlAuthRead( attrRec.attr.accessControl ))
        {
          statusRec->status = zclAuthorizeRead( pInMsg->msg->endPoint,
                                                        &(pInMsg->msg->srcAddr), &attrRec );
        }
        else
        {
          statusRec->status = zclReadAttrDataUsingCB( pInMsg->msg->endPoint, attrRec.clusterID, attrRec.attr.attrId, attrRec.attr.dataPtr, &len );
        }
// END of ADDED for v7.40

You could try reverting zcl.c or use ACCESS_CONTROL_AUTH_READ in your attribute list.

Regards,
Ryan

Hello Ryan,

I've delved deeper with the debugger and found that, for SDK 7.40, the failure is at the following verification:

    if ( ( attrFound == TRUE ) &&
         (  (attrRec.attr.accessControl & ACCESS_GLOBAL) ||
            (GET_BIT( &attrRec.attr.accessControl, ACCESS_CONTROL_MASK ) == pInMsg->hdr.fc.direction ) ) )

The attrFound variable was FALSE as set a few lines above. Therefore, the function returns with ZCL_STATUS_UNSUPPORTED_ATTRIBUTE.

I've then replaced ACCESS_CONTROL_READ with ACCESS_CONTROL_AUTH_READ for the attributes pertaining to the general cluster. Like so:

CONST zclAttrRec_t zclSampleTemperatureSensor_Attrs[] =
{
  // *** General Basic Cluster Attributes ***
  {
    ZCL_CLUSTER_ID_GENERAL_BASIC,
    { // Attribute record
      ATTRID_BASIC_ZCL_VERSION,
      ZCL_DATATYPE_UINT8,
      ACCESS_CONTROL_AUTH_READ,
      (void *)&zclSampleTemperatureSensor_ZCLVersion
    }
  },
  {
    ZCL_CLUSTER_ID_GENERAL_BASIC,             // Cluster IDs - defined in the foundation (ie. zcl.h)
    {  // Attribute record
      ATTRID_BASIC_HW_VERSION,            // Attribute ID - Found in Cluster Library header (ie. zcl_general.h)
      ZCL_DATATYPE_UINT8,                 // Data Type - found in zcl.h
      ACCESS_CONTROL_AUTH_READ,                // Variable access control - found in zcl.h
      (void *)&zclSampleTemperatureSensor_HWRevision  // Pointer to attribute variable
    }
  },
  {
    ZCL_CLUSTER_ID_GENERAL_BASIC,
    { // Attribute record
      ATTRID_BASIC_MANUFACTURER_NAME,
      ZCL_DATATYPE_CHAR_STR,
      ACCESS_CONTROL_AUTH_READ,
      (void *)zclSampleTemperatureSensor_ManufacturerName
    }
  },
  {
      ZCL_CLUSTER_ID_GENERAL_BASIC,
      { // Attribute record
        ATTRID_BASIC_MODEL_IDENTIFIER,
        ZCL_DATATYPE_CHAR_STR,
        ACCESS_CONTROL_AUTH_READ,
        (void *)model
      }
    },
  {
    ZCL_CLUSTER_ID_GENERAL_BASIC,
    { // Attribute record
      ATTRID_BASIC_POWER_SOURCE,
      ZCL_DATATYPE_ENUM8,
      ACCESS_CONTROL_AUTH_READ,
      (void *)&zclSampleTemperatureSensor_PowerSource
    }
  },
  {
    ZCL_CLUSTER_ID_GENERAL_BASIC,
    { // Attribute record
      ATTRID_BASIC_PHYSICAL_ENVIRONMENT,
      ZCL_DATATYPE_ENUM8,
      (ACCESS_CONTROL_AUTH_READ | ACCESS_CONTROL_WRITE),
      (void *)&zclSampleTemperatureSensor_PhysicalEnvironment
    }
  },
  {
    ZCL_CLUSTER_ID_GENERAL_BASIC,
    {  // Attribute record
      ATTRID_CLUSTER_REVISION,
      ZCL_DATATYPE_UINT16,
      ACCESS_CONTROL_AUTH_READ,
      (void *)&zclSampleTemperatureSensor_basic_clusterRevision
    }
  },
  // *** Identify Cluster Attribute ***
  {
    ZCL_CLUSTER_ID_GENERAL_IDENTIFY,
    { // Attribute record
      ATTRID_IDENTIFY_IDENTIFY_TIME,
      ZCL_DATATYPE_UINT16,
      (ACCESS_CONTROL_AUTH_READ | ACCESS_CONTROL_WRITE),
      (void *)&zclSampleTemperatureSensor_IdentifyTime
    }
  },
  {
    ZCL_CLUSTER_ID_GENERAL_IDENTIFY,
    {  // Attribute record
      ATTRID_CLUSTER_REVISION,
      ZCL_DATATYPE_UINT16,
      ACCESS_CONTROL_AUTH_READ | ACCESS_GLOBAL,
      (void *)&zclSampleTemperatureSensor_identify_clusterRevision
    }
  },

  // *** Temperature Measurement Attriubtes ***
  {
    ZCL_CLUSTER_ID_MS_TEMPERATURE_MEASUREMENT,
    { // Attribute record
      ATTRID_TEMPERATURE_MEASUREMENT_MEASURED_VALUE,
      ZCL_DATATYPE_INT16,
      ACCESS_CONTROL_READ | ACCESS_REPORTABLE,
      (void *)&zclSampleTemperatureSensor_MeasuredValue
    }
  },
  {
    ZCL_CLUSTER_ID_MS_TEMPERATURE_MEASUREMENT,
    { // Attribute record
      ATTRID_TEMPERATURE_MEASUREMENT_MIN_MEASURED_VALUE,
      ZCL_DATATYPE_INT16,
      ACCESS_CONTROL_READ,
      (void *)&zclSampleTemperatureSensor_MinMeasuredValue
    }
  },
  {
    ZCL_CLUSTER_ID_MS_TEMPERATURE_MEASUREMENT,
    { // Attribute record
      ATTRID_TEMPERATURE_MEASUREMENT_MAX_MEASURED_VALUE,
      ZCL_DATATYPE_INT16,
      ACCESS_CONTROL_READ,
      (void *)&zclSampleTemperatureSensor_MaxMeasuredValue
    }
  },

  {
    ZCL_CLUSTER_ID_MS_TEMPERATURE_MEASUREMENT,
    {  // Attribute record
      ATTRID_CLUSTER_REVISION,
      ZCL_DATATYPE_UINT16,
      ACCESS_CONTROL_READ,
      (void *)&zclSampleTemperatureSensor_temperaturems_clusterRevision
    }
  },
};

There was no change in the way the interview failed. I am still getting the undefined result for manufacturer and model identifier.

I've then replaced zcl.c from SDK 7.40 with zcl.c from SDK 6.20. I've gotten the same result: undefined manufacturer and model.

Which verification fails?

1. attrFound == TRUE
   
   1. Debug zclFindAttrRec -> zclFindAttrRecsList
   2. Does it align with the zcl_registerAttrList call from zcl_sampletemperaturesensor.c?  Make sure the numAttr and newAttrList parameters are correct and as expected
2. GET_BIT( &attrRec.attr.accessControl, ACCESS_CONTROL_MASK ) == pInMsg->hdr.fc.direction

Note: you can set multiple access controls since they are bit mask values, i.e. ACCESS_CONTROL_AUTH_READ | ACCESS_GLOBAL

Regards,
Ryan

Hello Ryan. Sorry for my belated response.

Ryan Brown1 said:

attrFound == TRUE

This fails.

I've dug deeper with the debugger and looked at the zclAttrRecsList* returned by zclFindAttrRecsList. It has 13 structures inside, just like my attribute list. The structures are correct and the pointers to model and manufacturer are also correct in size and structure.

I've stepped through the code inside this function with the debugger:

uint8_t zclFindAttrRec( uint8_t endpoint, uint16_t clusterID, uint16_t attrId, zclAttrRec_t *pAttr )
{
  uint8_t x;
  zclAttrRecsList *pRec = zclFindAttrRecsList( endpoint );

  if ( pRec != NULL )
  {
    for ( x = 0; x < pRec->numAttributes; x++ )
    {
      if ( pRec->attrs[x].clusterID == clusterID && pRec->attrs[x].attr.attrId == attrId )
      {
        *pAttr = pRec->attrs[x];

        return ( TRUE ); // RETURNS TRUE FOR MODEL AND MANUFACTURER
      }
    }
  }

  return ( FALSE );
}

Even so, I still get unsupported attribute inside zclProcessInReadCmd, though I suppose that was for a different attribute. Even with optimizations set to 0, the debugger seems to work rather poorly. I couldn't always get a breakpoint to hit even though I could see in the console that an interview was ongoing and completed with the same error. Anyways, in the seldom moments I could get a breakpoint to hit, I managed to see the model identifier and manufacturer attributes and they were correctly identified.

I will try to dig deeper and see why the debugger does not always work correctly.

Any other ideas where the interview might fail?

Thanks for debugging.  It would not make sense for both zclFindAttrRec to return true and attrFound to be false.  Looking back at the interview process, it mentions swBuildId as an error.  Have you included ATTRID_BASIC_SW_BUILD_ID in your attribute list?

Regards,
Ryan

Ryan Brown1 said:

It would not make sense for both zclFindAttrRec to return true and attrFound to be false.

I found that weird as well and have spent quite some time looking at this. I've also noticed that, inside zcFindAttrRec I got five consecutive hits for Cluster 0x402 (MS_TEMPERATURE) and AATR_ID 0x00. They all returned true, but I found that weird and did not always happen. Will try to replicate this with SDK 6.20 tomorrow when I get back to the office. I also noticed that, sometimes, the debugger would not trigger anywhere but the interview was ongoing and finished with the same failed result. Again, this did not always happen.

Ryan Brown1 said:

Have you included ATTRID_BASIC_SW_BUILD_ID in your attribute list?

No. I will also add this and see what response I get.

Additional question: Have there been made any changes to the bim_offchip from SDK 6.20 to SDK 7.40? Should I always pair boot loader from SDK 7.40 to the device firmware from the same SDK version? 

A V said:

Have there been made any changes to the bim_offchip from SDK 6.20 to SDK 7.40?

I'm not aware of any functional differences but please perform a diff compare of these two project variants to confirm.  You don't have to pair BIM and application SDK versions as this would not be helpful towards OAD.

Regards,
Ryan