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.

LP-AM243: Adding record in Ethercat slave simple demo

Part Number: LP-AM243

Tool/software:

Hi team,

In the example code given ({Ind_Comm_SDK} -> example -> industrial_comms -> ethercat_slave_demo -> device_profiles -> 401_simple) ,

I have added a Record 0x7000 with 3 sub indexes under EC_SLV_APP_SS_populateInOutObjects for testing purpose

/*0x7000 - Commands*/
    error = (EC_API_EError_t)EC_API_SLV_CoE_odAddRecord(
            ptSlave,
        0x7000,
        "Commands",
        EC_SLV_APP_setValueToMaster,
        pApplicationInstance,
        EC_SLV_APP_getValueFromMaster,
        pApplicationInstance,
        &pApplicationInstance->ptCommandObj);
    if (error != EC_API_eERR_NONE)
    {
        OSAL_printf("Object 0x7000 Record Error code: 0x%08x\r\n", error);
        /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
        /* cppcheck-suppress misra-c2012-15.1 */
        goto Exit;
    }
    /*0x7000:1*/
    error = (EC_API_EError_t)EC_API_SLV_CoE_configRecordSubIndex(
        ptSlave,
        pApplicationInstance->ptCommandObj,
        1,
        "INPUT COMMANDS",
        DEFTYPE_UNSIGNED16,
        16,
        ACCESS_READWRITE);
    if (error != EC_API_eERR_NONE)
    {
        OSAL_printf("Object 0x7000 SubIndex 1 Error code: 0x%08x\r\n", error);
        /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
        /* cppcheck-suppress misra-c2012-15.1 */
        goto Exit;
    }
    /*0x7000:2*/
    error = (EC_API_EError_t)EC_API_SLV_CoE_configRecordSubIndex(
        ptSlave,
        pApplicationInstance->ptCommandObj,
        2,
        "PROGRAM",
        DEFTYPE_UNSIGNED16,
        16,
        ACCESS_READWRITE);
    if (error != EC_API_eERR_NONE)
    {
        OSAL_printf("Object 0x7000 SubIndex 2 Error code: 0x%08x\r\n", error);
        /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
        /* cppcheck-suppress misra-c2012-15.1 */
        goto Exit;
    }
    /*0x7000:3*/
	error = (EC_API_EError_t)EC_API_SLV_CoE_configRecordSubIndex(
		ptSlave,
		pApplicationInstance->ptCommandObj,
		3,
		"RxPDO_SDO_FU",
		DEFTYPE_UNSIGNED16,
		16,
		ACCESS_READWRITE | OBJACCESS_RXPDOMAPPING);
	if (error != EC_API_eERR_NONE)
	{
		OSAL_printf("Object 0x7000 SubIndex 2 Error code: 0x%08x\r\n", error);
		/* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
		/* cppcheck-suppress misra-c2012-15.1 */
		goto Exit;
	}

<DataType>
								<Name>DT7000</Name>
								<BitSize>64</BitSize>
								<SubItem>
									<SubIdx>0</SubIdx>
									<Name>SubIndex 000</Name>
									<Type>USINT</Type>
									<BitSize>8</BitSize>
									<BitOffs>0</BitOffs>
									<DefaultData>3</DefaultData>
									<Flags>
										<Access>ro</Access>
									</Flags>
								</SubItem>
								<SubItem>
									<SubIdx>1</SubIdx>
									<Name>Input Commands</Name>
									<Type>UINT</Type>
									<BitSize>16</BitSize>
									<BitOffs>16</BitOffs>
									<Flags>
										<Access>rw</Access>
									</Flags>
								</SubItem>
								<SubItem>
									<SubIdx>2</SubIdx>
									<Name>PROGRAM</Name>
									<Type>UINT</Type>
									<BitSize>16</BitSize>
									<BitOffs>32</BitOffs>
									<Flags>
										<Access>rw</Access>
									</Flags>
								</SubItem>
								<SubItem>
									<SubIdx>3</SubIdx>
									<Name>RxPDO_SDO_FU</Name>
									<Type>UINT</Type>
									<BitSize>16</BitSize>
									<BitOffs>48</BitOffs>
									<Flags>
										<Access>rw</Access>
									</Flags>
								</SubItem>
							</DataType>
							
							
							<Object>
								<Index>#x7000</Index>
								<Name>Commands</Name>
								<Type>DT7000</Type>
								<BitSize>64</BitSize>
								<Flags>
                                    <Access>rw</Access>
                                </Flags>
							</Object>

 I got the below addition in Twincat CoE-Online,

why I'm not getting the number of indeces in

0x7000:0 Command Value

and default values of 0x7000:1-3 

Kindly guide me further to clear this issue


Regards,
D.Jenita

  • Hello Jenita,

    I added a record object 0x7000 with 3 sub-index entries in the EtherCAT SubDevice Simple Demo example and I used the online description instead of the ESI file, I see the number of indexes for object 0x7000 in CoE-Online tab in TwinCAT. I have attached the screenshot below.

    Kind Regards,

  • Hi Harsha,

    Thank you for your support,

    So I can confirm the snippet what I have added to configure Record is correct. right? 
    But I didn't get the values with online description as well.

    The thing is I need to run CTT test for the case with .esi file while  running I got the below warning 

    TF-2302_1.1.0/Objects with read Access in PreOp (offline dictionary) Warning Test Function 'CompareObjectData': 0x7000:0 SI0 Complete Access data is dfferent to Single Access data. The entry data may change because the entry description provides no default data. But the single access upload of this entry is ten times in the same value.

    I suspect that the warning may because of the  issue what I have mentioned.

    Can you please guide me further  with .esi file as well.

    regards, 

    D. Jenita

  • Hello Jenita,

    Yes. The code snippet you shared to create the record is correct. I have also done the modifications that you have shared for the ESI file and copied into TwinCAT device description folder (C:\TwinCAT\3.1\Config\Io\EtherCAT) and tested. 

    The API EC_API_SLV_CoE_setObjectEntryData can be used to write the data values to object entries. Please find the sample code snippet below to load the default values to the entries of the object 0x7000.

    static void EC_SLV_APP_SS_loadDefaultValuesForInOutObjects(EC_SLV_APP_SS_Application_t *pApplicationInstance)
    {
        EC_API_EError_t             error                   = EC_API_eERR_INVALID;
        EC_API_SLV_SHandle_t        *ptSubDevice;
        EC_API_SLV_SCoE_ObjEntry_t  *ptObjEntry             = NULL;
        static uint16_t             recEntryDefaultValue    = 0xDEFA;
        
        ptSubDevice = pApplicationInstance->ptEcSlvApi;
    
        error = (EC_API_EError_t)EC_API_SLV_CoE_getObjectEntry(ptSubDevice, 0x7000, 1, &ptObjEntry);
        if (error != EC_API_eERR_NONE)
        {
            OSAL_printf("%s:%d Error code: 0x%08x\r\n", __func__, __LINE__, error);
            /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
            /* cppcheck-suppress misra-c2012-15.1 */
            goto Exit;
        }
    
        /* @cppcheck_justify{misra-c2012-11.3} type cast required to fit API */
        /* cppcheck-suppress misra-c2012-11.3 */
        error = (EC_API_EError_t)
            EC_API_SLV_CoE_setObjectEntryData(ptSubDevice, ptObjEntry, 2, (uint16_t *)&recEntryDefaultValue);
        if (error != EC_API_eERR_NONE)
        {
            OSAL_printf("%s:%d Error code: 0x%08x\r\n", __func__, __LINE__, error);
            /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
            /* cppcheck-suppress misra-c2012-15.1 */
            goto Exit;
        }
    
        error = (EC_API_EError_t)EC_API_SLV_CoE_getObjectEntry(ptSubDevice, 0x7000, 2, &ptObjEntry);
        if (error != EC_API_eERR_NONE)
        {
            OSAL_printf("%s:%d Error code: 0x%08x\r\n", __func__, __LINE__, error);
            /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
            /* cppcheck-suppress misra-c2012-15.1 */
            goto Exit;
        }
        
        recEntryDefaultValue = 0xDEAD;
    
        /* @cppcheck_justify{misra-c2012-11.3} type cast required to fit API */
        /* cppcheck-suppress misra-c2012-11.3 */
        error = (EC_API_EError_t)
            EC_API_SLV_CoE_setObjectEntryData(ptSubDevice, ptObjEntry, 2, (uint16_t *)&recEntryDefaultValue);
        if (error != EC_API_eERR_NONE)
        {
            OSAL_printf("%s:%d Error code: 0x%08x\r\n", __func__, __LINE__, error);
            /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
            /* cppcheck-suppress misra-c2012-15.1 */
            goto Exit;
        }
    
        error = (EC_API_EError_t)EC_API_SLV_CoE_getObjectEntry(ptSubDevice, 0x7000, 3, &ptObjEntry);
        if (error != EC_API_eERR_NONE)
        {
            OSAL_printf("%s:%d Error code: 0x%08x\r\n", __func__, __LINE__, error);
            /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
            /* cppcheck-suppress misra-c2012-15.1 */
            goto Exit;
        }
        
        recEntryDefaultValue = 0xDCBA;
        
        /* @cppcheck_justify{misra-c2012-11.3} type cast required to fit API */
        /* cppcheck-suppress misra-c2012-11.3 */
        error = (EC_API_EError_t)
            EC_API_SLV_CoE_setObjectEntryData(ptSubDevice, ptObjEntry, 2, (uint16_t *)&recEntryDefaultValue);
        if (error != EC_API_eERR_NONE)
        {
            OSAL_printf("%s:%d Error code: 0x%08x\r\n", __func__, __LINE__, error);
            /* @cppcheck_justify{misra-c2012-15.1} goto is used to assure single point of exit */
            /* cppcheck-suppress misra-c2012-15.1 */
            goto Exit;
        }
    
        Exit:
            return;
    }

    Call the function EC_SLV_APP_SS_loadDefaultValuesForInOutObjects() after the call to the API EC_API_SLV_init().

     EC_SLV_APP_SS_loadDefaultValuesForInOutObjects(pAppInstance_p);

    Below is the screenshot of the CoE - Online tab in TwinCAT.



    Kind Regards,

  • Hi Harsha,

    Thank you for the suggestions.

    TF-2302_1.1.0/Objects with read Access in PreOp (offline dictionary) Warning Test Function 'CompareObjectData': 0x7000:0 SI0 Complete Access data is dfferent to Single Access data. The entry data may change because the entry description provides no default data. But the single access upload of this entry is ten times in the same value.

    Based on the warning, my understanding was 0x7000:0 is being interpreted as an entry description which has no default data.

    I got values on 0x7000:0 - 3 as yours, only after removing callback functions EC_API_SLV_CBObjRead_t cbRead & EC_API_SLV_CBObjWrite_t cbWrite,

    (SDK version Used: ind_comms_sdk_am243x_09_02_00_08)

        error = (EC_API_EError_t)EC_API_SLV_CoE_odAddRecord(
                ptSlave,
            0x7000,
            "Commands",
            NULL/*EC_SLV_APP_setValueToMaster*/,
    		NULL/*pApplicationInstance*/,
    		NULL/*EC_SLV_APP_getValueFromMaster*/,
    		NULL/*pApplicationInstance*/,
            &pApplicationInstance->ptCommandObj);

    static uint8_t EC_SLV_APP_getValueFromMaster(
            void* pApplicationCtxt_p,
            uint16_t index_p,
            uint8_t subindex_p,
            uint32_t size_p,
            uint16_t MBXMEM * pData_p,
            uint8_t completeAccess_p)
    {
        EC_API_EError_t     error   = (EC_API_EError_t)ABORT_NOERROR;
    
        OSAL_printf("%s ==> Idx: 0x%04x:%d | Size: %d | Value: %d | access: %d\r\n", __func__
                   ,index_p, subindex_p, size_p, pData_p[0], completeAccess_p);
    
    
        /*Update the LOOKUP Table*/
        update_lookup(index_p, subindex_p, &pData_p[0], size_p);
    
        /*Whenever data is received from master, give semaphore to Task 3*/
        if (NULL == pApplicationCtxt_p)
            goto Exit;
    
        OSALUNREF_PARM(completeAccess_p);
    
    Exit:
        return (uint8_t)error;
    }

    update_lookup() is the simple function which compares Index and Sub Index and update the variable accordingly.

    I’m currently using callback functions to update variables (e.g., a lookup table) in my application.

    Is there any alternative method for updating these variables, or a more suitable approach depending on the application?

    Also, am I possibly missing any steps or considerations in the configuration of the callback functions?

    Thank you for your continued support.

    Regards,

    D.Jenita

  • Hello Jenita,

    I was able to reproduce the issue when the write/read callback functions are attached to EC_API_SLV_CoE_odAddRecord(). I will get back to you on this.

    Kind Regards,

  • Hi Harsha,

    I wanted to share an observation that may help in identifying the root cause of this issue encountered during the conformance test.

    During testing, I noticed that the object entries with sub-indices other than 0 report Complete access: 0 [False]

    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:1 | Size: 2 | Value: 0 | access: 0
    
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:2 | Size: 2 | Value: 0 | access: 0

    However, the main entry (index 0) shows Complete access: 1 [True]

    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 1


    To address this, I tried disabling complete access in the .esi file using the following configuration:

    <CoE DiagHistory="true" SdoInfo="true" PdoConfig="true" PdoUpload="true" CompleteAccess="false"/>


    Still I'm having those warnings.

    I suspect the issue may lie in the firmware configurations. Could you please guide me further on how to address this?

    Looking forward to your suggestions.

    Regards,
    D.Jenita

  • Hello Jenita,

    The CTT warning is representing the data inconsistency between when accessed with complete access flag set and reset. When the object data accessed with complete access flag set, the callback function should return the values of all the sub-indexes of the object. The complete access flag is only valid with SI0. If the complete access flag is not set, then the callback function should return the specific data based on the SI value.

    When you attach the callback functions such as EC_SLV_APP_setValueToMaster and EC_SLV_APP_getValueToMaster, it is the responsibility of these callback function to handle the data of the object.

    When the EtherCAT Main Device, TwinCAT for example, tries to read the object data then the callback function EC_SLV_APP_getValueToMaster is called. In this case, this callback function should read the object's data from the memory and return. Similarly, When the EtherCAT Main Device, TwinCAT for example, tries to write the object data then the callback function EC_SLV_APP_setValueToMaster is called. In this case, this callback function should write the object data received into object's memory.

    Kind Regards,

  • Hi Harsha,

    Thank you for the explanation.

    As you mentioned, 

    The CTT warning is representing the data inconsistency between when accessed with complete access flag set and reset.

    Please correct me if I'm wrong, I understand that:

    • When CA is set, the callback function returns all subindices of the object.

    • When CA is not set, we are using Single Access (SA), and the function returns only the specified subindex value.

    My concern is about clearing the CTT warning. I’m fine proceeding with either CA or SA, but would like to confirm the correct approach:

    • If we use Complete Access (CA), how and where to set the CA flag for all subindices (SI1...SIn)?

    • If we use Single Access (SA), how to clear the CA flag for the entry object (SI0)? 

    For our application Complete Access is more preferred, we are also fine with Single Access if CA cannot be applied in this case.

    Please let me know which approach is preferred to resolve the warning.

    Warm regards,

    D. Jenita

  • Hello Jenita,

    Yes. You are correct. If the CA = 1, then the callback function should return the data of all SI of the object. There are 2 options in this case.

    1. If SI = 0, then the callback function should return the data of all SI of the object including the SI0 data.
    2. If SI =1, then the callback function should return the data of all SI of the object excluding the SI0 data.

    Please refer the screenshots below.

    If the CA = 0, then the callback function should return the data of the specified SI and Index of the object.

    In order to resolve the warning in the CTT and to find the root cause you have to verify your callback implementation and observe if the data read/write is as per the conditions. When the EtherCAT Main Device access the object 0x7000 data with CA=1 and CA=0, should match but the warning shows that there is a data mismatch.

    For example, in your case the object 0x7000 has 3 SI of size 16bits each. Let's assume that the object 0x7000 has the following data.

    0x7000:0 = 0x03, 0x7000:1 = 0x1234, 0x7000:2 = 0x5678 and 0x7000:3 = 0x9ABC.

    CASE1: When the EtherCAT MainDevice tries to read the object 0x7000 with CA=1 and SI=0 then the callback should return [0x03,0x1234,0x5678,0x9ABC] - represented like this for explanation.

    CASE2: When the EtherCAT MainDevice tries to read the object 0x7000 with CA=1 and SI=1 then the callback should return [0x1234,0x5678,0x9ABC].

    CASE 3: When the EtherCAT MainDevice tries to read the object 0x7000 with CA=0 and SI=0 then the callback should return [0x03].

    The CTT can compare the data of 0x7000:0 accessed via CA=1 and CA=0. When there is a data mismatch, it issues the warning.

    I see in your logs that, the callback returns value = 0x00 for 0x7000:0 read. Should it be returning 0x03 instead of 0x00?

    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 1

    Is my understanding correct?

    The CA information will be received from the EtherCAT MainDevice and EtherCAT SubDevice should act accordingly. 

    My concern is about clearing the CTT warning. I’m fine proceeding with either CA or SA, but would like to confirm the correct approach:

    • If we use Complete Access (CA), how and where to set the CA flag for all subindices (SI1...SIn)?

    • If we use Single Access (SA), how to clear the CA flag for the entry object (SI0)? 

    This part of the question is bit confusing to me. Could you please explain again?

    Kind Regards,

  • Hi Harsha,

    1. If SI = 0, then the callback function should return the data of all SI of the object including the SI0 data.
    2. If SI =1, then the callback function should return the data of all SI of the object excluding the SI0 data.

    I understand the content but where exactly It needs to be configured Subindex(SI) = 0 / 1. 

    In order to resolve the warning in the CTT and to find the root cause you have to verify your callback implementation and observe if the data read/write is as per the conditions.

    with TwinCAT read/write working properly

    I see in your logs that, the callback returns value = 0x00 for 0x7000:0 read. Should it be returning 0x03 instead of 0x00?

    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 1

    Is my understanding correct?

    Yes, while running CTT test I'm getting below log in console

    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 0 | access: 1
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7001:0 | Size: 10 | Value: 0 | access: 1

    and as I mentioned earlier, I got something like below in Twincat after adding callback functions.
     In both SI0 Value=0;

    Warning from CTT

    for SI other than 0

    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:1 | Size: 2 | Value: 0 | access: 0
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:2 | Size: 2 | Value: 0 | access: 0
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:3 | Size: 2 | Value: 0 | access: 0

    I was able to reproduce the issue when the write/read callback functions are attached to EC_API_SLV_CoE_odAddRecord(). I will get back to you on this.

    As you said, you was able to reproduce the same issue. Is resolved in your side?? 

    Regards,
    D.Jenita

  • Hello Jenita,

    I understand the content but where exactly It needs to be configured Subindex(SI) = 0 / 1.

    As per the attached callback APIs, the Index, Subindex (SI), size and complete access are the input parameters for your call back function and will be decided by the EtherCAT MainDevice while reading/writing the object data. The callback function should check the SI input parameter value and act accordingly. You are NOT ALLOWED to configure Index or SI in the callback.

    The Complete SDO Access is supported and enabled in the TI EtherCAT SubDevice stack. Hence, the connected EtherCAT MainDevice can access the SDO with complete access. Please refer the define in the ecat_def.h file. If you want, you can disable the complete SDO access by adapting this marco and flags in the General category of the SII.

    #define COMPLETE_ACCESS_SUPPORTED                 1


    If there are any settings in the EtherCAT MainDevice related to SDO access, you can try that.

    We are not understanding why exactly you want to configure the SI during the SDO access? How do you want to configure the SI during the SDO access?

    Yes, while running CTT test I'm getting below log in console

    Fullscreen
    1
    2
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 0 | access: 1
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7001:0 | Size: 10 | Value: 0 | access: 1
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    and as I mentioned earlier, I got something like below in Twincat after adding callback functions.
     In both SI0 Value=0;

    This shows that the callback functions are not implemented as intended. My suspect is that the callback functions are not handling the object data read and write. Please share the logs of SDO request and response transactions. You can use OSAL_printf API to print the details.

    As you said, you was able to reproduce the same issue. Is resolved in your side?? 

    Yes. I was able to reproduce the warning in the CTT with TF-2302 and the root cause was the incorrect callback implementations. Kindly recheck your callback implementations.

    Kind Regards,

  • Hi Harsha,

    This shows that the callback functions are not implemented as intended. My suspect is that the callback functions are not handling the object data read and write. Please share the logs of SDO request and response transactions. You can use OSAL_printf API to print the details.

    Yes, I agree — the callback function may not be implemented as intended. I had pointed this out in my earlier query as well.
    The log what I shared before is taken inside cb functions using OSAL_printf only which is SDO download and upload data right? 

    TF2300
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:1 | Size: 2 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:2 | Size: 2 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:3 | Size: 2 | Value: 0 | access: 0
    
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:1 | Size: 2 | Value: 0 | access: 0
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:2 | Size: 2 | Value: 0 | access: 0
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:3 | Size: 2 | Value: 0 | access: 0
    
    TF2302
    State change: 0x1 -> 0x2
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 0 | access: 1
    
    State change: 0x2 -> 0x4
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 0 | access: 1
    
    State change: 0x4 -> 0x8
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 7220 | access: 1
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    
    State change: 0x1 -> 0x2
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 10 | access: 1
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 0 | access: 1
    
    State change: 0x2 -> 0x4
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 1 | Value: 0 | access: 0
    EC_SLV_APP_setValueToMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 0 | access: 1
    EC_SLV_APP_getValueFromMaster ==> Idx: 0x7000:0 | Size: 8 | Value: 0 | access: 1
    
    

    I’m currently using callback functions to update variables (e.g., a lookup table) in my application.

    Is there any alternative method for updating these variables, or a more suitable approach depending on the application?

    Also, am I possibly missing any steps or considerations in the configuration of the callback functions?

    Yes. I was able to reproduce the warning in the CTT with TF-2302 and the root cause was the incorrect callback implementations. Kindly recheck your callback implementations.

    This is what my query is I checked things as per my knowledge, I want support in this. Since you were able to reproduce the issue, your insights would be highly valuable in resolving this.

    Looking forward to your suggestions and support on this.

    Regards,

    D. Jenita

  • Hello Jenita,

    Yes, I agree — the callback function may not be implemented as intended. I had pointed this out in my earlier query as well.
    The log what I shared before is taken inside cb functions using OSAL_printf only which is SDO download and upload data right? 

    The reason why I asked for a detailed log is to check the data value part. It is still missing in your logs. pData_p is a pointer to object data, and you have to print the data bytes based on the size.

    I have implemented the sample callbacks for SDO 0x7000 read and write operations, by considering your callbacks as a reference. Please find the code snippet below.

    static uint16_t objData[4] = {0x0003,0x1234,0x5678,0x9ABC}; // This simulates the memory/lookup table.
    
    // Attached as a write callback for SDO download.
    static uint8_t EC_SLV_APP_getValueFromMaster(void* pApplicationCtxt_p,uint16_t index_p,uint8_t subindex_p,uint32_t size_p,uint16_t MBXMEM * pData_p,uint8_t completeAccess_p)
    {
        EC_API_EError_t     error   = (EC_API_EError_t)ABORT_NOERROR;
    
        OSAL_printf("SDO Download: %s ==> Idx: 0x%04x:%d | Size: %d | access: %d\r\n", __func__,index_p, subindex_p, size_p, completeAccess_p);
        
        if (completeAccess_p)
        {
            if(subindex_p == 0)
            {
                OSAL_MEMORY_memcpy((uint8_t*)&objData[1],(uint8_t*)&pData_p[1], size_p);
                OSAL_printf("Download: 0x%04x:%d = 0x%04x\r\n",index_p, 0,objData[0]);
                OSAL_printf("Download: 0x%04x:%d = 0x%04x\r\n",index_p, 1,objData[1]);
                OSAL_printf("Download: 0x%04x:%d = 0x%04x\r\n",index_p, 2,objData[2]);
                OSAL_printf("Download: 0x%04x:%d = 0x%04x\r\n",index_p, 3,objData[3]); 
            }
            else if(subindex_p == 1)
            {
                OSAL_MEMORY_memcpy((uint8_t*)&objData[1],(uint8_t*)pData_p, size_p);
                OSAL_printf("Download: 0x%04x:%d = 0x%04x\r\n",index_p, 0,objData[0]);
                OSAL_printf("Download: 0x%04x:%d = 0x%04x\r\n",index_p, 1,objData[1]);
                OSAL_printf("Download: 0x%04x:%d = 0x%04x\r\n",index_p, 2,objData[2]);
            }
        }
        else
        {
            if(subindex_p!=0)
            {
                OSAL_printf("Download Data: %04x\n\r",pData_p[0]);
                objData[subindex_p] = pData_p[0];
                OSAL_printf("Download: 0x%04x:%d = 0x%04x\r\n",index_p, subindex_p,objData[subindex_p]);
            }
        }
    Exit:
        return (uint8_t)error;
    }
    
    // Read callback - upload
    static uint8_t EC_SLV_APP_setValueFromMaster(void* pApplicationCtxt_p,uint16_t index_p,uint8_t subindex_p,uint32_t size_p,uint16_t MBXMEM * pData_p,uint8_t completeAccess_p)
    {
        EC_API_EError_t     error   = (EC_API_EError_t)ABORT_NOERROR;
    
        OSAL_printf("SDO Upload: %s ==> Idx: 0x%04x:%d | Size: %d  | access: %d\r\n", __func__,index_p, subindex_p, size_p, completeAccess_p);
    
        if (completeAccess_p)
        {
            if (subindex_p == 0)
            {
                OSAL_MEMORY_memcpy((uint8_t*)pData_p, (uint8_t*)objData, size_p);
            }
            else if (subindex_p == 1)
            {
                OSAL_MEMORY_memcpy((uint8_t*)pData_p, (uint8_t*)&objData[1], size_p);
            }
            else
            {
                OSAL_printf("Invalid SI for Complete Access -> 0x%04x:%d\r\n",index_p,subindex_p);
            }
    
            OSAL_printf("Upload: 0x%04x:%d = 0x%04x\r\n",index_p, 0,objData[0]);
            OSAL_printf("Upload: 0x%04x:%d = 0x%04x\r\n",index_p, 1,objData[1]);
            OSAL_printf("Upload: 0x%04x:%d = 0x%04x\r\n",index_p, 2,objData[2]);
            OSAL_printf("Upload: 0x%04x:%d = 0x%04x\r\n",index_p, 3,objData[3]);  
        }
        else
        {
            if(subindex_p == 0) // size will be 1
            {
                uint8_t *SI0_data = (uint8_t*)objData;
                OSAL_MEMORY_memcpy(pData_p, &SI0_data[subindex_p], size_p);
            }
            else
            {
                OSAL_MEMORY_memcpy(pData_p, &objData[subindex_p], size_p);
            }
    
            OSAL_printf("Upload Data: %04x\n\r",pData_p[0]);
            OSAL_printf("Upload: 0x%04x:%d = 0x%04x\r\n",index_p, subindex_p,objData[subindex_p]);
        }
    
     Exit:
        return (uint8_t)error;
    }


    I have observed that the test case TF-2302 is passed with 0 warnings.

    Kind Regards,