I have been running recently into an interesting case where the GNU ARM Linker failed to link an application with strange error messages:
The ARM mbed USB MSD bootloader which is used on many silicon vendor boards has a big problem: it is vulnerable to operating systems like Windows 10 which can brick your board (see “Bricking and Recovering OpenSDA Boards in Windows 8 and 10“). To recover the board, typically a JTAG/SWD programmer has to be used. I have described in articles (see links section) how to recover from that situation, including using an inofficial new bootloader which (mostly) solves the problem. The good news is that ARM (mbed) has released an official and fixed bootloader. The bad news is that this bootloader does not work on every board because of a timing issue: the bootloader mostly enters bootloader mode instated executing the application.
More and more these very-very-high-resolution (UHD, Ultra-High-Density) notebook displays show up in my class rooms.These displays have 3100×1800 or even more pixels, making it great for watching high-resolution videos or for playing games (maybe?). But such a high-resolution makes many tools including Eclipse very hard to use, because the toolbar icons get so tiny that they are really hard to hit with a mouse cursor on Windows:
Most of the time I’m using a dedicated terminal program like Termite or PuTTY to connect to a board using virtual or non-virtual COM port. Another way is to use the Eclipse built-in Terminal view: that way no extra program is needed to communicate with a real or virtual COM port to my target device:
It can happen to everyone using Eclipse: launching Eclipse with workspace, and then it is stuck loading it. As a last resort, create a new workspace and go on? Possible, but painful, right? For some time I have a strange issue nagging me: from time to time, I’m not able to switch to a workspace which worked before. The IDE starts loading, but then is stuck:
For several projects I’m using library projects: I build a library and then use that library in the other project. If I change something in a library, I want to run make both on the referenced libraries and rebuild my application if needed. If you don’t know how to do this, then read on… 🙂
(… actually it means workign around known Eclipse CDT bug too….)
ARM Cortex-M microcontrollers can have multiple memory controllers. This is a good thing as it allows the hardware to do multiple parallel memory read/writes. However this makes the memory map more complicated for the software: it divides the memory into different regions and memory segments. This article is about how to enable FreeRTOS to use multiple memory blocks for a virtual combined memory heap:
Sometimes it is handy to know in the running application the start address, end address and the size of a linked section, e.g. to know the boundaries of RAM or FLASH areas. This means that from the application code I can get access to knowledge of the GNU linker:
The tools and IDE market is constantly changing. Not only there is every year at least one new major Eclipse IDE release, the commercial tool chain and IDE vendors are constantly changing the environment too. For any ARM Cortex-M development, the combination of Eclipse with the GNU tool chain provided by ARM Inc. is the golden standard. But this does not mean that things can be easily moved from one IDE package to another.
While moving between Eclipse versions and GNU versions is usually not a big deal at all, moving between the Eclipse build tool integration is usually not simple. While the GNU MCU Eclipse plugins are widely used (see Breathing with Oxygen: DIY ARM Cortex-M C/C++ IDE and Toolchain with Eclipse Oxygen), the Eclipse based IDEs from the silicon vendors or commercial Eclipse toolchain vendors are using their own GNU toolchain integration. Which means the project files are not compatible :-(.
Eclipse is probably the most used and de-facto standard IDE for any development for ARM Cortex or any other devices. It is very easy these days to construct an unlimited and unrestricted IDE (see “Breathing with Oxygen: DIY ARM Cortex-M C/C++ IDE and Toolchain with Eclipse Oxygen“). Up to the point that I can pack it into a .zip file and pass it around e.g. in a class room environment, so no installer at all is needed with the exception of the debug probe USB drivers. As Eclipse is using a Java Virtual Machine (VM), it is a good idea to bundle the VM with the IDE, and this article is about how to do this.
Eclipse as IDE takes care about compiling and building all my source files. But in an automated build system I would like to build it from the command line too. While using make files (see “Tutorial: Makefile Projects with Eclipse“) is an option, there is another easy way to build Eclipse projects from the command line:
FreeRTOS seems to get more and more popular, and I think as well because more and more debugger and Eclipse IDE vendors add dedicated debugging support for it.
The benefit of an IDE like Eclipse is: it makes working with projects very easy, as generates make files and it takes and automatically manages the make file(s). But sometimes this might not be what I want because I need greater flexibility and control, or I want to use the same make files for my continues integration and automated testing system. In that case a hand crafted make file is the way to go.
One thing does not exclude the other: This article explains how to use make files with Eclipse with similar comfort as the managed build system in Eclipse, but with the unlimited power of make files:
A bootloader on a microcontroller is a very useful thing. It allows me to update the firmware in the field if necessary. There are many ways to use and make a bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“). But such a bootloader needs some space in FLASH, plus it needs to be programmed first on a blank device, so a JTAG programmer is needed. That’s why vendors have started including a ROM bootloader into their devices: the microcontroller comes out of the factory with a bootloader in FLASH. So instead writing my bootloader, I can use the one in the ROM.
And as with everything, there are pros and cons of that approach.
If you are like me – someone who always wants to know what the compiler generates for a piece of source code – then have a look at the Compiler Explorer: A web-based compiler code comparison tool:
Thanks to Matt Godbolt, I can select different compilers and compare their output for a given source code. Very useful to see the impact of a compiler optimization or to compare different GCC compiler versions.
Happy Comparing 🙂
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge, with the following major changes and updates:
- Complete refactoring for 1-Wire stack and DS18B20 temperature sensor components
- Added HID Joystick device class to the FSL_USB_Stack
- New SDK_Timer component to work with Kinetis SDK
- New ST756P LCD driver component
- New TSL2561 digitial temperature sensor driver
- Added ReadByte() and WriteByte() GenericI2C functions
- Added 64bit mapping functions to Utility
- added configUSE_NEWLIB_REENTRANT and newlib reentrancy support to FreeRTOS
- Pull resistor support for SDK_BitIO
- Many smaller bug fixes and enhancements
For reliable applications, I avoid using functions of the standard libraries. They are banned for most safety related applications anyway. I do not use or avoid
printf() and all the other variants, for many reasons including the ones listed in “Why I don’t like printf()“. Instead, I’m using smaller variants (see “XFormat“). Or I’m using only the thread-safe FreeRTOS heap memory allocation which exist for many good reasons.
Things get problematic if
malloc() still is pulled in, either because it is used by a middleware (e.g. TCP/IP stack) or if using C++. Dave Nadler posted a detailed article (http://www.nadler.com/embedded/newlibAndFreeRTOS.html) about how to use newlib and newlib-nano with FreeRTOS.