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.

MSP432E401Y: Invoking ROM Bootloader from application

Part Number: MSP432E401Y

Is there a way to start the internal ROM bootloader from the application and have it remain running for firmware updates?

I have been able to start the ROM bootloader through the vector at 0x1000004, but when it executes, the application is just restarted.

The ROM bootloader sees the vector at 0x0000004 is programmed, and the pin defined in BOOTCFG is not asserted, so it starts the app again.

  • Hi,

    What do you mean that "have it remain running for firmware updates?"

    You want to keep the BSL running, after finishing updating application?

    Can you tell me you application? As the ROM is fixed, I don't think you can realize. Maybe you can try the bootloader in flash:http://dev.ti.com/tirex/explore/node?node=AFExyN9Ym1DsibDJ5oM3oQ__J4.hfJy__LATEST

    Eason

  • I do not want the ROM bootloader to automatically branch to the application when it starts.  It should wait for the baud sync character to accept new firmware.

    When I call the ROM bootloader at 0x1000004 it detects the app and restarts immediately without ever allowing a firmware upgrade to be done.

    I can start the ROM bootloader using the GPIO defined in BOOTCFG, I'm looking for a way to do the same programmatically from the application.

  • You mean when enter the application, you want to use a GPIO pin to enable the ROM bootlaoder to wait for the baud sync character to accept new firmware?

  • This is a very typical scenario.

    The app firmware is running.

    A user wants to upgrade to new firmware.

    The app starts the bootloader.

    The bootloader loads new firmware.

    The unit is restarted and the new firmware runs.

    I cannot make this happen, because the bootloader just restarts the application instead of handling the firmware upgrade.  I want the bootloader wait for new code on the serial interface, rather than starting the old application.

  • I think you may mix boot mode and bootloader. Do you mean that after you set stack pointer and reset vector pointer to 0x01000000 and 0x01000004, the bootloader will not wait you to send the new application code?

    Actually, I don't find Bootloader will check the content at 0x0000004 in this document: http://www.ti.com/lit/ug/slau746a/slau746a.pdf?&ts=1589869324425

  • Hi Eason,

    I'm not sure how else to describe this.  I think I have been pretty clear in my messages.  The document you are reading refers to the flash based bootloader, it only contains a small section describing the ROM bootloader default pin configurations.  Here is a section of the Technical Reference manual that describes the ROM Bootloader startup.

    Now consider what happens when the app starts the bootloader programmatically.  This logic runs and the app restarts, there is no chance to use the bootloader to upload new firmware.

    The ROM Bootloader does everything I need, so I'm trying to avoid using a flash based bootloader.  I just want to start the ROM Bootloader and upload new firmware. 

  • Thank you for your patient. I am much clear about the ram bootloader now. I will close thread.

  • Please do not close this thread.  I have now explained the problem, but have no solution.

    Is is possible to use the ROM bootloader to update firmware as I have described?

    How do I prevent the ROM bootloader from restarting the old application when I call it from my application?

  • I think you can.

    I must declare that it is boot code to check the address at 0x00000004 not bootloader not bootloader. You can't get access to boot code through memory address.

    You can check this thread for more information: https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/777879?tisearch=e2e-sitesearch&keymatch=MSP432E%252520ROM%252520bootloader.

    As I check the flash bootloader, it will keep waiting the host. I advice you make a try.

    Eason

  • I don't understand your differentiation between "boot code" and "bootloader".  The text you highlight again further explains my point that the bootloader will not run and wait for code.

    I have already read the thread you linked.  If you follow it, this is a user with a SPI interface, at the end you can see he had problems with his setup.  I stated I am using the UART interface, and have successfully run the firmware upgrades using the GPIO invoking method.  This means I have correctly implemented the protocol and have successful communication.   This thread is not related to my concerns.

    You ask me to "make a try".  Do you think I haven't tried this?  I have spent days working on this problem looking for a solution.  I have stepped through the bootloader manually in assembly language to look for solutions.  Have you tried it?

  • Actually, there is a solution. After a few more hours of experimentation I have found a method to keep the ROM bootloader from restarting the application.

    In the application set the pin that is configured in the BOOTCFG register to an output and set the output to the state needed to keep the ROM bootloader running.

    Then make a call directly to the ROM Bootloader entry vector. The GPIO pin will be read as being in the state required to keep the ROM bootloader active. After the new firmware is uploaded, a normal reset will cause the GPIO to return to an input and the new application starts.

    The code looks something like this:

    void StartROMBootloader(void)
    {
    /* Turn off clocks */
    SysTickIntDisable();
    SysTickDisable();

    /* Enable the GPIO peripheral for the boot pin */
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOD)) {}

    /* Set the boot pin to an output */
    GPIOPinTypeGPIOOutputOD(GPIO_PORTD_BASE, GPIO_PIN_2);

    /* Set the state of the boot pin to force the ROM Bootloader to run */
    GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_2, 0);

    /* Disable all processor interrupts. Instead of disabling them one at a
    * time, a direct write to NVIC is done to disable all peripheral
    * interrupts. */
    NVIC->ICER[0] = 0xffffffff;
    NVIC->ICER[1] = 0xffffffff;
    NVIC->ICER[2] = 0xffffffff;

    /* Execute the ROM Bootloader */
    (*((void (*)(void))(*(uint32_t *)0x1000004)))();
    }


    If the pin is also connected to something externally, make sure this does not cause an electrical short when you drive the output. In my case I am going to be using a switch to ground, so I have an external pullup resistor, and I configure the output as an Open Drain. In this configuration either the switch, or the MSP can pull the line low without causing a short.

  • The boot code is use for initialization. When the MCU is powered on,  it is the first code which will run, such as initialization, IP protection, judge if enter bootloader, etc. This part of code should not be accessed by user use program counter directly.Bootloader is the code for firmware update or erase, which can be accessed by program counter.

    See from the UG, I think jumping to 0x010000004 happens at boot code, not in bootloader, which is designed like this in MSP430. That is why I hope you to make a try.  About the link using SPI interface, you can find a TIer said the code in flash bootloader is same as rom bootloader. That is why I say when you enter the rom booloader, it should wait for communication all the time, after I check the flash bootloader. So I make an assumption. Yesterday, I borrow a launchpad and tried, it seem that if there is application, it will enter the application directly, which is unkind to customer.

    I also try to find more information about ROM bootloader content, nothing can find. I consult our software team guy who is responsible for MSP432Exx bootloader, all she can find is just user guide. 

    Sorry, and thank you for solving this problem.

  • Hi Rob,

    what I nice solution! Thank you for sharing.

    br

    Markus

**Attention** This is a public forum