• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 83 subscribers
  • Views 3084 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.

FlashApi download via SCI about customized bootloader for tms32F28335

user1743394
Prodigy 195 points
Other Parts Discussed in Thread: CONTROLSUITE

Hi,everybody.

     I have written a customized bootloader (non-BIOS) that can update AppCode for F28335.I refer to the app note SPRAAQ2 for 2812 and find the answer in TI E2E communitythe when I designed the bootloader.The Flash API functions MUST be run out of internal zero-waitstate SARAM memory, so Copy API Functions into SARAM:

Example_MemCopy(&Flash28_API_LoadStart, &Flash28_API_LoadEnd, &Flash28_API_RunStart);

SECTIONS
{
    Flash28_API:
   {
        -lFlash28335_API_V210.lib(.econst)
        -lFlash28335_API_V210.lib(.text)
   }                   LOAD = FLASHA,
                       RUN = RAML0,
                       LOAD_START(_Flash28_API_LoadStart),
                       LOAD_END(_Flash28_API_LoadEnd),
                       RUN_START(_Flash28_API_RunStart),
                       PAGE = 0

}

The Flash API functions are progrommed with customized bootloader in initial version,now If I want download the API Functions to SARAM memory via SCI, How can I do ?

Thank you,

Clack.

  • 0
    TI__Mastermind 32995 points
    You can use the hex utility tool and map the Flash API to RAM. Send the hex file to your bootloader and make sure your bootloader checks the address of the block before programming the contents of that block. Check to see if it is a RAM location or a Flash location. If it is a RAM location, just simply do a CPU write of the data to the location specified for that block in the hex file.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 195 points

    Hi, Sal , thank you very much for your help . I have some questions:

    1、As you said , I can use the hex utility tool and map the Flash API to RAM.  How can i use the API Functions in the bootloader if I have map the Flash API to RAM in the AppCode? I don't konw the address of Flash API ----Flash_Erase,Flash_Program and Flash_Verify, for example. I can't use the Function Pointer. Tht Flash API functions are packaged in the Flash28335_API_V210 library;

    2、Can you give me a TI example as a reference ?

    thanks ,

    Clack

  • 0 in reply to user1743394
    TI__Mastermind 32995 points
    We have a serial_flash_programmer and sci_flash_kernel in controlSUITE. Please see www.ti.com/lit/sprabv4

    I am not sure what your are saying in your first point. Please describe in greater detail what your firmware upgrade process is.

    I am assuming your bootloader resides in Flash. In order t run the Flash API, you need to execute the Flash API from RAM. You will need to do a memcpy of the Flash API into RAM in order to upgrade your flash.

    Using your bootloader, you can get the Flash API into RAM in two ways. You can map the Flash API to RAM in the hex file and check the address of the block. If the block of memory is RAM then simply do a CPU write into RAM. if it is flash, then use the flash API you copied into RAM to program the flash. It may be best to keep your entire bootloader and Flash API in flash, and have your bootloader copy the flash API into RAM before executing it.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 195 points

    Thanks, I want to achieve this utility:

    1、Customized bootloader what can update AppCode  does not include the  Flash API functions(Flash_Erase,Flash_Program and Flash_Verify) ;

    2、The  Flash API functions(Flash_Erase,Flash_Program and Flash_Verify) is download to SRAM via SCI ,and then the AppCode is programmed into the flash by Flash API functions based on customized bootloader.

    How can i do ?

    thanks ,

    Clack

  • 0 in reply to Sal Pezzino
    Prodigy 30 points

    I can't find this serial _flash_programmer in  the latest controlSUITE , wish you check about it ? On the other hand , it seems that the flash_kernel doesn't give the usage of vertifying flash .

  • 0 in reply to song wang
    TI__Mastermind 32995 points
    Please see this important App Note http://www.ti.com/lit/sprabv4

    The serial_flash_programmer can be found in device_support/~Utilities

    Clack, you can use and modify the serial_flash_programmer and sci_flash_kernel to acomplish what you are wishing to do.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 195 points

    Sal, thank for your help . I had read the serial_flash_programmer and sci_flash_kernel.   I had  acomplish what sci_flash_kernel can do. Now , I want do something different from the sci_flash_kernel. I want  Flash _API library from stripped sci_flash_kernel what named Primary Bootloader (PBL)and download Flash API Funtions(Flash_Erase,Flash_Program,Flash_Verify) what named Secondary Bootloader (SBL) .

    I'm confused about how to konw the addresses of  Flash API Funtions?They are packed of library. How can I allocation the addresses of Flash API Funtions (Flash_Erase,Flash_Program,Flash_Verify) ?

    thanks ,

    clack

  • 0 in reply to user1743394
    TI__Mastermind 32995 points
    In order to create a hex file to doawnload to the device, you would need to create a project and .out file.

    I am not sure if there is a very simple way to do this. I am not sure why you are wanting to do this either. Are you running out of flash memory?

    You can load two separate applications. One being your main application and another being a firmware upgrade application containing the flash API. You can then branch to the flash API application when needed. If you want to do it this way, they just make sure you map both applications do different flash memory locations.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 195 points

    Hi,Sal, I have achieved the implementation that application reports(spraaq2, spru963a and sprabv4a) describe, but what I want to do  must abide by ISO 14229-1.

    The bootloader is divided into two separate parts: a primary bootloader (PBL) and a secondary bootloader (SBL). The PBL is designed to be permanently placed in a protected flash boot sector, which is activated from reset. The SBL is intended to be downloaded by the PBL into the CPU internal RAM, from where it is executed and thereafter deleted after each use. The SBL can be described as a superset of the PBL, adding functions for erase and program of flash memory .

    Clack

  • 0 in reply to user1743394
    TI__Mastermind 32995 points
    Clack,

    I think the sci flash kernels with slight modification would serve the purpose for SBL. In this case your PBL would not have to do much. It could use a serial link to download the kernel into RAM, or it could simply call the SCI_Boot function in ROM.

    Your SBL could be its own CCS project with its own main(). Once your PBL gets the notification to perform a firmware upgrade, download the SBL, and branch to it. After the SBL finishes the firmware upgrade, then branch to the flash application your just programmed or branch back to the PBL.

    What questions do you have?

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 195 points
    Sal, thank you for help .
    clack