Installation Steps
AM62X/AM62AX/AM62PX/AM62DX/AM275X
No seperate configurator is required for MPU/SPMCU.
AM275X
Note:
Please note that this is an indicative image, actual soc and versions would change
Installation Instructions
Please follow the steps below to install the required tools and components:
- Install Locations:
- Install the MCU+SDK Installer at
{install_dir}/ti/{MCU+SDK_am275x_installer}.
- Install the MCAL AM275x/MPU Installer at
{install_dir}/ti/{MCAL_am275x_installer}.
- Install Code Composer Studio (CCS) and the ARM Clang Compiler at
{install_dir}/ti.
- Default Installation Path:
- If the default installation paths are used for Tools, MCAL, and MCU+SDK, no updates will be required in the
Rules.make file for MCAL makefile.
Back To Top
Directory Structure
Post installation of MCUSW, the following directory would be created. Please note that this is an indicative snap-shot. Modules/Drivers could be added/modified.
Top Level Directory Structure
MCAL
MCAL Directory structure, contains MCAL modules, build files. Please note that this is an indicative snap-shot. Modules/Drivers could be added/modified.
Back To Top
The following diagram (or screenshot) shows an example layout of the MCAL directory structure:
MCAL Modules
This structure is organized to separate driver sources, configuration files, build artifacts, and examples.
Top-Level Directories
MCAL Release Directory Structure
This structure separates driver sources, configuration files, build artifacts, and example applications.
| Directory | Location | Description | Notes |
build/ | {MCAL_INSTALL_PATH} / build | Contains makefiles and scripts used to build the MCAL SDK. | Defines logic for compiling and linking MCAL modules and examples. |
csp/ | {MCAL_INSTALL_PATH} / csp | Contains CSP (Configuration Safety Package) files and safety documents. | Complements certified releases with configuration-specific safety data. |
mcal/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal | Core MCAL driver source files organized by module. | Each subdirectory corresponds to a specific MCAL driver. |
board/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / board | Board-specific code (e.g., NOR Flash) used during bring-up and testing. | Not FSQ-qualified; excluded from safety scope. |
Adc/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / Adc | ADC driver source files. | |
Can/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / Can | CAN driver source files. | |
CddUart/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / CddUart | UART driver source files. | |
Eth/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / Eth | Ethernet (Eth) driver source files. | |
EthTrcv/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / EthTrcv | Ethernet Transceiver driver source files. | |
Fls/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / Fls | Flash driver source files. | |
Gpt/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / Gpt | GPT driver source files. | |
Mcu/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / Mcu | MCU driver source files. | |
Wdg/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal/Wdg | Watchdog (WDG) driver source files. | |
examples/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / examples | Example projects demonstrating MCAL driver usage. | |
examples/Utils | {MCAL_INSTALL_PATH} / mcal_drv / mcal / examples / Utils | Shared non-AUTOSAR utility APIs (e.g., ISRs). | Not AUTOSAR-compliant; avoid in production or AUTOSAR projects. |
examples_config/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / examples_config | EB Tresos-generated config files for example projects. | For demonstration use only. |
include/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal / include | Shared headers (e.g., macros, typedefs) used across drivers. | |
mcal_config/ | {MCAL_INSTALL_PATH} / mcal_drv / mcal_config | EB Tresos plugins/templates for MCAL configuration and integration. | Includes example .epd/.xdm and generated files. |
MCAL Driver Version And Source Files Mapping
| Module | Version Used | Applicable Source Files |
| Adc | V0 | Adc.c Adc_Irq.c Adc_Priv.c Adc_Utils.c |
| Can | V1 | Can.c Can_Priv.c Can_Irq.c Can_Mcan.c mcan.c |
| CddIpc | V1 | Cdd_Ipc.c Cdd_IpcIrq.c ipc_mp.c ipc_utils.c ipc_mailbox.c ipc_virtio.c ipc_api.c ipc_soc.c hw_mailbox.c |
| CddUart | V0 | Cdd_Uart.c Cdd_Uart_Irq.c Cdd_Uart_Priv.c uart.c |
| Dio | V0 | Dio.c Dio_Platform.c |
| Fls | V0 | Fls.c Fls_Ospi.c Fls_Irq.c lld_ospi.c |
| Gpt | V1 | Gpt_Gptimer.c Gpt.c Gpt_Irq.c |
| Icu | V0 | Icu.c Icu_Priv.c Icu_Irq.c ecap.c |
| Pwm | V0, V0_1 | Pwm.c Pwm_Irq.c Pwm_Priv.c Pwm_Ehrpwm.c lld_hrpwm.c lld_epwm.c |
| Spi | V0 | Spi.c Spi_Priv.c Spi_Utils.c Spi_Irq.c Spi_Mcspi.c mcspi.c |
| Wdg | V0 | Wdg.c Wdg_Priv.c |
Notes on Usage
- Integration into AUTOSAR
When integrating MCAL drivers into an AUTOSAR environment, be sure to replace:
- Bsw_Stubs: with real BSW modules provided by your AUTOSAR supplier or integrator.
- Non-AUTOSAR Examples
The examples folder is primarily for demonstration and testing. The utilities in examples/Utils are not meant to be used in a final AUTOSAR system.
- Binary Output
Final build artifacts (libraries, executables) are placed under {MCAL_INSTALL_PATH}/binary, typically organized by target device or platform.
- The
Adc module is only applicable for the AM275x device.
- The
Icu and Pwm modules are not supported on MPU devices such as AM62x.
- The
CddUart module is not applicable for AM62x and AM62Px MPU devices.
- The source file
ecap.c is not applicable for the AM62x device.
- The source files
lld_hrpwm.c and lld_epwm.c are not applicable for the AM62x device.
- The
Spi_Dma.c file is not applicable for MPU devices.
- All module-specific source files referenced above are located in the following path:
{MCAL_INSTALL_PATH}/mcusw/mcal_drv/mcal/<module>/
- Customers must use the specified version folders and files in their Makefile as mentioned in the documentation.
Failure to do so may result in:
- An incorrect build
- Or the build targeting the wrong device
MCAL Examples
Contains demo applications that demonstrate use of MCAL modules. An integrator could refer these to determine the dependencies of the module.
MCAL Examples
MCAL Examples Configuration
Contains configurations (standalone i.e. configuration for given module and its dependencies, such as Gpt (not dependent on other modules)
MCAL Example Configurations
Back To Top
Build
MCAL employs make based build mechanism. When building on Windows based machine, tool such as gmake could be used.
Setup Build Environment
Following changes are required to be performed in Rules.make to build
- Rules.make can be found at ($SDK_INSTALL_PATH)/mcusw/build, When building on Windows environment ensure to update variables under ifeq (Windows_NT,Windows_NT)
- Build MCAL Examples
- Set BUILD_OS_TYPE = baremetal to build MCAL examples/libraries
- Specify the location of the compiler
- In Rules.make, update SDK_INSTALL_PATH to specify location of the SDK installation.
- One can override compiler path by updating variable TOOLCHAIN_PATH_R5
- Make sure that CCS path is correctly set in variable CCS_INSTALL_PATH
- Modify Rules.make file as per Soc
- AM62X : By default AM62X_MCU_SDK_VERSION is set to am62x_xx_xx_xx_xx. To use with specific SDK, update AM62X_MCU_SDK_VERSION in Rules.make file. Update ENABLE_UART_BOOTMODE=no to build in No Boot Mode. By default it is yes and will build in UART boot mode.
- AM62AX: By default AM62AX_MCU_SDK_VERSION is set to am62ax_xx_xx_xx_xx. To use with specific SDK, update AM62AX_MCU_SDK_VERSION in Rules.make file.
- AM62PX: By default AM62PX_MCU_SDK_VERSION is set to am62px_xx_xx_xx_xx. To use with specific SDK, update AM62PX_MCU_SDK_VERSION in Rules.make file.
- AM62DX (AM62D-AWE-SDK): By default AM62DX_MCU_SDK_VERSION is set to am62dx_xx_xx_xx_xx. To use with specific SDK, update AM62DX_MCU_SDK_VERSION in Rules.make file.
- AM275X: By default AM275X_MCU_SDK_VERSION is set to am275x_xx_xx_xx_xx. To use with specific SDK, update AM275X_MCU_SDK_VERSION in Rules.make file. Please follow the steps below to install the required tools and components:
Note: Please refer release note for compatible MCU_PLUS_SDK version.
Build Everything MCAL
With steps listed at (Setup Build Environment) all MCAL modules can be built
AM62X
- Ensure BUILD_OS_TYPE = baremetal
- Go to folder ($SDK_INSTALL_PATH)/mcusw/build
- gmake -s all BOARD=am62x_evm SOC=am62x BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- On Successful compilation, binary folder would be created in ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am62x_evm/
- Note: To build the .xer5f file for AM62X, which can be loaded and run via CCS, use the following build command: gmake -s all BOARD=am62x_evm SOC=am62x BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal ENABLE_UART_BOOTMODE=no
AM62AX
- Ensure BUILD_OS_TYPE = baremetal
- Go to folder ($SDK_INSTALL_PATH)/mcusw/build
- gmake -s all BOARD=am62ax_evm SOC=am62ax BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- On Successful compilation, binary folder would be created in ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am62ax_evm/
AM62DX
- Ensure BUILD_OS_TYPE = baremetal
- Go to folder ($SDK_INSTALL_PATH)/mcusw/build
- gmake -s all BOARD=am62dx_evm SOC=am62dx BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- On Successful compilation, binary folder would be created in ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am62dx_evm/
AM62PX
- Ensure BUILD_OS_TYPE = baremetal
- Go to folder ($SDK_INSTALL_PATH)/mcusw/build
- gmake -s all BOARD=am62px_evm SOC=am62px BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- On Successful compilation, binary folder would be created in ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am62px_evm/
AM275X
- Ensure BUILD_OS_TYPE = baremetal
- Go to folder ($SDK_INSTALL_PATH)/mcusw/build
- gmake -s all BOARD=am275x_evm SOC=am275x BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- On Successful compilation, binary folder would be created in ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am275x_evm/
Other useful commands
- To Clean all examples (all MCAL drivers and their associated examples)
- To Build all examples (all MCAL drivers and their associated examples)
- gmake -s all BOARD=am62x_evm SOC=am62x BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- gmake -s all BOARD=am62ax_evm SOC=am62ax BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- To build specific example (associated MCAL driver will also be built)
- gmake -s can_app BOARD=am62x_evm SOC=am62x BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- gmake -s can_app BOARD=am62ax_evm SOC=am62ax BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal
- Other examples cdd_ipc_app, dio_app, eth_app, eth_virtmac_app, gpt_app, mcspi_app, wdg_app, mcu_app
- The above list is indicative and examples could be added/deleted
- TO build cdd ipc linux application on AM62X use below command.
- gmake -s cdd_ipc_app_rc_linux BOARD=am62x_evm SOC=am62x BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal CDD_IPC_LINUX_BUILD=yes
- TO build cdd ipc linux application on AM62AX use below command.
- gmake -s cdd_ipc_app_rc_linux BOARD=am62ax_evm SOC=am62ax BUILD_PROFILE=release CORE=mcu0_0 BUILD_OS_TYPE=baremetal CDD_IPC_LINUX_BUILD=yes
- To determine example name, refer makefile in subdirectory of ($SDK_INSTALL_PATH)/mcusw/mcal/examples/
- gmake -help, will list available target names
Profiles
- Debug : Mostly used to development or debugging
- Release : Recommended to be used for production / profiling performance
Examples Linker File (Select memory location to hold example binary)
The example applications use different memory and this could be changed/re-configured.
- linker_r5.lds defines the memory locations used by the MCAL examples.
- The linker file is specific to a device/core and available at ($SDK_INSTALL_PATH)/mcusw/build/(device family name)/(core name)/linker_r5.lds
- In case of AM62x, ($SDK_INSTALL_PATH)/mcusw/build/am62x/mcu0_0/linker_r5.lds
- In case of AM62Ax, ($SDK_INSTALL_PATH)/mcusw/build/am62ax/mcu0_0/linker_r5.lds
- In case of AM62Dx (AM62D-AWE-SDK), ($SDK_INSTALL_PATH)/mcusw/build/am62dx/mcu0_0/linker_r5.lds
- In case of AM62Px, ($SDK_INSTALL_PATH)/mcusw/build/am62px/mcu0_0/linker_r5.lds
- In case of AM275x, ($SDK_INSTALL_PATH)/mcusw/build/am275x/mcu0_0/linker_r5.lds
- Used for MCAL example application, that would be hosted on MCU 0 0
- Memory that is used to hold, code, data impacts performance of the driver
- When placed in internal memory (such OCMRAM) best performance is noted
- It's recommended to place ISR code and other frequently used code/data in internal memory
Running Examples
IDE
CCS
Please refer (IDE (CCS)) for CCS and GEL setup. In MCU+SDK user-guide inside Getting Started there will be a section called CCS Launch, Load and Run this will have CCS Theia related information, on how to build and run via the CCS-Theia.
Load Example Binaries
AM62X/AM62AX/AM62PX/AM62DX/AM275X
Using Linux boot
- Cdd IPC linux can be tested using linux boot.
- Ensure bootmode of the EVM is configured to SD Card bootmode
- Use Balena Etcher application to flash the linux OS on the SD Card using the file tisdk-default-image-am62xx-evm.wic.xz downloaded from linux sdk
- Once the SD card is flashed, insert the SD Card to EVM and observe the UART logs to make sure the EVM is booted
- For detailed instructions on setting up the SD card and flashing images, please refer to the official TI documentation:
Processor SDK Linux – Create SD Card Guide (AM62x)
Using SBL Bootflow
- In case of AM62X refer [AM62X EVM Setup Page] (https://www.ti.com/tool/download/MCU-PLUS-SDK-AM62X/) for flashing using SBL bootflow
- Follow Documentation >> Getting Started >> EVM Setup
- In case of AM62AX refer [AM62AX EVM Setup Page] (https://www.ti.com/tool/download/MCU-PLUS-SDK-AM62A/) for flashing using SBL bootflow
- Follow Documentation >> Getting Started >> EVM Setup
- In case of AM62PX refer [AM62PX EVM Setup Page] (https://www.ti.com/tool/download/MCU-PLUS-SDK-AM62P/) for flashing using SBL bootflow
- Follow Documentation >> Getting Started >> EVM Setup
- In case of AM62DX refer [AM62DX EVM Setup Page] (https://www.ti.com/tool/AUDIO-AM62D-EVM) for flashing using SBL bootflow
- Follow Documentation >> Getting Started >> EVM Setup
- In case of AM275X refer [AM275X EVM Setup Page] (https://www.ti.com/tool/download/AM275-FREERTOS-SDK) for flashing using SBL bootflow
- Follow Documentation >> Getting Started >> EVM Setup
Note:
To run the example via CCS, you must first flash the sbl_null and initialize the SoC.
After initialization, you can connect the core and run the example via CCS.
For instructions on initializing via sbl_null, please refer to the SDK Document section: Getting Started >> EVM Setup >> Flash SOC Initialization Binary for the corresponding device.
AM62X: Steps to Load Example Binaries
- POWER-ON the EVM.
- Boot the hardware with required boot mode.
- CCS Setup & Steps to run from CCS Refer the [AM62X MCU+SDK] (https://www.ti.com/tool/download/MCU-PLUS-SDK-AM62X/) user guide for generic test setup details and steps to run the examples using CCS.
- Follow Documentation >> Getting Started >> CCS Launch, Load and Run
- Do CPU Reset and Load binary (driver name)_app_mcu0_0_(release or debug).xer5f
- AM62x MCAL Binaries will be available at ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am62x_evm/
- Some of the example applications (ipc) would have more than 1 binaries. The name of the binaries specify the core that it's intended to hosted on
- After loading respective binary, Run example application to be tested.
- Console for demo application logs / messages
NOTE:
- All the AM62X MCAL driver supports AM62Q as well except FLS because AM62Q has different flash chip than AM62X.
For the AM62X device, please run the example using the AM62X SDK UART bootloader.
Steps for setting up the UART bootloader are mentioned in the [MCU+SDK AM62X Documentation] under section [Examples and Demos >> Secondary Bootloader (SBL) >> SBL UART].
The examples are validated using the UART bootloader.
AM62AX: Steps to Load Example Binaries
- POWER-ON the EVM.
- Boot the hardware with required boot mode.
- CCS Setup & Steps to run from CCS Refer the [AM62AX MCU+SDK] (https://www.ti.com/tool/download/MCU-PLUS-SDK-AM62A/) user guide for generic test setup details and steps to run the examples using CCS.
- Follow Documentation >> Getting Started >> CCS Launch, Load and Run
- Do CPU Reset and Load binary (driver name)_app_mcu0_0_(release or debug).xer5f
- AM62Ax MCAL Binaries will be available at ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am62ax_evm/
- Some of the example applications (ipc) would have more than 1 binaries. The name of the binaries specify the core that it's intended to hosted on
- After loading respective binary, Run example application to be tested.
- Console for demo application logs / messages
AM62DX: Steps to Load Example Binaries
- POWER-ON the EVM.
- Boot the hardware with required boot mode.
- CCS Setup & Steps to run from CCS Refer the [AM62DX - (AM62D-AWE-SDK)] (https://www.ti.com/tool/AUDIO-AM62D-EVM) user guide for generic test setup details and steps to run the examples using CCS.
- Do CPU Reset and Load binary (driver name)_app_mcu0_0_(release or debug).xer5f
- AM62Dx MCAL Binaries will be available (at`{MCAL_INSTALL_PATH}/mcusw/binary/(driver name)_app/bin/am62dx_evm/)
- Some of the example applications (ipc) would have more than 1 binaries. The name of the binaries specify the core that it's intended to hosted on
- After loading respective binary, Run example application to be tested.
- Console for demo application logs / messages
AM62PX: Steps to Load Example Binaries
- POWER-ON the EVM.
- Boot the hardware with required boot mode.
- CCS Setup & Steps to run from CCS Refer the [AM62PX MCU+SDK] (https://www.ti.com/tool/download/MCU-PLUS-SDK-AM62P/) user guide for generic test setup details and steps to run the examples using CCS.
- Follow Documentation >> Getting Started >> CCS Launch, Load and Run
- Do CPU Reset and Load binary (driver name)_app_mcu0_0_(release or debug).xer5f
- AM62Ax MCAL Binaries will be available at ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am62ax_evm/
- Some of the example applications (ipc) would have more than 1 binaries. The name of the binaries specify the core that it's intended to hosted on
- After loading respective binary, Run example application to be tested.
- Console for demo application logs / messages
AM275X: Steps to Load Example Binaries
- POWER-ON the EVM.
- Boot the hardware with required boot mode.
- CCS Setup & Steps to run from CCS Refer the [AM275X MCU+SDK] (https://www.ti.com/tool/PROCESSOR-SDK-AM275) user guide for generic test setup details and steps to run the examples using CCS.
- Do CPU Reset and Load binary (driver name)_app_mcu0_0_(release or debug).xer5f
- AM275x MCAL Binaries will be available at ($SDK_INSTALL_PATH)/mcusw/binary/(driver name)_app/bin/am275x_evm/
- Some of the example applications (ipc) would have more than 1 binaries. The name of the binaries specify the core that it's intended to hosted on.
- After loading respective binary, Run example application to be tested.
- Console for demo application logs / messages
Note:
The expected terminal logs for module examples can be found in the MCAL Module User Guide, under the respective module's section.
Back To Top
MCAL Compiler and Assembler Settings Information
This section provides an overview of the compiler and assembler settings required for MCAL product line deliverables. These settings are essential for ensuring that the code is optimized for performance, code size, and safety compliance.
| Category | Flag/Value | Description |
| Target Architecture | -mcpu=cortex-r5 | Targets the ARM Cortex-R5 processor. |
| -mfpu=vfpv3-d16 | Specifies the VFPv3-D16 FPU for floating-point operations. |
| -mthumb | Enables Thumb instruction set for smaller code size and efficient memory usage. |
| Optimization Levels | -Os | Optimizes for code size and execution speed; strikes a balance between binary size and performance. |
| Warning Suppressions | -Wno-unused-command-line-argument | Suppresses warnings for unused command-line arguments. |
| -Wno-unused-function | Suppresses warnings for unused functions. |
| -Wno-c++11-narrowing, -Wno-writable-strings | Handles compatibility with older or specific C++ features. |
| Error Handling | -Werror | Treats all warnings as errors, enforcing strict code quality. |
| Linker Flags | --ram_model | Configures the linker to optimize for execution from RAM. |
| --reread_libs | Forces the linker to re-read libraries, ensuring all required symbols are available. |
| --diag_suppress=10083 | Suppresses specific linker diagnostics (e.g., warning codes). |
| Assembler Flags | -me | Specifies the endianness (-me for little-endian). |
| -g | Generates debugging information in the assembled output, useful for debugging. |
| -mthumb | Configures the assembler to use Thumb instructions, which generate compact and efficient code for embedded devices. |
| --diag_warning=225 | Converts diagnostic code 225 to a warning rather than an error. |
| Debug Symbols | -g | Enables debugging symbols in the compiled code, useful for stepping through code during debugging. | |
Additional Flags and Their Descriptions
| Flag | Description |
-c | Disables linking. |
-qq | Super Quiet Mode. |
--endian=little | Configures the compiler for little-endian mode. |
-Wall | Enables most warning categories. |
-Wno | Disables the specified warning category. |
--abi=eabi | Specifies the application binary interface as ELF. |
--inline_recursion_limit | Limits the number of recursive inline expansions during compilation to avoid excessive code size. |
--symdebug:dwarf | Generates symbolic debug information in DWARF format. Used in arxml files. |
--embed_inline_assembly | Embeds inline assembly in the generated code for optimization. |
-os | Interlists optimizer comments with assembly statements. |
--optimize_with_debug | Fully optimizes code while retaining debug information. |
-DBUILD_MCU0_0 | Identifies Core in the domain. |
-DSOC_AM62X | Device Identifier for AM62X. |
-DSOC_AM62AX | Device Identifier for AM62AX. |
-DSOC_AM62PX | Device Identifier for AM62PX. |
-DSOC_AM62DX | Device Identifier for AM62DX. |
-DSOC_AM275X | Device Identifier for AM275X. |
Note: Define the appropriate -DSOC_xxx flag in the Makefile or environment based on the target device.
This ensures correct configuration is selected during the build. These flags are mandatory for proper compilation.
Detailed Descriptions
1. Target Architecture
The target architecture specifies the hardware environment for which the code is being built:
-mcpu=cortex-r5: This flag instructs the compiler to generate code optimized for the ARM Cortex-R5 CPU.-mfpu=vfpv3-d16: Enables support for the VFPv3-D16 floating-point unit.-mthumb: Generates code in the ARM Thumb instruction set, which is often used for its smaller instruction encoding, ideal for memory-constrained environments.
2. Optimization Levels
The optimization level impacts the performance and size of the generated code:
-Os: Optimizes for smaller code size while maintaining performance. This flag is a balance between binary size and execution speed, making it particularly suitable for embedded systems where memory is limited, but performance is still important.
3. Warning Suppressions
To maintain focus on relevant warnings, the following flags suppress less relevant warnings:
-Wno-unused-command-line-argument: Suppresses warnings for unused command-line arguments.- Additional C++ Flags: C++ builds use extra flags such as
-Wno-c++11-narrowing to handle potential issues arising from compatibility with C++11 features.
4. Error Handling
To ensure high code quality, -Werror is used, treating all warnings as errors, thus stopping the build until all warnings are resolved.
5. Linker Flags
The following linker flags are used to optimize memory handling:
--ram_model: Directs the linker to optimize for running the application from RAM.--reread_libs: Ensures that the linker re-reads libraries to pick up required symbols.--diag_suppress=10083: Suppresses specific diagnostic warnings, making the build output less cluttered.
6. Assembler Flags
The assembler flags are used when generating object files from .asm or .S assembly source files:
-me: Specifies the endianness, with -me indicating little-endian.-g: Includes debugging symbols to help with debugging at the assembly level.-mthumb: Uses Thumb instructions for efficient code generation.--diag_warning=225: Converts the specified diagnostic into a warning, avoiding a build error.
7. Debug Symbols
The -g flag enables the inclusion of debugging symbols in the output, which are vital for troubleshooting during development. This flag is typically used for debug builds.
Note:
Avoid using --scan_libs linker flag as it may lead to redefinition of macro errors during the build as MCAL links MCU+SDK library.
1.12.0