#19 GNU-ARM Toolchain and Eclipse IDE

Summary

In this lesson, Miro Samek introduces the switch from IAR to the free GNU-ARM toolset, using Eclipse-based Code Composer Studio (CCS) for embedded systems programming. The tutorial guides users through the installation of the toolset, the setup of a project, and the conversion of IAR-specific code to work with the GNU compiler. Key steps include configuring CMSIS, updating startup code, resolving compiler issues, and understanding the use of GNU-specific extensions. The video concludes with debugging the project on a TivaC LaunchPad board and modifying the LED color, offering a hands-on approach to porting embedded code for ARM Cortex-M microcontrollers.

Takeaways

• 😀 The course introduces switching from IAR to the free GNU-ARM toolset with Eclipse-based Code Composer Studio (CCS) for embedded systems programming.
• 😀 Code portability is a key theme, with much of the previous code being compatible with GNU-ARM, thanks to compliance with CMSIS.
• 😀 Some adjustments are necessary to transition code from IAR to GNU-ARM, such as replacing IAR-specific startup code and board support package with GNU equivalents.
• 😀 The recommended development toolset for the TivaC LaunchPad board is Code Composer Studio (CCS), which supports the Stellaris-ICDI debugger interface.
• 😀 When installing CCS, ensure to select the appropriate components like Tiva-C Series support and the GCC ARM Compiler.
• 😀 It's recommended to use separate workspaces for different project groups, especially for this embedded programming course.
• 😀 When creating a new project, choose the correct embedded target (Tiva-C family) and the specific TM4C MCU, and ensure you select the GNU toolset over the default TI compiler.
• 😀 The generated code often needs manual adjustments, including replacing proprietary exception names and modifying the vector table, especially for CMSIS compliance.
• 😀 The generated linker script should be reviewed, as placing the stack at the top of RAM (rather than the bottom) is a safer approach to avoid stack overflow issues.
• 😀 The startup code should use GNU-specific extensions like the 'naked' attribute for stackless functions and the 'weak' and 'alias' attributes for exception handlers, ensuring compatibility and preventing stack corruption.

Q & A

Why was the switch from IAR to GNU-ARM considered a good opportunity?

The switch was an opportunity to review the code and understand 'code portability' in practice. Most of the code written for IAR would work with GNU-ARM due to CMSIS compliance, but a few IAR-specific extensions in the startup code and board support package (BSP) needed to be replaced with GNU equivalents.

What is the key factor when selecting a development toolset for the TivaC LaunchPad board?

The key factor is support for the specific debugger interface. In the case of the TivaC LaunchPad, this is the Stellaris-ICDI interface, which is why Code Composer Studio (CCS) was chosen as the toolset.

What is the role of the 'workspace' in Code Composer Studio (CCS)?

The 'workspace' in CCS groups together related projects. While it's common to use one default workspace, it's recommended to use separate workspaces for different project groups, such as creating a dedicated workspace for the Embedded Programming Course.

What is the purpose of the 'lesson' project name in CCS?

The 'lesson' project name is a generic name for all the projects in the Embedded Programming Course. It is used to clone projects for each lesson rather than creating a new project from scratch every time.

Why did the generated code in CCS have issues with the startup code?

The startup code generated by CCS used proprietary exception names that were not compliant with CMSIS standards. Additionally, it required manual edits to the vector table for each interrupt handler, and the provided exception handlers used infinite loops that would freeze the system.

What is the role of the .lds file in CCS?

The .lds file is the linker script, which tells the linker where ROM and RAM are located in the address space and specifies where to place various program sections. It plays a crucial role in setting up memory allocation and organization.

How did the user address the 'core_cm4.h' missing file error in CCS?

The user solved the missing 'core_cm4.h' error by copying the CMSIS core header files into the project directory and then adding the include directory path to the project properties in CCS.

What changes were made to the startup code to make it compatible with the GNU compiler?

The startup code was rewritten using GNU-specific extensions, making it compliant with the CMSIS 4.3.0 standard. Changes included defining the vector table with a special attribute to place it in the right section of memory and replacing IAR-specific keywords like '__stackless' with GNU equivalents like 'naked'.

Why was the stack placement changed in the linker script?

The stack was moved to the beginning of RAM instead of the end to prevent stack overflow from corrupting other memory sections. With this approach, stack overflow is detected automatically by the HardFault exception.

How did the user fix the issue with '__enable_interrupts()' being an IAR-specific intrinsic?

The user replaced the IAR-specific '__enable_interrupts()' intrinsic with the GNU equivalent, '__enable_irq()', ensuring compatibility with the GNU-ARM toolset.