• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 1407 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LS0714: TMS570LS0714 CAN_Boot Flash program issue

David Bai
Intellectual 1835 points
Part Number: TMS570LS0714


Hi team,

My customer use CAN_bootloader base on TMS570LS0714 platform, there are some issues need to clarify.

1. They use  Fapi_BlockProgram() to do the app code update,  the code is as below. Then they found that Fapi_BlockProgram just can write up to 16Bytes at a time. But after wrote 16 Bytes, the code jump to interrupt vectors, and the  BOOT can't write more bytes in the flash.

Current solution:  Disable interrupt, they can write bytes normally. But firstly, they use " _disable_Interrupt_() " to do the interrupt disable, it doesn't work; then if they use "vimDisableInterrupt()", it works well.

Question:

                 1. Is it necessary to disable interrupt when they do the Flash Update? Why?

                 2. What's the difference between " _disable_Interrupt_() " & "vimDisableInterrupt()", why the  " _disable_Interrupt_() " can't disable the interrupt successfully?

void App_CANFlashUpdate(void) 
{ 
    UINT16  u16Lenth; 
    UINT32  u32TargetAddress; 
    UINT32  u32UpdataFlag; 
    UINT8   u8FlashBootInfo[24]; 
    UINT8   u8Ret; 

    if(1 == g_un_SysCanCommFlag.bits.b1FlashUpdate) 
    { 
        g_un_SysCanCommFlag.bits.b1FlashUpdate = 0; 
        u32TargetAddress = FLASH_MODULEID_ADDR; 
        g_u32ModuleIDBoot = 0x1234; 
        g_u32BootSWVer = 0x5678; 
        g_u32CANIDSend = 0x109; 
        g_u32CANIDRcvd = 0x119; 

        UINT8 i = 0; 
        u8FlashBootInfo[i++] = 0x00; 
        u8FlashBootInfo[i++] = 0x00; 
        u8FlashBootInfo[i++] = (g_u32ModuleIDBoot>>8) & 0xFF; 
        u8FlashBootInfo[i++] = g_u32ModuleIDBoot & 0xFF; 

        u8FlashBootInfo[i++] = 0x00; 
        u8FlashBootInfo[i++] = 0x00; 
        u8FlashBootInfo[i++] = (g_u32BootSWVer>>8) & 0xFF; 
        u8FlashBootInfo[i++] = g_u32BootSWVer & 0xFF; 

        u8FlashBootInfo[i++] = 0x00; 
        u8FlashBootInfo[i++] = 0x00; 
        u8FlashBootInfo[i++] = (g_u32CANIDSend>>8) & 0xFF; 
        u8FlashBootInfo[i++] = g_u32CANIDSend & 0xFF; 

        u8FlashBootInfo[i++] = 0x00; 
        u8FlashBootInfo[i++] = 0x00; 
        u8FlashBootInfo[i++] = (g_u32CANIDRcvd>>8) & 0xFF; 
        u8FlashBootInfo[i++] = g_u32CANIDRcvd & 0xFF; 

        u8FlashBootInfo[i++] = 0x55; 
        u8FlashBootInfo[i++] = 0xAA; 
        u8FlashBootInfo[i++] = 0x55; 
        u8FlashBootInfo[i++] = 0xAA; 

        u8FlashBootInfo[i++] = 0x55; 
        u8FlashBootInfo[i++] = 0xAA; 
        u8FlashBootInfo[i++] = 0x55; 
        u8FlashBootInfo[i++] = 0xAA; 

        u32TargetAddress = 0x30000;//FLASH_MODULEID_ADDR; 
        Fapi_BlockProgram((uint32)0, u32TargetAddress, (UINT32)&u8FlashBootInfo[0], 24); 

    } 
}

2. When they use the CAN_bootloader to update the app program hex, they find the application can't be executed successfully. 

Current solution: Modify the sequence of VECTORS and FLASH_API  address in .cmd file.

Unavailable cmd configuration:

Available cmd configuration:


Question:

                 1. Why the address of FLASH_API need less than the address of VECTORS?

                 2. If the address allocation in "MEMORY {}" must be continuous? Or if the address of VECTORS and FLASH_API can be assigned to different sectors?

3. Now customer use the following configuration is CCS to output the HEX file of application program, is it right? Why the Specify rom width is "32"? Is there any documents to introduce how to configure the options?

4. How to get the length of receive date from CAN bus dynamically?

Thanks a lot.

  • 0
    TI__Guru**** 199096 points

    Hi David,

    David Bai said:
    They use  Fapi_BlockProgram() to do the app code update,  the code is as below. Then they found that Fapi_BlockProgram just can write up to 16Bytes at a time. But after wrote 16 Bytes, the code jump to interrupt vectors, and the  BOOT can't write more bytes in the flash.

    The Flash API itself can program from 1 byte up to the bank width (8,16,32) bytes based on the bank architecture. The supplied starting address to program at plus the data buffer length cannot exceed the bank data width. For example, Programming 14 bytes on a 16 byte wide bank starting at address 0x4 is not allowed. The flash bank width of LS0714 is 16 bytes.

    But the Fapi_BlockProgram can program any size of data block. The Flash API in this function is used to program 16 bytes data every time. If you increase the value of size in the function, it will cause problem:

    if (SizeInBytes < 16)

        bytes = SizeInBytes;
    else
        bytes = 16;

    David Bai said:
    Is it necessary to disable interrupt when they do the Flash Update? Why?

    You don't have to disable the interrupt. Normally the interrupt is not enabled in bootloader.

    David Bai said:
    What's the difference between " _disable_Interrupt_() " & "vimDisableInterrupt()", why the  " _disable_Interrupt_() " can't disable the interrupt successfully?

    _disable_Interrupt_() is to disable IRQ and FIQ. The vimDisableInterrupt(channel) is to disable the interrupt for the the selected channel, the interrupt for this channel may be IRQ or FIQ.

    I don't know why _disable_Interrupt_() doesn't work. The interrupt is not enabled at default.

    David Bai said:
    When they use the CAN_bootloader to update the app program hex, they find the application can't be executed successfully. 

    The bootloader doesn't support hex format which has address embedded. But the flash API don't care.

    David Bai said:
    Why the address of FLASH_API need less than the address of VECTORS?

    don't understand. The INT vector for bootloader has to be at 0x00. The INT vector for application has to be located at the application address.

    David Bai said:
    If the address allocation in "MEMORY {}" must be continuous? Or if the address of VECTORS and FLASH_API can be assigned to different sectors?

    The flash_API can be assigned to anywhere except the 0x00

    David Bai said:
    Now customer use the following configuration is CCS to output the HEX file of application program, is it right? Why the Specify rom width is "32"? Is there any documents to introduce how to configure the options?

    yes, you can use this utility to generate the intel or motorola format hex files. but the bootloader doesn't support hex file.

    David Bai said:
    How to get the length of receive date from CAN bus dynamically?

    the maximum length for CAN transmission is 8 bytes. The size is in the CAN data packet. what do you mean "dynamically"? 

  • 0 in reply to QJ Wang
    Expert 1210 points
    Maybe,his meaning is "active" CAN Data
  • 0 in reply to Qiu chi
    TI__Guru**** 199096 points
    You get the data length when you read the data packet. For bootloader, the host side should inform the receiver the total data length before it transfers the data.
  • 0 in reply to QJ Wang
    TI__Intellectual 1835 points

    Hi QJ,

    1. 
    David Bai
    Is it necessary to disable interrupt when they do the Flash Update? Why?

    You don't have to disable the interrupt. Normally the interrupt is not enabled in bootloader.

             David Bai Clarification:
     
             If customer doesn't use vimDisableInterrupt() to disable the interrupt, they can't use Flash API normally in application program;
    2. 
              
    David Bai
    Why the address of FLASH_API need less than the address of VECTORS?

    don't understand. The INT vector for bootloader has to be at 0x00. The INT vector for application has to be located at the application address.

                David Bai Clarification:  

                In customer 's CAN_bootloader bl_config.h, they define the APP_START_ADDRESS and APP_STATUS_ADDRESS as below.

    // The flash image of the boot loader must not be larger than this value.
//*****************************************************************************
#define APP_START_ADDRESS       0x00020100

//*****************************************************************************
// The address to store the update status of the application image
// It contains Application Start Address, Application Image Size, etc
//
//*****************************************************************************
#define APP_STATUS_ADDRESS       0x00020000

                 But in application cmd files, if they config the MEMORY as Figure 1, the application program can't be executed normally. While, if they config as Figure 2, the application program can be executed very well, do you know why? Thanks.

     

    Figure 1 Unavailable CMD file of Application


    Figure 2 Available CMD file of Application

     

  • 0 in reply to David Bai
    TI__Guru**** 199096 points
    Hi David,

    1. Need to test: flash API with/without executing the vimDisableInterrupt()
    2. The figure 1 looks ok, and figure 2 is not correct. Does the application also call the flash APIs?
  • 0 in reply to QJ Wang
    TI__Intellectual 1835 points
    Hi QJ,
    Thanks for your support.
    For the 2nd question, the application also call the flash APIs. unfortunately, if they use the figure 1, the application program can't be executed normally, but the figure 2 works well.
  • 0 in reply to David Bai
    TI__Guru**** 199096 points
    Hi David,

    I just did test with rti interrupt enabled (every 0.1ms), the flash API (band erase takes about 0.3s, and program takes longer) still works without any issue.

    Does their application need flash API?