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.

MSP432E411Y: ROM bootloader questions

Part Number: MSP432E411Y


I am somewhat uncertain how the ROM bootloader on the MSP432E411 is configured?  As I understand, in default settings (BOOTCFG=ffff'fffeh) the startup code will check for PH7 level at startup; if high, the ROM bootloader (from 0100'0000h) is entered.  The ROM will be entered if the flash reset vector is erased as well.

What interfaces are supported?  Specifically, is USB update supported?

Is entering the ROM bootloader directly from software supported with a function call in the SDK or a programming sequence?  Does this entry require the pin above to be set / flash to be erased.

  • Hello Jaakko,

    With the reset value of the BOOTCFG the boot pin is not supported. This is so because the Bit-8 of the register which is the EN bit is set. The Pin is only checked if the EN bit is cleared, i.e. it has the value 0. To be able to clear the bit and make it permanent you would need to commit the register with the updated value first. This will ensure that at every power up or hard reset of the device the pin shall be polled to check if the value of the Port-Pin match for invoking the ROM boot loader.

    On the MSP432E4x devices the interfaces supported for the boot loader are the UART, I2C, SSI, USB and Ethernet in the ROM. For Ethernet boot loader an external crystal of 25 MHz is required while for USB an external crystal is a must.

    Entering the boot loader from the application is also supported. For this the specific interface call is required. There are examples shown in the SDK that do the same. Please refer to the following path for the SDK of MSP432ED4 for references.

    C:\ti\simplelink_msp432e4_sdk_1_55_00_21\examples\nortos\MSP_EXP432E401Y\boot_loader
  • ¨Thanks!  I somehow mis-interpreted the EN bit here.

    I am not sure if I understand the way to enter the ROM bootloader from the application though... if I understand correctly I would call an irq function to reset the SP to the application's SP address and call e.g. AppUpdaterUSB from within the ISR?  This would not execute from ROM however, but would need to be linked separately into flash?  Is there an SDK function for this?

    How does the bootloader select between the configured interfaces?

    I would prefer a solution with only the ROM bootloader in use!

  • Hello Jaakko

    No you do not need to call an IRQ function when going from application code to the ROM boot loader. When compiling the application code with the call to ROM, the ROM interface being used has a defined location and gets linked during application code linker invocation. The ROM boot loader user guide gives all the calls to the interface of choice.

    When the ROM boot loader is invoked due to flash being empty or due to the Boot Pin polarity matching, it polls the interfaces to see if a packet is received. The interface which shows a packet being received that is valid is the interface selected. However the same is not possible from the application code to the ROM update function as the ROM update function is specific to the interface.
  • Hmm... the document is not awfully clear in which of the calls are public (this is SLAU746, right ?) I assume I could call AppUpdaterUSB(), but this will result in a link error. What library should I be link against and/or which header to include (I am using the TI compiler.) I am still using SDK 1.55.00.21. -- do I need to upgrade?
  • Hello Jaakko,

    The SLAU746 is for the Flash based boot loader. And you are correct the ROM based boot loaders are not so well documented. The API's to invoke the ROM API's is

    ROM_UpdateEMAC
    ROM_UpdateI2C
    ROM_UpdateSSI
    ROM_UpdateUART
    ROM_UpdateUSB

    You need to include the rom.h and rom_map.h from the driverlib.

    If you can tell which specific interface you are looking for, I can provide more information
  • Thanks!  Update would be mainly through USB.  Do the peripherals need to be configured and/or enabled or does the ROM code take care of that?  What's the expected state of the USB device on entry, or will everything be initialized ?  Can the descriptor be configured (PID/VID) / what's the (non-const) pui8DescriptorInfo argument taken by UpdateUSB() ?

    I assume there's no way to use a different UART for the ROM update code, but that would require linking the flash code?

  • Hello Jaako,

    When the ROM_UpdateXXX function is called from the application code, then the application code needs to make sure that the IO's for the peripheral is configured correctly and the peripheral has been clock enabled and configured for the correct clocking. Also before jumping to the ROM Update function, the CPU needs to make sure that all peripheral interrupts are disabled at the NVIC level so the boot loader is not interrupted by an interrupt handler.

    In case of USB, the ROM uses a predefined PID/VID provided by TI. It is must to terminate the USB before re-invoking it for ROM boot loader.

    Also the UART-0 is used for UART based boot loader.

**Attention** This is a public forum