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.

MSPM0-DIAGNOSTIC-LIB: RAM Test & FLASH Test Questions

Part Number: MSPM0-DIAGNOSTIC-LIB
Other Parts Discussed in Thread: MSPM0G1106

Tool/software:

Hi,

I'm trying to integrate the diagnostic tests provided by TI (mspm0_diag_lib_0_90_00_01). Specifically, I'm using the example project for the LP-MSPM0G3607, as it's the closest match to the microcontroller I'm using, MSPM0G1106, for my project.

Question 1: RAM Test

In the file test_config.c, the macro SAFE_BUFFER_SIZE doesn't appear to be defined anywhere in the project hierarchy. Is it up to the user to define and use this macro, or is it supposed to be defined elsewhere in the code that isn’t included in this file?

Also, is it the programmer's responsibility to create the ".RAMsafeBuff" section via the linker command file of the project in advance for the following code to work?

/* test_config.c */

PLACE_IN_MEMORY(".RAMsafeBuff")
uint32_t safebuffer[MSPM0_DIAG_RAM_SAFE_BUFF_NUM_OF_WORDS_TO_TEST];

Question 2: FLASH Test

Similarly, is it the programmer's responsibility to create the ".FLASHTestCRC" section via the linker command file of the project in advance for the following code to work?

/* test_config.c */

PLACE_IN_MEMORY(".FLASHTestCRC")
const uint32_t FLASHTestgoldenCRC = MSPM0_DIAG_FLASH_EXPECTED_CRC;

Also, according to the following portion of the code, it looks like you are calculating the CRC over the first 16380 words (i.e., 65,520 bytes), leaving the last 4 words (i.e., 16 bytes) unincluded. Is this to store the 4-byte CRC value somewhere in that region? How and when (before flash OR after flash) was the expected CRC value 0x52A05524 calculated?

/* test_config.h */

/*******************************************************************************
 * FLASH Test configuration
 ******************************************************************************/
#define MSPM0_DIAG_FLASH_FAULT_INJECTION (MSPM0_DIAG_test_inject_fault_false)
#define MSPM0_DIAG_FLASH_START_ADDR ((uint32_t *)0x00000000)
#define MSPM0_DIAG_FLASH_NUM_OF_WORDS (16380)
#define MSPM0_DIAG_FLASH_GOLDEN_CRC ((uint32_t *)&FLASHTestgoldenCRC)
#define MSPM0_DIAG_FLASH_EXPECTED_CRC ((uint32_t)0x52A05524)

I'd appreciate any guidance on this.

Thank you,

Kyungjae Lee

  • Hi Lee,

    Question 1: RAM Test

    1. Yes, the size is depends on customer selection.

    2. Yes, user should creat the related memory section in cmd, our example project should give a good example.

    Question 2: FLASH Test

    1. Yes, cmd should be customized.

    2.Yes, tthe flash data and CRC reference value both are loaded in the FLAST_TEST_CRC, and reference value excluded from the CRC check. Use the calculated one to judgement.

    B.R.

    Sal

  • Hi Sal,

    Thank you for the clarification. Here are some follow up questions:

    • [RMA Test]
      Based on my understanding of the non-destructive RAM test implemented in ram_test.c, the process is as follows: it first performs the test on a user-defined safe buffer, then copies the RAM area to be tested into the safe buffer, performs the RAM test on the target area, and finally restores the original contents by copying the data back from the safe buffer to the RAM.
      Could you confirm if this understanding is correct?

    • [RAM Test]
      Aside from ensuring that the safe buffer is larger than the RAM area to be tested, are there any other considerations when defining the safe buffer size? Since I’ll be running the test in non-destructive mode, can I choose any size as long as the combined size of the RAM area to be tested and the safe buffer does not exceed the total available RAM?
      (I'm aware that the larger the RAM area to be tested, the longer the test will take, but let's set that aside for now.)

    • [FLASH Test]
      Are there any other considerations when defining the FLASHTestCRC section in the linker command file, besides ensuring that it does not overlap with the area of FLASH over which the CRC will be calculated?

    • [FLASH Test]
      Is the expected CRC value pre-calculated from the .bin file (for example, using a separate Python script)? I'm asking because I noticed that unused bits are padded with zeros in the .bin file. However, after loading the .bin file onto the target, those unused areas appear as all 1s (i.e., 0xFF). This makes me unsure how the CRC calculated from the .bin file can match the one calculated directly from the FLASH contents on the target. Is there a recommended way to calculate the expected CRC?

    Thank you,

    Kyungjae Lee

  • Hi Lee,

    See the comments below:

    Could you confirm if this understanding is correct?

    Yes, that is correct.

    Aside from ensuring that the safe buffer is larger than the RAM area to be tested, are there any other considerations when defining the safe buffer size? Since I’ll be running the test in non-destructive mode, can I choose any size as long as the combined size of the RAM area to be tested and the safe buffer does not exceed the total available RAM?
    (I'm aware that the larger the RAM area to be tested, the longer the test will take, but let's set that aside for now.)

    No, we do not have limitation on the safety buffer length selection.

    [FLASH Test]
    Are there any other considerations when defining the FLASHTestCRC section in the linker command file, besides ensuring that it does not overlap with the area of FLASH over which the CRC will be calculated?

    No.

    Is the expected CRC value pre-calculated from the .bin file (for example, using a separate Python script)? I'm asking because I noticed that unused bits are padded with zeros in the .bin file. However, after loading the .bin file onto the target, those unused areas appear as all 1s (i.e., 0xFF). This makes me unsure how the CRC calculated from the .bin file can match the one calculated directly from the FLASH contents on the target. Is there a recommended way to calculate the expected CRC?

    If user do not manually filled the value in the bin files, actually it is empty and will not load any value to the empty flash address. The empty flash address is read as 0xFF.

    I have two ideas for this scenaros:

    1. You can manually fill the given value to the .bin files, so that all the flash address has its value in .bin files.

    In cmd files, we can add --fill to fill the data, example refer to below:

        FLASH           (RX)  : origin = 0x00000000, length = 0x00020000, fill = 0xffffffff

    Then, the unused flash address will be filled with 0xFFFFFFFF.

    2. Also, you can do some modification to calculate the CRC with .bin files -> use 0xFF with the empty flash address. 

    B.R.

    Sal

**Attention** This is a public forum