• State
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 18 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

MSPM0G3507: Question about Secondary BSL and NVM Configuration

MSPM0G3507: secondary BSL developing workflow, device locked

Zq
Prodigy 80 points
Part Number: MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

Hi there,

I am currently working on a secondary BSL implementation on the MSPM0G3507 to perform firmware update.

Today I encountered an issue where the microcontroller became permanently locked. The register reads 0x0036, and the NOMAIN region appears to be erased, resulting in a permanent lock. 

I would like to ask for clarification on the following points:

  1. I had enabled NOMAIN static write protection. However, NOMAIN was still erased, looks not be protected. Is this protection expected to prevent erase operations? During development or debugging, are there any additional settings or precautions that should be enabled to avoid accidentally erasing NOMAIN and locking the device?

  2. For the MAIN region, my understanding is that the static write protection should be configured as 0xFFFFF00F according to where we put the secondary bsl code. is that right? should i also configure it during developing?

  3. Regarding the debug erase configuration, I had configured both MAIN and NONMAIN sectors. Could this configuration allow NOMAIN to be erased during debug operations even if static protection is enabled?

The secondary BSL itself is flashed in the MAIN region, and to protect it from being overwritten, I understand that MAIN static write protection must be configured correctly. However, the configuration registers related to BCR and BSL are located in the NOMAIN region. If these registers are written incorrectly or if NOMAIN is erased, the device becomes permanently locked.

Is my understanding correct?

I have read a large amount of official NVM documentation and several related forum threads, but I could not find clear development guidelines or best practices on how to avoid permanently locking the device when developing a secondary BSL.

Could you please provide recommendations or a suggested development workflow to safely develop and debug a secondary BSL while minimizing the risk of erasing NOMAIN or permanently locking the device? 

Thank you for your support.

Best regards,
Zq

  • 0
    TI__Mastermind 27595 points

    Hi Zq,

    Zq said:
    Today I encountered an issue where the microcontroller became permanently locked. The register reads 0x0036, and the NOMAIN region appears to be erased, resulting in a permanent lock. 

    Yes, if read back with 0x0036, NONMAIN is empty.

    Zq said:
    I had enabled NOMAIN static write protection. However, NOMAIN was still erased, looks not be protected. Is this protection expected to prevent erase operations? During development or debugging, are there any additional settings or precautions that should be enabled to avoid accidentally erasing NOMAIN and locking the device?

    No, if NONMAIN static protected, the flashloader can not erase NONMAIN anymore. While, the factory reset command generated by DSSM can overwrite the static protection and can erase NONMAIN and program default NONMAIN parameter.

    Zq said:
    For the MAIN region, my understanding is that the static write protection should be configured as 0xFFFFF00F according to where we put the secondary bsl code. is that right? should i also configure it during developing?

    Yes, I suggest you configure it in case you erase it incidentally. 

    Zq said:
    Regarding the debug erase configuration, I had configured both MAIN and NONMAIN sectors. Could this configuration allow NOMAIN to be erased during debug operations even if static protection is enabled?

    No, only factory reset can recover it to default state.

    Zq said:

    The secondary BSL itself is flashed in the MAIN region, and to protect it from being overwritten, I understand that MAIN static write protection must be configured correctly. However, the configuration registers related to BCR and BSL are located in the NOMAIN region. If these registers are written incorrectly or if NOMAIN is erased, the device becomes permanently locked.

    Is my understanding correct?

    Yes.

    Zq said:
    Could you please provide recommendations or a suggested development workflow to safely develop and debug a secondary BSL while minimizing the risk of erasing NOMAIN or permanently locking the device? 

    In development stage, modify NONMAIN once, and static protect it (optional).

    Remain secondary bsl unprotected in NONMAIN for development usage. During the development, the NONMAIN can remained unchanged, so remove the NONMAIN configruation from the project, then you will never prorgam NONMAIN again.

    Note: you can exculde the boot_config.c from build, then NONMAIN setting is reamined in sysconfig, but will not participate in the build.

    I also recommend you choose below to avoid erase NONMAIN accidentally:

    After secondary BSL project developed well, do factory reset and then program the final NONMAIN to protect secondary bsl.

    I think this can maximum reduce the risk of NONMAIN empty.

    BTW, for NONMAIN, there has a UG for your reference: MSPM0 NONMAIN Flash Memory Configuration Guide.

    B.R.

    Sal