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.

MSPM0G1107: Invalid CRC Value when configuring NONMAIN with Debug Lock Policy / Password

Part Number: MSPM0G1107
Other Parts Discussed in Thread: SYSCONFIG, SEGGER

Tool/software:

I am trying to restrict the SW Debug Access using a password. However, when I flash the device using JFlash 7.96 I receive the following issue concerning the CRC value in NONMAIN:

Steps to Reproduce:

1. Set the Serial Wire Debug lock policy according to 1.5.2

2. Set SWD Password according to 1.5.4

As a test, I am using a dummy password: 00010203 04050607 08090A0B 0C0D0E0F



3. Here are the values in the compiled image at the correct addresses:

4. Try to erase the device but fail because NONMAIN sector is locked

5. Try to program the device device but CRC is incorrect

6. Tried to reverse engineer the default CRC32 digest value found at 1.5.15 but it's pretty much impossible to do if you don't know which address range or exact algorithm scheme you guys are using.




Questions:

1. How do you erase NONMAIN using JFlash without bricking the device?

2. Which exact address range(s) is being used to calculate the CRC for the BCR and BSL respectively?

3. Which exact CRC32 algorithm are you using to calculate the checksum?

4. How does TI expect us to calculate these CRC values ourselves?

5. We want to randomize the password and automate the process during CI/CD deployment, is there a python library/script you recommend that uses the same exact CRC scheme? If not, how would we be able to randomize the password, and then when compiling/linking populating those fields with the randomized words?

  • Hi Edward,

    Are you using our SysConfig tool? This will find the CRC for you with your given settings and password. You can do all your settings here then copy the files into your program if you don't want to use our SysConfig.

    Regards,
    Luke

  • Hey Luke!

    So this SysConfig tool seems useful I'll be sure to check it out but where is it located? In CCS? Seems like it will be useful for verifying our CRC in development time but this not helpful for our cause regarding Question 5

    We need a way to randomize the password and then place that password into NONMAIN. The CRC would have to be updated accordingly as well. The idea is we would run the same CRC32 algorithm and place them ourselves into NONMAIN. Doesn't seem like this is automate-able to be done during deployment (Jenkins / Cloudbess)

    We don't develop using CCS because we run WSL and Docker to manage all the different build environments we have. So CCS isn't the best for us. We do already use it for example code like you suggested

    For Question 4 is this the only way you guys expect us to generate the CRC?

    Also, please respond to Questions 1, 2, 3, and 5.

    Can we please schedule a call, I think the transfer of knowledge will go a lot quicker over a phone call and this is a high priority item for me and my team.

    Thanks,
    Eddie Devlin

  • Hi Edward,

    Let me check on the polynomial and configurations so I don't give you the wrong one.

    1. Segger - You need to erase the non-main and reprogram it, the behavior would be the same as a normal memory address, but do not reset or power cycle the device until non-main is programmed. If you have an erased device then you power cycle you won't be able to access it again.
    2. The respective registers for the BCR and BSL are what is utilized in the CRC check.
    3. Getting this information for you
    4. Once you have the CRC method you can generate it yourself
    5. We don't have a tool to do this, you will have to create your own method for randomizing the password.
      1. Creating a script to add the password and CRC into your hex file is a viable option

    Regards,
    Luke

  • Hey thanks so much the response, looking forward to those details.

    Question 2

    Specifically for the BCR, I'm aware that 0x41C0005C is the BOOTCRC digest value (look at #6 in Steps to Reproduce in the original post). The default value is 0x1879DAC3 which I have been struggling to arrive at on my own. Without knowing the exact address range you guys use, I'm just taking shots in the dark and feel like I'm wasting my time. Maybe I'm not looking at the right spot of the manual or it's not in there. I also would like information on the BSL configuration data as well, just in case

    I need:

    A) the start and end address you guys use to compute BOOTCRC value

    B) the start and end address you guys use to compute BSLCONFIGCRC value

  • Hi Edward,

    Here is the memory address for the BCR and BSL

    The length is from the ID register until the CRC of the same. This is in the G-Series technical reference manual NONMAIN registers.

    Regards,
    Luke

  • Hi Edward,

    Here are the parameters for the CRC. (The initial and final value is the input and output, this is dependent on your settings)

    Regards,
    Luke

  • Thanks for the CRC32 details - that Xor value is what we needed!

    Regarding Question 1

    We are still struggling to erase NONMAIN. In SEGGER JFlash we have enabled both sectors - MAIN and NONMAIN and have ran both the Erase Sectors (F3) and Erase Chip (F4) commands. Both cause this error:


    So it does not seem it is as simple as programming MAIN. How do we unlock this sector so we can erase it?

  • Hi Eddie,

    I took the gpio_toggle_output example and adjusted it to do the fast boot option (to get a new NONMAIN generated). I didn't have any issues flashing the non-main. My J-Flash version is 8.12 vs your 7.96, and I typically select the Production Programming option instead of individual erases on the sectors.