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.

RTOS/MSP432P401R: UART interrupt failed when entering custom BSL from TI RTOS

Part Number: MSP432P401R

Tool/software: TI-RTOS

Hi,

I am developing a TI-RTOS application which will receive a command from UART to enter the BSL for firmware upgrade. I followed the example from TI. Here is the code I used

#define BSL_PARAM       0x7C48DF90 //0xFFFFDFFF  // Interface selection = UART

#define BSL_API_ADDR    0x00202000  // Address of BSL API table

#define BSL_FUNCTION    (*((UIntT *)BSL_API_ADDR))

void jumptoBSL(Int val) {

    uint8_t locDelay;

    Hwi_disable();

    NVIC->ICER[0] = 0xFFFF;

    NVIC->ICPR[0] = 0xFFFF;

    NVIC->ICER[1] = 0xFFFF;

    NVIC->ICPR[1] = 0xFFFF;

    for (locDelay = 0; locDelay < 10; locDelay++)

    {

        __delay_cycles(2000000);

    }

    // call the bootloader

    ((void (*)())BSL_FUNCTION)((UIntT)BSL_PARAM);

}

I am able to go to the BSL. I used the TI BSL Scripter to load the firmware. The BSL response to the synchronization byte from the UART, but it stopped response to the next command. I look into this problem and found that the UART ISR is not called in the BSL. Can someone help me to resolve this problem?

Thanks

  • Hello Wilson,

    I have asked the concerned engineer to look at the same. They should get back to you
  • Hi Wilson,

    does it means you got the "initialization succeed" message on the console when starting the BSL Scripter? but then failed, when you send the password?
    Could you please give more information about BSL Scripter version and the tool you are using to communicate with the BSL (MSP-FET, backchannel UART in Launchpad, or BSL Rocket)?
    I have to try to reproduce the setup to figure out what happened.
  • Hi Fatmawati,

    Yes the BSL Scripter send the password and I got the proper reply from the BSL, but it failed on the password command. I used BSL Scripter version 3.4. For your information, this problem only occurs when I jump from the TI-RTOS application with the same BSL UART port initialized and opened. If I run the BSL from the beginning, everything works fine. 

    Thanks,

    Wilson

  • Hi Wilson,

    thank you for more detailed information. I remember that recently we had same problem with calling the BSL via software on this thread: link.

    It was the Timer that is used by the application and not being reset before entering the BSL. The timer itself is being used on BSL application to calculate the timeout.

    Could you please check the use of timer on your RTOS application?

     


  • Hi Fatmawati,

    I don't think I used any timer in my code. Here is my simple TI-RTOS example that will create the problem.

    #define TASKSTACKSIZE      4096
    
    Task_Struct task1Struct;
    Char task1Stack[TASKSTACKSIZE];
    
    #define BSL_PARAM       0x7C48DF90 //0xFFFFDFFF  // Interface selection = UART
    #define BSL_API_ADDR    0x00202000  // Address of BSL API table
    #define BSL_FUNCTION    (*((UIntT *)BSL_API_ADDR))
    
    UART_Handle xPort;
    
    void jumptoBSL(Int val) {
        uint8_t locDelay;
        UART_close(xPort);
    
        Hwi_disable();
        NVIC->ICER[0] = 0xFFFF;
        NVIC->ICPR[0] = 0xFFFF;
        NVIC->ICER[1] = 0xFFFF;
        NVIC->ICPR[1] = 0xFFFF;
    
        for (locDelay = 0; locDelay < 10; locDelay++)
        {
            __delay_cycles(2000000);
        }
    
        // call the bootloader
        ((void (*)())BSL_FUNCTION)((UIntT)BSL_PARAM);
    
    }
    
    
    
    Void echoFxn(UArg arg0, UArg arg1)
    {
        UART_Params uartParams;
        UART_Params_init(&uartParams);
        uartParams.writeDataMode = UART_DATA_BINARY;
        uartParams.readDataMode = UART_DATA_BINARY;
        uartParams.readReturnMode = UART_RETURN_FULL;
        uartParams.readEcho = UART_ECHO_OFF;
        uartParams.readTimeout = 1000; // mS
        uartParams.baudRate = 9600;
        xPort = UART_open(Board_UART0, &uartParams);
    
        BIOS_exit(1);
    
        while(1) {
        }
    }
    
    /*
     *  ======== main ========
     */
    int main(void)
    {
    
        Task_Params taskParams;
    
        /* Call board init functions */
        Board_initGeneral();
        Board_initGPIO();
        Board_initUART();
    
        /* Construct heartBeat Task  thread */
        Task_Params_init(&taskParams);
        taskParams.arg0 = 1000;
    
        taskParams.stackSize = TASKSTACKSIZE;
        taskParams.stack = &task1Stack;
        taskParams.priority = 1;
        taskParams.instance->name = "echo";
        Task_construct(&task1Struct, (Task_FuncPtr)echoFxn, &taskParams, NULL);
    
        System_atexit(jumptoBSL);
        /* Start BIOS */
        BIOS_start();
    
        return (0);
    }

    As long as I remove the UART initialization code, the BSL works fine.

    Thanks,

    Wilson

  • Wilson,
    One thing that I have found is that the Systick, SVPEND, and SVC (supervisor call) which are used by the RTOS are not disabled by the example code provided. You may be getting into a situation where the BSL has remapped the interrupt vector table to SRAM and then when the RTOS related exceptions happen (Systick, SVPEND, and SVC), the BSL fails.

    Are you using the BIOS_Exit before attempting to invoke the BSL?

    Chris
  • Hi Chris,

    In my example, I used the BIOS_exit call in my task. The jumptoBSL is called after the BIOS_exit call to switch to the BSL. 

    Wilson

  • Thank you Wilson. I will need to dig into the source code and see how these exceptions are disabled.

    Regards,
    Chris
  • Wilson,
    I have been unable to locate any API calls that would turn off the associated supervisor and systick functions. If you can include the following API calls after the exit and before calling the BSL, then that should prevent the associated exceptions from happening and possibly corrupting the system (since the BSL maps the interrupt vector table to SRAM).

    SysTick_disableInterrupt();
    SysTick_disableModule();
    Interrupt_unpendInterrupt(FAULT_SYSTICK);
    Interrupt_unpendInterrupt(FAULT_PENDSV);

    I will also try and test on my side.

    Chris
  • Hi Chris,

    Thank you for your help. I will give it a try and let you know the result.

    Wilson

  • Wilson,
    If you have an update, then that would be great. I am going to file a bug against the kernel to get this captured.

    Regards,
    Chris
  • Hi Chris,

    I have tried your suggestion and I am still having the same issue. Please let me know if you have any fixes in the future.

    Thanks,

    Wilson

**Attention** This is a public forum