AWR2944: How to write a new .appImage file to flash over the serial interface while in qspi boot mode?

Hi Saswat Kumar,

Thanks for your suppport.

Saswat Kumar said:

2) For AWR2944 you can refer the C:\ti\mmwave_mcuplus_sdk_04_03_00_01\mcu_plus_sdk_awr294x_08_04_00_22\examples\drivers\boot\sbl_qspi\awr294x-evm\r5fss0-0_nortos\main.c line 149 status = Bootloader_runSelfCpu(bootHandle, &bootImageInfo); where the soft reset is being performed.

Calling the function Bootloader_runSelfCPU only resets the arm R5F. When the customer calls this function in a function defined in the CLI, the program cannot work properly and the function is located in the main program of SBL after the SBL boot .appimage file is complete.

What customers want to do is they can re-run the SBL function and start running from RBL when receiving the CLI command.

Also the customer referenced this doc, a reset can be performed using CLI commands in the SDK4.3.1 release, but is still not available in the SDK4.2.2 release. 

Thanks and regards,

Cherry

Hi Saswat Kumar,

Receive the appimage file sent from the upper computer over the serial port in qspi mode, and use UART_uniflash.tiimage to burn the script in UART boot mode where the appimage file is received from the serial port using the xmodem protocol. However, this burn script is not available in qspi mode, is it ok to read files directly using the UART_read function? Is there a possibility of a file read error? 

Could you help specify how to set up memory on L3 of DSS for temporary storage of appimage and then write to flash? The function you mentioned Bootloader_socMenInitCPU initializes the bank about L3 without allocating memory.

The following memory requests in UART_uniflash.C:

Hi Saswat Kumar,

The customer now is able to reboot, but will receiving a 0x0A at startup when reading the appimage file sent from the serial port. After several tests, the character remains.

And they have reviewed the appimage file, this 0x0A is not a character in it. Currently it can be fixed through reading one more character from the serial port and skipping the first character when writing flash.

Will this happen by accident OR will it always happen? And how to avoid it? Doing so will cause errors in the appimage file written to flash, causing SBL to fail.

The code is as follows:

static int32_t MYRESETFUNCTION(int32_t argc,char* argv[])
{
    uint32_t filesize = 0;
    if(argc<2)
    {
        return 0;
    }
    else
    {
        CLI_write("FILESIZE=%s\r\n",argv[1]);
        filesize = atof(argv[1]);
    }
    CLI_write("filesize = %d\r\n",filesize);
    CLI_write("COPY appimage file\r\n");
    //Read the appimage file from the serial port 
    uint32_t done = 0U;
    rlFrameStartStop(1,0x0000);   //Stops the transmission of the signal frame and now specifies a device map id of 1 
    ClockP_usleep(1000);//Wait for the current frame to complete and close the front end. 
    uint8_t *databuf1 = (uint8_t *)(0x88000000);
    UART_Transaction trans;
    while(!done)
    {
        UART_Transaction_init(&trans);
        trans.buf = databuf1;
        trans.count = filesize+1;   //Read space + 1 of 1M 
        if(!UART_read( UART_getHandle(1),&trans))
        {
            Bootloader_uniflashFlashFile(0,databuf1+1,filesize,0xA0000);//+1 is to skip the 0x0A received for each fix 
            UART_write(UART_getHandle(1),&trans);    //Prints the received data, dcb.fNULL = 0; 
            CLI_write("END OUT PRINT\r\n");
            done = 1;
        }
        else
        {
            CLI_write("RECEIVE ERROR\r\n");
        }
    }
    //Re-enter reboot mode 
    uint32_t baseAddr;
    volatile uint32_t *kickAddr;
    uint32_t i=0;
    //uint32_t value = 0;
    baseAddr = CSL_MSS_TOPRCM_U_BASE;
    kickAddr = (volatile uint32_t*)(baseAddr+CSL_MSS_TOPRCM_LOCK0_KICK0);
    CSL_REG32_WR(kickAddr,KICK0_UNLOCK_VAL);
    kickAddr = (volatile uint32_t*)(baseAddr+CSL_MSS_TOPRCM_LOCK0_KICK1);
    CSL_REG32_WR(kickAddr,KICK1_UNLOCK_VAL);
    uint32_t*regAddr = (uint32_t*)0x02140100;
    uint32_t dbg = *regAddr&0xFFFFF8FF;
    while(i<0xFFFF)
    {
        i++;
    }
    *regAddr = dbg;
    return 0;
}

Thanks and regards,

Cherry

Hi,

May I know is there any update? 

Thanks and Regards,

Cherry

Hello Cherry,

Could you please proobe the UART lines and check if the 0x0A is visible on the probe log?

Regards,
Saswat Kumar