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.

SAFETI-HALCOGEN-CSP: Unit Test of FEE might be accessing data beyond the end of an array

Part Number: SAFETI-HALCOGEN-CSP
Other Parts Discussed in Thread: TMDX570LC43HDK, HALCOGEN,

Tool/software:

Hello,

We are running the HALCoGen CSP Unit Tests of the FEE module on a TMDX570LC43HDK Hercules TMS570LC43x Development Kit.

We are using HALCoGen 04.07.01 and SAFETI-HALCOGEN-CSP 04.07.01.

However, I get different statement coverage results to those obtained by a colleague.
The difference is due to TI_Fee_GlobalVariables[u8EEPIndex].bWriteFirstTime.
For instance in ti_fee_writeSync.c at line 503 "if(TI_Fee_GlobalVariables[u8EEPIndex].bWriteFirstTime!=TRUE)" always evaluates to false for me. i.e. bWriteFirstTime is always TRUE

bWriteFirstTime is set to TRUE on line 242 depending upon the result from the call to TI_FeeInternal_GetCurrentBlockAddress().

The call to TI_FeeInternal_GetCurrentBlockAddress() is passed u16ArrayIndex which comes from the call to TI_FeeInternal_GetArrayIndex() on line 200.

In TI_FeeInternal_GetArrayIndex() the value of u16ArrayIndex comes from 1415 of ti_fee_util.c which is "u16ArrayIndex += Fee_BlockConfiguration[u16LoopIndex].FeeNumberOfDataSets;".
For us the number of datasets is 1.

So, in TI_Fee_WriteSync() u16ArrayIndex is 1 when it is passed to TI_FeeInternal_GetCurrentBlockAddress().
Within TI_FeeInternal_GetCurrentBlockAddress() u16ArrayIndex becomes the BlockNumber and it is used in TI_Fee_GlobalVariables[u8EEPIndex].Fee_au16BlockOffset[BlockNumber];

For us the definition of Fee_au16BlockOffset is Fee_au16BlockOffset[TI_FEE_TOTAL_BLOCKS_DATASETS]; and #define TI_FEE_TOTAL_BLOCKS_DATASETS 1U


So, in summary for us a value of 1 is used as the index into an array of only one element. i.e beyond the end of the array.

Can you confirm whether or not my understanding is correct?

I have also noticed a difference between our HALCoGen generated code and the code shown in the test results that TI provide.

In ti_fee_util.c line 1406 is "for(u16LoopIndex=0U ; u16LoopIndex<TI_FEE_NUMBER_OF_BLOCKS ; u16LoopIndex++)"
But in the test results (ti_fee_util.dyn.htm#ti_feeinternal_getarrayindex_19) the same line is
5057 (1406) for 1 0 *** 1
5058 ( 1 0 *** 1
5059 u16LoopIndex = 0U 1 0 *** 1
5060 ; 1 0 *** 1
5061 u16LoopIndex < 16U 1 0 *** 1
5062 ; 1 0 *** 1
5063 u16LoopIndex ++ 1 0 *** 1
5064 ) 1 0 *** 1

i.e. 16U instead of TI_FEE_NUMBER_OF_BLOCKS

Do you know why there is a difference?

Thank you.

  • Hi Andrew,

    Apologies for the delay in late response, 

    I am working on your issue now and will try to post my updates as soon as possible.

    --
    Thanks & regards,
    Jagadish.

  • Hi Andrew,

    First of all, apologies for the late response. I was stuck with other issues in this mean time.

    Can we please setup one live debugging session, so that i can verify this issue in live. I am requesting this because of i don't have this setup.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    Thank you for your reply and your offer of a live debugging session.

    Unfortunately, my company will not allow a live debugging session.

    To help you debug the issue, below I have shown the extracts of the code that I suspect might be causing some of the unit tests to unexpectedly fail.

    I think that on line 2013 of ti_fee_util.c the index BlockNumber is beyond the end of the array.

    Thank you,

    Andrew