• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 512 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.

Original question:

TMS570LC4357: Bootloader example code

TMS570LC4357: Questions about the TMS570LC43 SafetyMCU_Bootloaders example code

jimj2713
Expert 2385 points
Part Number: TMS570LC4357


I need to rewrite the TMS570LS_canBootloader_Test, as the NI USB-8473 is no longer available, but in the meantime, I had a couple of questions.

1. Is the CCS-project available that built the "TMS570LC43x_rtiBlinky_BL_APP10020.bin" referenced in TMS570LS_canBootloader_Test? In my experience, there would have to be linker-command-file coordination between the resident application (lc43_can_boot) and the file to be loaded (rtiBlinky_BL), otherwise wouldn't rtiBlinky_BL overwrite lc43_can_boot, and this bootloader would only work once?

2. The .out to .bin post-build actions specified by the readme in SafetyMCU_Bootloaders create a 4GB bin file -- in order to assure that all Flash holes are properly filled and ECC-ed, does the file-to-be-loaded also have to be a complete ECC-Flash (4GB) file?

Thanks,
Jim

  • 0
    TI__Guru**** 198766 points

    Hello Jim，

    1. The application image is programmed to the flash sectors starting at 0x10020. The bootloader is located at the first sector of the flash. I will find the ccs project for you.

    2. You can use the bootloader to calculate the whole flash ECC using linker cmd file. But for application image, you only need to calculate the ECC for sectors used by application image.

  • 0
    Expert 2385 points

    QJ,
    Thanks for the quick reply; yes if you could find that TMS570LC43x_rtiBlinky_BL_APP10020.bin CCS project, that would really help with some of details.

    I assume the application-to-be-loaded has no CPU-initialization code in it (because that is done by the bootloader), so to debug my new application,
    I would have to first load the bootloader project, then separately load the application?

    Two items I am unclear on are:

    1. I need FlashAPI support in my application also (to store user configuration), so if the bootloader and application are different CCS-projects, will I need 2 instances of the FlashAPI in product -- one that the bootloader can find and one that the application can find (and is that possible)? I have never done that with a library before.

    2. This potential ECC-error due to Flash-holes seems like it would have to be managed throughout the software lifecycle? Consider this scenario:

    A) The initial version 1 application requires 10KB of flash-space.
    B) The customer upgrades this application to version 2, but this version uses 12KB of flash-space.
    C) The customer wants to upgrade this application to version 3, but this version only uses 11KB of flash-space -- so after this upgrade, there is ~1KB of garbage code left over from version 2; wouldn't this potentially cause an ECC error due to the speculative fetches?

    Thanks,
    Jim

  • 0 in reply to jimj2713
    TI__Guru**** 198766 points

    Hi Jim,

    Attached is the application image which will loaded to 0x20020:

    2061.TMS570LC43x_rtiBlinky_BL_APP20020.zip

  • 0 in reply to jimj2713
    TI__Guru**** 198766 points
    jimj2713 said:
    I assume the application-to-be-loaded has no CPU-initialization code in it (because that is done by the bootloader), so to debug my new application,
    I would have to first load the bootloader project, then separately load the application?

    You don't have to repeat the following self-test in your application if they are done in the bootloader:

    1. CPU/STC self-test, and self-check

    2. PBIST to RAM groups, and PBIST and STC ROMS

    3. System Init if same PLL is used

    4. HW initialization of the peripherals' RAM which are not used in Bootloader

    But the modules and peripherals have to be initialized again in application: VIM, ESM, MPU, Pinmux, MCU RAM HW initialization, etc.

  • 0 in reply to jimj2713
    TI__Guru**** 198766 points
    jimj2713 said:
    1. I need FlashAPI support in my application also (to store user configuration), so if the bootloader and application are different CCS-projects, will I need 2 instances of the FlashAPI in product -- one that the bootloader can find and one that the application can find (and is that possible)? I have never done that with a library before.

    Yes, you need to copy the F021 flash APIs to MCU RAM in application again.

  • 0 in reply to jimj2713
    TI__Guru**** 198766 points
    jimj2713 said:

    2. This potential ECC-error due to Flash-holes seems like it would have to be managed throughout the software lifecycle? Consider this scenario:

    A) The initial version 1 application requires 10KB of flash-space.
    B) The customer upgrades this application to version 2, but this version uses 12KB of flash-space.
    C) The customer wants to upgrade this application to version 3, but this version only uses 11KB of flash-space -- so after this upgrade, there is ~1KB of garbage code left over from version 2; wouldn't this potentially cause an ECC error due to the speculative fetches?

    The application image (10K, 12K, 11K) is smaller than one flash sector size (16KB, 32KB, or 128KB, or 256kB). If the application is programmed to flash sector #4 (starting at 0x10000), you can generate ECC for flash sector #4 using Linker cmd file, or you can fill the unused the space of sector #4 with 0xFF in linker cmd file.

    For example:

    To fill the unused the space of sector #4 with 0xFF, the ECC of unused space is also calculated when program the application image using F021 API:

    MEMORY
    {
          /* USER CODE BEGIN (2) */
         VECTORS (X) : origin=0x00010020 length=0x00000020
         FLASH_CODE (RX) : origin=0x00010040 length=0x4000 - 0x40 fill=0xFFFFFFFF /*sector 4*/
         FLASH0 (RX) : origin=0x00028000 length=0x00200000 - 0x28000
         STACKS (RW) : origin=0x08000000 length=0x00001500
         RAM (RWX) : origin=0x08001500 length=0x0007EB00

    }

    SECTIONS
    {
         /* USER CODE BEGIN (5) */
        .intvecs : {} > VECTORS
        .text align(32) : {} > FLASH_CODE
        .const align(32) : {} > FLASH_CODE
        .cinit align(32) : {} > FLASH_CODE
        .pinit align(32) : {} > FLASH_CODE


        .bss : {} > RAM
        .data : {} > RAM
        .sysmem : {} > RAM

        /* USER CODE END */
    }