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.

TMS320F28027: test wrong when call STL_generateCrc()

Part Number: TMS320F28027
Other Parts Discussed in Thread: CONTROLSUITE

Hi Expert,

there have an issue when run the example code from the below path,  when call this function  STL_generateCrc(), the result of gStructCrcResult is all 0 as below showed which does not match the expected value, and the crc check status is fault, could you help take a check if any wrong?

C:\ti\controlSUITE\libs\IEC60730_safety\v4_00_01_00\examples\f2802x

  • Hi Expert,

    The above test is done when insert an breakpoint in software, if remove the breakpoint, the result is different, but the status is still reported test fault.

  • Hi Expert,

    The above test is done when insert an breakpoint in software, if remove the breakpoint, the result is different, but the status is still reported test fault.

  • Hi Strong,

    I'm looking into this. I'll get back to you tomorrow.

    Whitney

  • Unfortunately I don't have an F2802x board with me to try this out myself at the moment. Which of the the CRC tests is the error coming from? Can you look at the SCI output or right click on the gStructCrcResult struct and change the number format to hex so you can more easily compare it to the values in gGoldenCRC?

    Whitney

  • Hi Whitney,

    Could you help reproduce this issue at F2803x? my customer have found the same issue with this example.

    C:\ti\controlSUITE\libs\IEC60730_safety\v4_00_01_00\examples\f2803x

    There are two issue for this:

    1. insert a breakpoint in software, gStructCrcResult value will be zero, which is not correct.

    2. without insert a breakpoint, gStructCrcResult value are correct compared to gGoldenCRC value, but the status return is still false.

    Could you help reproduce this issue on board? CCS version is CCS10.1, Thanks.

  • Where are you putting the breakpoint that is causing the failure? Is it all breakpoints are just certain locations?

    I don't have an F2803x board with me either. I'll try to make some arrangements to get one early next week.

    Whitney

  • Hi Whitney,

    you can insert the breakpoint after this function or inside this function, the compiler is TI 6.1.0,  ccs is 10.1.

    void STL_generateCrc(void)

    look forward to your update, Thanks.

  • Thanks. I've made arrangements to get an F2802x board. I'll try it out and get back to you tomorrow.

    Whitney

  • Hi Strong,

    I got was able to try this out and I'm seeing similar failures for most of the CRC tests that call STL_CRC_TEST_testNvMemory(). I don't think this is entirely expected though. See section D.1.2 in the User Manual:

    The simple app calls a function that checks a CRC checksum on all invariable memory. This includes flash and OTP. The content of the OTP could be different for different silicon. Do the following steps if there is a CRC checksum error or if any part of the application or IEC60730 STL library code is modified.

    1. Import and rebuild the simple app example.
    2. Run the app with emulator with no breakpoints for at least 1 minute (to ensure the STL_generateCrc() function is run.
    3. The newly generated CRC values will be populated in gStructCrcResult structure (in main.c). Use watch window to see the newly calculated CRC values. The golden CRC values passed on to the CRC check are defined in gGoldenCRC array (in STL_TEST_REPORT.c). Copy the newly populated CRC values from gStructCrcResult to the corresponding array cell in gGoldenCRC.

    Like the above documentation says, any difference in silicon between what you are using and what was used to test this demo application may result in a different result. Also there may be some differences in how the code compiled between your environment vs the one where the original example was built and the golden CRCs were generated that could explain why the flash tests fail.

    You can see the note about no breakpoints--I suspect they interfere with the PSA.

    Whitney

  • Hi Whitney,

    Thanks for your update.

    if no breakpoint, the result of gStructCrcResult is correct, but the return status is wrong, which is 0x245E. could you also take a check whatit is wrong?

    status = STL_CRC_TEST_testSafeRam((uint32_t *)0x8AB0,(uint64_t *)&gStructCrcResult.pcTest1Crc,RAM_TYPE_PC_TEST_1);

     

     

  • The only valid return values for STL_CRC_TEST_testSafeRam are SIG_RAM_CRC_TEST (0xA02E) and TEST_FAILED (0). Can you explain how and where you're checking the value of status? Are you putting an ESTOP0 at the end of STL_generateCrc() or are you running some other code?

    I haven't been able to reproduce this--it returns SIG_RAM_CRC_TEST as expected for me.

    Whitney

  • Hi Whitney,

    Thanks you, I find the issue, the variable is wrong because is overwritten by other function later.