• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 1939 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.

MSPM0L1306: Configuration of NONMAIN - BCR and BSL

Jens G
Expert 3335 points
Part Number: MSPM0L1306
Other Parts Discussed in Thread: SYSCONFIG, CODECOMPOSER, UNIFLASH

Hi team,

because we are using I2C in our application, we have pull-up resistors connected to those pins. As far as we saw in the default configuration this causes the device to enter BSL and that is unwanted in our project. Therefore we wanted to disable the BSL from NONMAIN section configurations, by writing the BOOTCFG2 location. We observed that the given data is not written in the Flash location.

 My current assumption is that this is because we didn’t write a correct CRC for the BCR region and this triggered the incorrect NONMAIN BCR recovery procedure (that re-erases the BCR).

 

Could you:

  • Provide the details used for CRC validation (Polynomial, initial value, final xor) so that we can generate a correct CRC signature
  • Confirm how exactly can we disable the BSL.
  • 0
    TI__Mastermind 28075 points

    Hi Jens,

    Jens G said:

    because we are using I2C in our application, we have pull-up resistors connected to those pins. As far as we saw in the default configuration this causes the device to enter BSL and that is unwanted in our project. Therefore we wanted to disable the BSL from NONMAIN section configurations, by writing the BOOTCFG2 location. We observed that the given data is not written in the Flash location.

    In early sample devices it is not recommended to touch Non-main memory, as it is very easy to lock yourself out of the device. I also believe you have to erase and unprotect the non-main flash before trying to write to it (see below). How did they try to execute this write operation? 

    In production devices with the production SDK disabling this will be possible without as much risk, and in fact can be done through SysConfig via a checkbox.

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 30 points

    Hi Brandon,

    I'm part of the team that tries to disable the BSL access:

    • the debugger tool that we use is Lauterbach
    • we intend to disable the BSL completely by writing BOOTCFG2= 0x5566AABB
    • for this we used the default values for the entire BCR segment (41C0.0000h 41C0.005Bh) with the new BOOTCFG2 value detailed above
    • for BCR CRC we used CRC-32 according to IEEE with the public polynomial

    We failed to write the BOOTCFG2 value and we need to understand why: either the CRC is wrong, or we are missing steps. From what you wrote above a mass erase is needed. In our memory dump the BOOTCFG2 is 0xFFFFFFFF, does this still need an erase before?

    We also tried MASSERASE and FACTORYRESET in CodeComposer environment using XDS110 debugger but for unknown reasons it fails with :

    Any idea to try on our setup?

    Thanks,

    Daniel

  • 0 in reply to Daniel Ciocea
    TI__Mastermind 28075 points

    Hi Daniel,

    What version of silicon are you using? I suspect they are early samples, this thread tells you how to identify if this is the case: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1204644/faq-mspm0-sdk-important-note-for-early-mspm0-customers

    Daniel Ciocea said:

    We also tried MASSERASE and FACTORYRESET in CodeComposer environment using XDS110 debugger but for unknown reasons it fails with :

    Any idea to try on our setup?

    Are these the devices where you have modified NONMAIN memory? If so they may be unrecoverable, which is part of why we don't recommend modifying non-main in early sample devices. 

    You could also see this message if the devices are just blank, as they will boot into BSL Mode, and then timeout into a Low Power Mode if after 10 seconds no connection attempt is made. On production devices you will still be able to connect when that timeout occurs, but on early samples you will see this message.

    Are you using a launchpad? If so, please try to launch a debug session with one of our basic examples, any of the GPIO or empty examples is a good idea. You will see that dialog box again. Press and Hold S2/PA18 on the Launchpad, while clicking Force Reset. 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 30 points

    Hi Brandon,

    here are updated results from our project.

    The above error is solved now, it was a wrong wiring of one adapter cable between XDS110 and our board. 

    Indeed, our microcontrollers were early samples type; we replaced one with a production type and the BCR, BSL NONMAIN region can now be correctly written (including the correct BOOTCRC and BSLCRC).

    One question remaining though: 

    BOOTCFG1 = 0x5566AABB works like expected (disabling the BSL enter by external pull-up)

    However we tried toe completely disable the BSL by:

    BOOTCFG2 =  0x5566AABB and the bootloader was still entered at power on.

    Could you check if BOOTCFG2 setting works on your setup?

    Thank you,

    Daniel

  • 0 in reply to Daniel Ciocea
    TI__Mastermind 28075 points

    Hi Daniel,

    I believe the NONMAIN tool in sysconfig will disable the BSL Invocation button by default when you disable BSL, although from reading the TRM it doesnt look strictly necessary.

    How are you disabling the BSL without disabling the BSL_INVOKE pin? Keep in mind that you have to use the correct CRC value as well. 

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    Prodigy 30 points

    Hi Brandon,

    our build setup is not based on TI's SDK (no CCS environment) and we use SW defined values for each BCR/BSL word.

    Their respective values do appear in the executable *.elf and *.s19 respectively. Of course the build environment calculates the appropriate BSL CRC and BCR CRC and populates them in the *s19 file. The resulted *.s19 is written on the microcontroller using UniFlash (the CRC is validated by the tool).

    Thus we are able to control each BCR,BSL entry individually.

    Best regards,

    Daniel

  • 0 in reply to Daniel Ciocea
    TI__Mastermind 28075 points

    Thanks for clarifying Daniel,

    I will test on my end and see if I can recreate this. I will have to do some modification to my setup but it should be possible.

    Best Regards,
    Brandon Fisher

  • 0 in reply to Brandon Fisher94
    TI__Mastermind 28075 points

    Hi Daniel,

    Apologies for the delay. I have finally got around to trying this on my end. 

    I don't seem to be able to get into BSL mode when BSL is disabled by any means (software invoke or PIN invoke). Even if the pin invoke is enabled. 

    I think in most cases disabling both BSL and the Pin Invoke is sensible, but I'm confused as to why you may be seeing this and I'm not.

    If you try to enter via Software reset when BSL is disabled does it work for you?

    If you are using our header files you should be able to do this with:

        SYSCTL->SOCLOCK.RESETLEVEL = SYSCTL_RESETLEVEL_LEVEL_BOOTLOADERENTRY;
    SYSCTL->SOCLOCK.RESETCMD =
        SYSCTL_RESETCMD_KEY_VALUE | SYSCTL_RESETCMD_GO_TRUE;

    Best Regards,
    Brandon Fisher