• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 174 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSPM0G3519: MSPM0-DIAGNOSTIC-LIB compile error: use of undeclared identifier 'DL_CRC_32_POLYNOMIAL'

Chris Yorkey
Genius 15855 points
Part Number: MSPM0G3519
Other Parts Discussed in Thread: MSPM0G3507, MSPM0L1306

Tool/software:

Team,

Our customer tried to compile DiagLib for MSPM0G3519 with mspm0_sdk_2_04_00_06 and got this

 

../../Appl/Src/DiagLib/src/source/flash_test.c:433:23: error: use of undeclared identifier 'DL_CRC_32_POLYNOMIAL'

  433 |     DL_CRCP_init(CRC, DL_CRC_32_POLYNOMIAL, DL_CRCP_BIT_NOT_REVERSED,

      |                       ^

../../Appl/Src/DiagLib/src/source/flash_test.c:464:5: warning: call to undeclared function 'DL_CRC_disablePower'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]

  464 |     DL_CRC_disablePower(CRC);

      |     ^

1 warning and 1 error generated.

 

Compile options:

 

-march=thumbv6m

-mcpu=cortex-m0plus

-mfloat-abi=soft

-mlittle-endian

-mthumb

-gdwarf-3

-save-temps=obj

-D__MSPM03519__

-c

 

  • MSPM0G3519 has CRCP but DL_CRC_32_POLYNOMIAL seems to only be defined in dl_crc.h and not in dl_crcp.h.
  • Line 464 has incorrect reference to DL_CRC_disablePower(CRC) rather than CRCP.

 

Claim is that Diaglib supports MSPM0G3519 but it may not seem to be so in its entirety? Customer was not sure if they should post this on E2E as access is restricted at this time.

I have posted as a TIer.

 

Regards,

CY

  • 0
    TI__Genius 15855 points

    Team,

    There seems to maybe be another issue with the library.

    In cpu_test.asm

     

    MSPM0_DIAG_cpuTest:

         /* Store R0 and R1. R0 and R1 contains the pointer to CPU test struct and

         * CPU test result

         */

         PUSH   {R0-R1,R4-R7}

         /* Determine if fault injection is enabled */

         LDR    R3, [R0] <- this is word read and address in R0 shall be word aligned.

     

    However, when tiarmclang -fshort-enums option is used (which is default) then the address of the first parameter cpuTestConfig in the call

     

    MSPM0_DIAG_cpuTest(&cpuTestConfig, &cpuTestResult);

     

    may not be word aligned because enumeration MSPM0_DIAG_test_inject_fault is byte sized. LDR R3,[R0]will result in Hard Fault.

    We do not see that there is a requirement to word align cpuTestConfig structure or use -fno-short-enums.

     

    Does the above make sense or are we missing something here?

    TY,

    CY

  • 0 in reply to Chris Yorkey
    TI__Expert 8395 points

    Hi Chris,

    Do you know which diag library version is customer using? And where are they apply this library from?

    And let me answer the CRC question firstly:

    I think this CRC problem is caused by that MSPM0G3507 uses CRC module but MSPM0G3519 uses CRCP module instead. So if we directly migrate MSPM0G3507 project to G3519 device, the CRC part may have such problem. A simple way is to just correct "CRC" to "CRCP" for both CRC API and instance.

    Regards,

    Pengfei

  • 0 in reply to Pengfei Xie
    TI__Genius 15855 points

    Hi Pengfei,

    From customer:

    "

     

    MSPM0 Diagnostics Library 0.90.00.01 released on August 04, 2023

    MSPM0 SDK 2.04.00.06

    TI ARM Clang 4.0.2.LTS

     

    Build does not use Composer Studio but rather CLI with options from the library documentation.

     

    From the documentation it could be inferred that the library should be used as is rather than a reference implementation when user is free to modify the code..

     

    Note that the MSPM0 Diagnostics Library 0.90.00.01 has not undergone any third-party assessment or certification to a particular standard. However, MSPM0 Diagnostics Library 1.0.0.xx or later followed Texas Instruments internal software development for Functional Safety Quality process which has been certified to meet a Systematic Capability up to SIL-3 and ASIL-D.

     

    The claim is that library supports and I assume was tested for all devices listed here MSPM0-DIAGNOSTIC-LIB Driver or library | TI.com. Apparently, this is not the case for MSPM0G3519. Then, what is behind the claim about quality compliance? Can this library be fully trusted for use in safety devices incl the G3519?

     

    In addition, I do not see any FLASH or RAM ECC circuit tests which could be required for safety devices.

    "

    Thank you in advance for any guidance here.

    Regards,

    Chris

  • 0 in reply to Chris Yorkey
    TI__Genius 15855 points

    Pengfei - also one additional question if we may:  How to test RAM that is allocated to stack with this library? The whole library is in C and even noon-destructive test uses stack which is being modified by the test.  ?

    TY,

    Chris

  • 0 in reply to Chris Yorkey
    TI__Expert 8395 points

    Hi Chris,

    To be clarified, the MSPM0 "diagnostic library" is designed for IEC60730 standard (target at Class B). And for ISO26262, there is another "safety library" to support ASIL-B level for MSPM0G3519 device. Sorry for the confusing because of these early description. 

    For the diagnostic library, we have an internal 1.0 version which has got TUV IEC60730 Class B certification. I will send it to you by email. But it only support MSPM0G3507 and MSPM0L1306 devices, and for MSPM0G3519 diagnostic library development, it may not in a high priority currently.

    Could you please check with customer which one do they need? The IEC60730 or ISO26262.

    I think we could take further communication on this by email.

    Best Regards,

    Pengfei