Why xDestroyProvidedObjects function hangs in I2C repeat condition ?

[Darsh-Dev]

Hi, As I have ported aws freertos on Silabs Geint Gecko MCU ki with trust-m my pkcs11 call will be redirected towards trust-m.

While performing vDevModeKeyProvisioning() for the first time (as suggested) xDestroyProvidedObjects() needs to be commented to work with from _aws_dev_modeprovisning.c file .

In debugging I found that xDestroyProvidedObjects() uses pal_i2c.c file's pal_i2c_write() function. This i2c write call does continuously loops in transmit of my I2CSPM_Transfer() if I2C_FLAG_WRITE is set. But on the other hand, if I use I2C_FLAG_WRITE_READ or I2C_FLAG_WRITE_WRITE flags (both will generate i2c condition) and I2CSPM_Transfer() will work properly.

So i assume xDestroyProvidedObjects() needs repeat condition in I2C (?!)

As a workaround, I have commented xDestroyProvidedObjects(). So, now vDevModeKeyProvisioning function job successfully done with CKR_OK

While further debugging this issue I saw macro in iot_pkcs_config.h as pkcs11configPAL_DESTROY_SUPPORTED to configurable. But when I made pkcs11configPAL_DESTROY_SUPPORTED macro 0 it disabled just only function and not its call i.e from iot_pkcs11_pal.c.c file, so it turned me giving _undefined reference to `PKCS11_PALDestroyObject error.

so I had to enable pkcs11configPAL_DESTROY_SUPPORTED.

Any help would be appreciable.

Thanks.

[ayushev]

All data Objects on OPTIGA Trust M have their own lifecycles and endurance . Depending on access conditions defined per each object different actions are allowed with that object. For instance the LcsO (Lifecycle State of the Object) transits from creational->initialisation->operational->termination In general, if the LcsO of the object is operational you cannot overwrite it, however if the LcsO is less than opertational you can "Destroy" an Object In the conext of AWS Demo the Destroy is required to remove recent data at the step of provisioning, so this function is required.

I just partially covered this question, as I'm no sure how can I help you in this issue? Is there a particular question(-s)?

[Darsh-Dev]

Hi, Thanks for the replay i did run optiga self test in early porting stage where it did write meta data which was causing this issue.

After optiga self test's successful execution i wrote again below metadata and it worked well.

static uint8_t metadata [] = {
        0x20, 0x08, // TL metadata TLV-Object
        0xD1, 0x01, 0x00, // TLV Read = ALW
        0xD0, 0x03, 0xE1, 0xFC, 0x07 // TLV Change = LcsO < op
};

Thanks