• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 302 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

MSP430FR2433: Trouble programming memory through BSL using Uniflash

MSP430F67791A: Password CRC verification fail when using UniFlash BSL

Eric Watson
Prodigy 10 points
Part Number: MSP430F67791A
Other Parts Discussed in Thread: UNIFLASH, MSP-FET

Tool/software:

We are having some problems with password CRC verification when programming the MSP430F67791A using UniFlash in BSL (Bootloader) mode.

This is very similar to the following ticket:

MSP430FR2433: Trouble programming memory through BSL using Uniflash

Tools/Equipment Used

  • UniFlash version(s): 8.1.1.4146 and 9.0.0.5086 (older and the also the latest version show the same issue)
  • MSP-FET debugger/programmer
  • MSP430F67791A

Description

Hopefully the following example highlights the issue:

  • Program the device using UniFlash, with a JTAG interface (password is not required).
    • The hex data of the program is known.
    • The password data at 0xFFE0 is known.
    • The software we loaded is V1.0
  • Disconnect UniFlash and the MSP-FET programmer and check the program runs
    • No problems and the program runs as expected.
  • Connect the MSP-FET programmer and program the device again using UniFlash, but this time using BSL (Bootloader) mode (password is required).
    • The hex data of the program is known and different to V1.0
    • The password data at 0xFFE0 is known and is different to V1.0
    • The software we loaded is V1.1
  • The verification fails when the BSL checks address 0xFE00, which is the location of the password data.

Passwords

V1.0 password data is as follows:

@FFE0
E0 C0 DE C0 FF FF FF FF DC C2 7E C2 DC C0 B0 C1
84 C0 38 C0 FF FF 20 C2 FF FF FF FF FF FF 00 C0
q

V1.1 password data is as follows:

@FFE0
E0 C0 DE C0 FF FF FF FF E0 C2 82 C2 DC C0 B0 C1
84 C0 38 C0 FF FF 24 C2 FF FF FF FF FF FF 00 C0
q

As expected, some bytes are different between the 2 passwords.

UniFlash Settings

"test_V1.0.txt" was already loaded at this point and we select the password file for V1.0 software.

"test_V1.1.txt" is selected to be loaded into the device, which will overwrite V1.0 software.

My understanding is that the selected Password file must match the password data currently programmed into the device - so in this case the password data for V1.0 software.

CRC Failure

When the device is programmed with V1.1 software and verified, there is a failure at address 0xFFE0, which is the password address:

[2/10/2025, 6:55:02 PM] [ERROR] MSP430: CRC check at 0xFFE0 does not match; expected value: 0xA366 obtained from BSL: 0xFB55
[2/10/2025, 6:55:02 PM] [INFO] MSP430: [80] [06] [00] [16] [E0] [FF] [00] [20] [00] [3C] [EF]
[2/10/2025, 6:55:02 PM] [INFO] MSP430: {00}{80} {03} {00} {3A} {55} {FB} {C6} {61}

UniFlash expects the password CRC to be 0xA366, but the device's Bootloader calculates and returns 0xFB55.

I decoded the transfer to/from the device using the MSP430 Flash Devices Bootloader (BSL) document, which shows the command and response as follows:

  • Command from UniFlash: [80] [06] [00] [16] [E0] [FF] [00] [20] [00] [3C] [EF]
    • 80 = Header
    • 60 00 = 0x0006 (bytes in packet)
    • 16 = "CRC Check"
    • E0 FF 00 = 0x00FFE0 (address)
    • 20 00 = 0x0020 (length i.e., 32 bytes which is the password length).
    • 3C EF = 0xEF3C (packet checksum)
  • Response from MSP430: {00} {80} {03} {00} {3A} {55} {FB} {C6} {61}
    • 00 = ACK from MSP430 indicating command packet is valid
    • 80 = Header
    • 03 00 = 0x0003 (bytes in packet)
    • 3A = "CRC Value"
    • 55 FB = 0xFB55 (CRC calculated by MSP430 Bootloader)
    • C6 61 = 0x61C6 (packet checksum).

So, UniFlash uses the password file for "test_V1.0.txt" software (which is currently loaded into the MSP430) and verifies that the password matches the currently loaded software (PASS).

Then the new software "test_V1.1.txt" is programmed into the MSP430 (PASS).

Then the verification (memory check) stage happens (FAIL), where the password check fails.

CRC Calculation

I used the the online crccalc tool to calculate the expected CCITT CRC for the old and new passwords.

V1.0 (old) password = 0xA366

V1.1 (new) password =  0xFB55

Conclusion

I think that the UniFlash tool uses the provided password file data to check against the currently loaded software (OK), but also uses it to check against the new software being loaded (not OK).

This is partly based on the console output from UniFlash when in "verbose" mode:

[2/10/2025, 6:55:02 PM] [ERROR] MSP430: CRC check at 0xFFE0 does not match; expected value: 0xA366 obtained from BSL: 0xFB55

When verifying the new code, it expects the CRC to be 0xA366 (but this is the old password CRC) and obtains 0xFB55 from the device (this is the correct, new CRC).

Is UniFlash using the old password's CRC to check against the new programmed password data?

Hopefully that all makes sense,

Thanks

  • 0
    TI__Expert 5380 points

    Hi Eric,

    I will check internally about the Uniflash password CRC verification logic. A question about your application:

    Is it a necessary requirement that the old image and new image use different password?

    Best Regards,

    Pengfei

  • 0 in reply to Pengfei Xie
    Prodigy 10 points

    Hi Pengfei,

    Thank you for your quick response.

    It depends on what the differences are between the old and new software versions.

    Because the password data is effectively the addresses of the interrupt vectors in the software, the password data often changes, depending on what has been modified in the new software release.

    To ensure the password is always the same, I think we would have to hard-code the addresses of each interrupt vector, which is not our preferred option.

    Best Regards,

    Eric

  • 0 in reply to Eric Watson
    TI__Expert 5380 points

    Hi Eric,

    Thanks for your information. I will check internally.

    Best Regards,

    Pengfei

  • 0
    TI__Mastermind 38595 points
    Eric Watson said:
    Then the verification (memory check) stage happens (FAIL), where the password check fails.

    Have you change the password of test_V1.1.txt when you try to download at the second time?

    Due do the password is located at the address of the interrupt table if a new firmware be downloaded for the interrupt table normally changed, so you need different password to access the BSL

  • 0 in reply to Gary Gao
    Prodigy 10 points

    Hi Gary,

    Thanks for your question.

    I think the only way UniFlash will indicate a successful "verification" of programmed software into an MSP430 is either:

    • The 32-byte password of the new software matches the 32-byte password of the old software (interrupt vector values).
      • When UniFlash tries to program the MSP430, it will check the provided password file against the 32 bytes currently loaded in the MSP430.
      • When UniFlash has completed programming the new software, it uses the same password file to verify the new 32 bytes in the MSP430.
      • If the 32-byte password data (interrupt vector values) never change, the verification will always pass.
      • If the 32-byte password data does change between old and new MSP430 software, the verification stage will always fail.
    • Program the software twice. In the following example, I'll assume the 32-byte password data changes between V1.0 and V1.1 MSP430 software.
      • V1.0 software is already loaded in the MSP430.
      • Provide UniFlash with the password file for V1.0 (required to unlock access to the MSP430 when V1.0 software is loaded).
      • Use UniFlash to program V1.1 software into the MSP430.
      • UniFlash programs V1.1 software into the MSP430 (PASS, because the password matched the previously loaded software i.e., V1.0)
      • UniFlash verifies the password data for the newly loaded software (V1.1) against the provided password file (FAIL - the password data has changed).
      • Now provide the new password file to UniFlash (for V1.1 software).
      • UniFlash programs V1.1 software into the MSP430 again (PASS, because the password matched the software that was already in the MSP430 i.e., V1.1)
      • UniFlash verifies the password data for the newly programmed software (V1.1) in the device using the new password (PASS)

    For the first point, we can't really assume that that interrupt vector data never changes, and therefore we can't assume the password never changes.

    For the second point, programming the software twice (firstly using the password for the old file, secondly using the password for the new file) will finally result in UniFlash providing no verification errors (the first time it will provide an error), but this seems very much like a workaround. Based on my analysis (original post), UniFlash programs the software into the device correctly, but the "verification" check fails, and I believe it fails because it's not verifying against the correct 32 bytes of data (old vs new).

    I believe the process should be this:

    • Provide the new software file to UniFlash (V1.1)
    • Provide the password file for the software currently loaded into the MSP430 (for V1.0)
    • UniFlash uses the password file for V1.0 software to gain access and program V1.1 software into the MSP430.
      • UniFlash already does this correctly.
    • UniFlash then determines the password data for the new software (V1.1).
      • It can read this from the V1.1 software file.
      • (instead of using the old password file to check the newly loaded password data)
    • UniFlash verifies the newly programmed software (V1.1) against the newly determined password data.

    Anyway, that's my understanding of the current UniFlash behaviour versus what I think it should do.

    But I could be wrong - I hope the post made sense.

    Best Regards,
    Eric

  • 0 in reply to Eric Watson
    TI__Mastermind 38595 points

    I think you are right, for a more reliable way is that you can capture the wave form directly by a logic analyzer like saleae that will be more clear.  

**Attention** This is a public forum