• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 119 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.

MSPM0G3507: MCU Locked (0x0036) Due to Empty NONMAIN – Is Our Workaround Correct?

Zq
Prodigy 130 points

Part Number: MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

Recently, during development, our MCU became locked and displayed 0x0036. It looks like the NONMAIN area became empty, so the device could no longer boot.

To prevent this from happening again, we are considering the following workaround. Could you please check whether our understanding is correct?

  1. Disable BSL
    By default, the BSL GPIO invoke pin is PA18. We are also using this pin as UART RX, so it might accidentally trigger BSL mode.

    One question: if I uncheck "Enable BSL", why is the GPIO invoke option still available?nvm.png

     

    Is it better to:

    • uncheck Enable BSL completely, or
    • keep Enable BSL checked but disable GPIO invoke only? like the following screenshoot. nvm2.png

  2. Flash erase option
    For debugging, we select "Erase MAIN and NONMAIN necessary sectors only" instead of "Erase MAIN and NONMAIN".

    Our understanding is that if Erase MAIN und NONMAIN is selected, the debugger first erases both MAIN and NONMAIN. If an error occurs before the new NONMAIN configuration is programmed, the NONMAIN area remains empty. Since the device cannot boot without a valid NONMAIN configuration, it may become permanently locked.

    Is this understanding correct?

  3. Do not program boot_config.c after the first successful programming
    After the initial programming, we exclude boot_config.c from subsequent debug downloads. This way, the valid NONMAIN configuration is preserved and will not be overwritten during later debug sessions.

 is that working to avoid this issue?

Thank you in advance :)

Best regards
Zq




  • 0
    Prodigy 130 points

    Hi there,

    is there any update? 

    Thanks in advance:)

    Best regards
    Zq

  • 0
    TI__Expert 8465 points

    Hi Zq,

    Your understanding is mostly correct, but there are several important distinctions.

    First, please confirm the complete 32-bit diagnostic value:

    • 0x00000036 means the NONMAIN configuration is invalid or erased. Once the device boots into this state, it is permanently unrecoverable.
    • 0x00010136 indicates a NONMAIN CRC verification failure and is not identical to 0x00000036.

    If the diagnostic is exactly 0x00000036, the MCU must be replaced.

    1. BSL configuration

    Because PA18 is being used as UART RX, its normal idle level is high. If the default BSL hardware-invoke check is enabled, PA18 being high during a POR or sufficiently long reset can unintentionally invoke the ROM BSL. The preferred configuration depends on whether the product still needs BSL functionality:

    • Keep “Enable BSL” selected and disable “BSL Invoke Pin Check” when you want to retain software BSL invocation or a possible firmware-update path, but do not want PA18 checked during boot.
    • Disable “Enable BSL” completely only when the product will never use the ROM BSL. This disables both hardware and software BSL invocation.

    The GPIO-invoke settings can remain visible in SysConfig even when BSL is disabled because the underlying pin-configuration fields still exist. However, the global BSL enable setting takes precedence, so those fields have no functional effect while BSL mode is disabled. For this application, I recommend leaving BSL enabled but disabling the BSL invoke-pin check, unless there is a security or product requirement to disable BSL completely.

    2. Flash erase option

    Your understanding of the full erase risk is correct.

    “Erase MAIN and NONMAIN memory” erases both regions. If programming is interrupted after NONMAIN is erased but before a complete, valid NONMAIN image and CRC are restored, the next boot can produce diagnostic 0x00000036. TI explicitly warns that an erased NONMAIN region left unprogrammed locks the device permanently. “Erase MAIN and NONMAIN necessary sectors only” is safer because it erases only sectors represented in the output image. However, it does not completely eliminate the risk:

    • If the output file contains the generated NONMAIN section, the NONMAIN sector will still be erased and rewritten.
    • A power loss, reset, debugger disconnection or programming failure during that operation could still leave NONMAIN invalid.

    The CCS flash-loader documentation confirms that the “necessary sectors only” option erases any MAIN or NONMAIN sector that is being updated.

    A safer development workflow is:

    1. Program the required NONMAIN configuration once under controlled conditions using stable target power.
    2. Verify that the device boots correctly and read back the configuration when possible.
    3. Remove NONMAIN content from normal development images.
    4. Use a MAIN-only erase option for subsequent application debugging.
    5. Do not reset or remove power while NONMAIN is being erased or programmed.

    Avoid using “Erase MAIN and NONMAIN memory” for normal application downloads.

    3. Excluding boot_config.c

    Yes, excluding boot_config.c after the initial successful NONMAIN programming can prevent subsequent debug downloads from rewriting NONMAIN. However, this is safe only when all of the following are true:

    • The linker output contains no other section located in NONMAIN.
    • The selected flash-loader erase option does not erase NONMAIN independently.
    • The existing NONMAIN configuration is already valid.
    • Future SysConfig regeneration does not automatically add boot_config.c back into the build.

    Do not rely only on the source-file exclusion checkbox. Check the linker map or generated TI-TXT/HEX file and confirm that the normal application image contains no NONMAIN addresses.

    The recommended project organization is to create two build configurations:

    • Provisioning build: Includes boot_config.c and programs the complete SysConfig-generated NONMAIN image.
    • Development build: Excludes all NONMAIN sections and erases/programs MAIN only.

    Keep the known-good boot_config.c, SysConfig file and generated NONMAIN programming image under version control. Do not delete them, because they will be needed if the configuration must be reproduced on another device.

    So your thinking is mostly correct here, I would just add with these recommendations:

    • Disable the hardware BSL invoke-pin check, rather than disabling the complete BSL, if software BSL updates are still required.
    • Use “necessary sectors only” only for the controlled programming of NONMAIN.
    • Use a MAIN-only erase configuration for normal debugging.
    • Exclude boot_config.c from the normal application build and verify that the resulting image contains no NONMAIN data.
    • Never erase NONMAIN unless a complete, valid replacement configuration is ready to be programmed immediately.

    Hope this helps 

    -Brian