• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 150 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.

TMS320F280037-Q1: How to decrease the code size of these library

Shuqing Zhou
Intellectual 2275 points
Part Number: TMS320F280037-Q1


Tool/software:

Hi team,

I ask this for my customer.

From the output file of CCS, it can be seen that some driver/library(such as FLASHAPI library) will occupy a lot of flash, and the remaining space is insufficient to hold their application code. So they want to check if it have any method to decrease the code size of theses driver/library.

1. In the customer code, it will consist of two parts: customer's bootloader and application. Since it is the two individual project, so these driver/library will occupy some flash memory in the bootloader project, and it will also occupy some memory in the application at the same time, this caused repeated occupancy. Do we have any suggestion about this? Customer need two teams to develop the bootloader and application, so in two individual projects, for the same driver/library, can we just occupy one flash memory to avoid repeated occupancy?

2. Customer have already use the O2 optimization, do we have the smaller driver/library? For example, the debug version and release version.

BRs

Shuqing

  • 0
    TI__Mastermind 24380 points

    Hi Shuqing,

    Please allow another day for me to review the information. Thanks for the patience!

    Best Regards,

    Allison

  • 0 in reply to Allison Nguyen
    TI__Intellectual 2275 points

    Hi Allison

    Any update?

  • 0
    TI__Mastermind 24380 points

    Hi Shuqing,

    Thanks for your patience on this- was just about to respond :) Below are some suggestions:

    1. Regarding the duplicate code occupancy issue:

    • You are correct that having the same drivers/libraries in both bootloader and application projects can lead to redundant flash memory usage.
    • There are a few approaches you could consider:
      • Optimize the code sharing between bootloader and application:
        • Keep the bootloader minimal with only essential functions needed for its operation
        • Place commonly used drivers/libraries in shared flash sectors that can be accessed by both bootloader and application
      • Memory Management:
        • Carefully plan the flash sector allocation for bootloader and application code to make sure both projects' linker files contain consistent memory mapping information.
        • Use the linker command files to define clear memory boundaries between bootloader and application sections

    2. Regarding code size optimization, linked here for reference is the c28x optimization guide.

    • Compiler Optimization Options:
      • Use optimization level -O2 or -O3 with --mf=0 (optimize for size)
      • Try optimization level -O4 which performs additional post-link optimization considering the entire project view
      • Use the optimizer assistant (View > optimizer assistant) to find the best combination of optimization level and mf setting
    • Code Placement:
      • Place performance-critical code in RAM using .TI.ramfunc sections
      • Only place essential initialization code and frequently used functions in RAM
      • Keep the rest in flash to save RAM space
    • Additional Optimization Tips:
      • Align code and data sections to 128-bit boundaries when mapping to flash memory
      • For EABI executable formats, define uninitialized RAM sections as NOINIT sections
      • Enable prefetch mode and data cache mode for better flash execution performance
    • Debug vs Release:
      • While there isn't a specific "debug" or "release" version of the drivers/libraries, you can:
        • Remove debug-specific code and diagnostics in release builds
        • Use conditional compilation to exclude debug features
        • Optimize function inlining and code structure for release builds

    To caution, remember that the flash architecture imposes restrictions - when erasing, programming, or verifying flash, code cannot execute and data cannot be fetched from flash simultaneously. 

    Best Regards,

    Allison