GNU ARM Eclipse plug-ins v2.4.2-201411261616 released | web-jekyll

# GNU ARM Eclipse plug-ins v2.4.2-201411261616 released

Nov 26, 2014 / Liviu Ionescu / gnu, arm, eclipse

Version 2.4.2-201411261616 is a maintenance release; the main improvements include support for Peripherals view in the OpenOCD debug plug-in and the newlib-nano explicit configuration options.

Binary files »

New features:

- [feature-requests:#73] the Peripherals view is now visible in OpenOCD too
- in the C/C++ Build settings, the linker configuration was extended with explicit options to configure the newlib-nano, including setting the _printf_float and _scanf_float symbols
- [feature-requests:#70] the standard Eclipse preference mechanism is now the default mechanism for setting various defaults (more info in the wiki)
- [feature-requests:#72] the `${jlink_path}` is automatically set to the install folder of J-Link, by reading the Windows registry or searching several folders (on macOS or GNU/Linux)
- the `${openocd_path}` is automatically set to the install folder of OpenOCD, by searching several folders
- the Cortex-M7 architecture was added to the compiler list of supported architectures.

The following bugs were addressed:

- [bugs:#128] when closing the Peripherals view, the memory monitors were not disposed; fixed.
- [support-requests:#81] in certain erroneous conditions the debug session hanged; the error processing in the Peripherals view was improved and the problem fixed
- if packs un-archiving failed, the incomplete folders were erroneously preserved; fixed, no partially installed packs left
- in certain conditions, the value for the `fpu_unit=` build option was not appropriate; reset to default.

In the projects generated by the templates, the following issues were addressed:

- [bugs:#129] in the startup code, the data area copy check had a bug related to DATA_END_GUARD_VALUE; fixed
- the origin of the flash area in the memory map for the generic Hello World ARM Cortex-M C/C++ Project was not 0x0; fixed
- the ST HAL library assumes that the SysTick handler is always present and returns; the empty default SysTick handler now returns
- for the large STM32 cores (F3, F4), the startup code was not able to initialise multiple RAM regions, as .data & .bss; fixed; fixed, a new mechanism based on tables was added to startup.c
- the file _write.c, previously located in the system folders was moved to the application folder, since its content is application dependant.

Edit