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.

MSPM0L1106: BSL invoke question.

Part Number: MSPM0L1106
Other Parts Discussed in Thread: UNIFLASH, , SYSCONFIG

Tool/software:

Hi Team,
As datasheet mentioned that below, NRST and BSL invoke pin are optional as below.


Due to product design limitation, these pins are not accessible. As I tested that if the function call, DL_SYSCTL_resetDevice(DL_SYSCTL_RESET_BOOTLOADER_ENTRY), MCU will reboot and enter bootloader directly without any operation on NRST pin. However, when I use UniFlash to download the firmware, the following error occurred :
If I set BSL_invoke pin to high and start the firmware download again, the operation can be success. In that case, BSL_invoke pin is not optional. Am I correct? If I am wrong, can you tell me how to bypass the BSL_invoke pin?

  • Hi,

    Enter BSL method:

    1. Hardware: pull BSL invoke pin while power on

    2. Software: use DL_SYSCTL_resetDevice(DL_SYSCTL_RESET_BOOTLOADER_ENTRY) API.

    There are two different way.  If you only disable invoke pin, you still can enter BSL via software.

    Regards,

    Zoey

  • Hi Zoey,

    Thank you for your reply. I know that there are two different way to enter BSL and I also tested these 2 methods, they both works on entering BSL only. In my test or my product, BSL invoke pin (PA18) will keep low all the time and I using the software method to enter BSL. After that, I use UniFlash to download the firmware and I got the following error : 

    In order to make it success, I need to set the PA18 high. What I mean here is that the BSL will check the state of PA18 again before firmware downloading. So my questions are :

    1. From my test result, PA18 is not optional. And it must be kept high all the time during firmware download. Am I correct?

    2. If PA18 is not really set high during firmware download, what will be the cause of the error provided above?

  • Hi,

    Sorry for late reply, as there seems to be some bug for my E2E email notification.

    To answer your question:

    1. From my test result, PA18 is not optional. And it must be kept high all the time during firmware download. Am I correct?

    2. If PA18 is not really set high during firmware download, what will be the cause of the error provided above?

    It is because the bug for Uniflash code. Not chip itself.

    Could you please use our self bootloader GUI in SDK(...\ti\mspm0_sdk_2_03_00_07\tools\bsl\BSL_GUI_source_code)? And I have done the test that it can meet your requirement.

    Regards,

    Zoey

  • Hi Zoey,

    Thank you for your reply and your suggestion. But I am sorry to tell you that I am using the ROM BSL in MSPM0L1106.

    AlanC.

  • Hi Alan,

    Yes, the BSL GUI can also be used for ROM BSL. It is the same function as Uniflash but more stable.

    Regards,

    Zoey

  • Hi Zoey,

    Yes, I understand, but the bug in ROM cannot be fixed. Disappointed

    AlanC.

  • Nonono,

    Alan, The bug is in Uniflahs, not ROM.

  • The source i provided in SDK, is the BSL GUI source code not BSL for M0 source code

    And I have tested that it can work while PA18 is always in low based on ROM BSL

    Regards,

    Zoey

  • Hi Zoey, 

    I am sorry of my mis-understanding. May I know when will a new version of Uniflash available?

    AlanC.

  • Hi Alan,

    Not sure for this. Could you please use BSL GUI firstly? And I will report this issue back to our internal team.

    Regards,

    Zoey

  • Hi Zoey,

    Yes, sure.

    By the way, may I ask you about the BSL on MSPM0L1106?

    I am studying on the secondary BSL on address 0. I created a sample project, flash_bsl_uart. I found that the starting address is 0x1000. Am I just change the start address to 0 in linker cmd file and it will become the secondary BSL on address 0? Are there any other thing need to be changed?

    Besides, If I want to debug / test on it, am I need to disable the BSLMODE and FASTBOOTMODE in NONMAIN? are there any other thing need to be changed?

    AlanC.

  • Hi Alan,

    I am studying on the secondary BSL on address 0. I created a sample project, flash_bsl_uart. I found that the starting address is 0x1000. Am I just change the start address to 0 in linker cmd file and it will become the secondary BSL on address 0? Are there any other thing need to be changed?

    Please also change below setting in sysconfig.

    Besides, If I want to debug / test on it, am I need to disable the BSLMODE and FASTBOOTMODE in NONMAIN? are there any other thing need to be changed?

    Yes, you need to disable ROM BSL.

    In bootcode(ROM), it will check if the ROM BSL is enabled, if enabled it will use ROM BSL. And if not, it will check if secondary BSL is ok. If yes, if will jump into the secondary BSL address. If not, it will run your application code in 0x0000.

    Regards,

    Zoey

  • Hi Zoey,

    If ROM BSL is disabled and changed the BSL to address 0, is that mean the "Use Alternate BSL Configuration" option should be set to disable?

    Besides, there is "factory reset" option under erase setting in Uniflash program. Is it erasing the NONMAIN memory? Will it write back any default setting into it? If not, how to specify and write back the default setting?

    AlanC.

  • Hi Alan,

    If ROM BSL is disabled and changed the BSL to address 0, is that mean the "Use Alternate BSL Configuration" option should be set to disable?

    You can just serve your secondary BSL code as application code. And every time you power on your MCU, it will run this code.

    Besides, there is "factory reset" option under erase setting in Uniflash program. Is it erasing the NONMAIN memory? Will it write back any default setting into it? If not, how to specify and write back the default setting?

    Yes, if you click the factory reset. The flash will all be 0xFFFFF and NONAMIN will also be back to the default setting.

    Regards,

    Zoey