To do your best, know your tools
An embedded systems engineer is only as good as their knowledge of the tools they use. Using the right tool for the job can drastically speed up development but doesn’t necessarily ensure success. The developer needs to understand the intricacies of the tool in order to be successful.
Take for example an apparently simple task of setting the configuration bits of an NXP Kinetis-L microcontroller using the IAR compiler and Processor Expert.
The configuration bits control the NMI and Reset pins' functions along with initial clock and boot options. In this sample the configuration bits are located starting at hex address 0x400, just following the interrupt vector table. Table 1 shows the description of what each address controls.
Table 1 – Configuration Bits
A developer has a number of options available on how to set these memory regions. First, they could set the values using a table mapped within the linker file. Or, they could use Processor Expert to set the values.
With the values for the configuration area set, the developer could now compile code and load it onto the target. One might then expect the process to set the configuration bits in flash. Running the code, however would reveal a different story! Despite having configured the bits properly, the developer would find that on the target, the bits are still set to the default values.
What could possibly have gone wrong? Using IAR, a developer could run a verification check between the code to be loaded and what exists in memory on the target. They would find that the verification failed. Something is preventing the configuration bits from being programmed.
The culprit turns out the IAR toolchain, which is preventing the configuration area from being updated. The reason for this behavior is that these configuration bits can be dangerous to program because they can lock the entire device. Inadvertently programming them could be disastrous, so the toolchain automatically blocks write permission to this area of the target, without any mention to the developer. The toolchain assumes the developer knows that this is how the toolchain behaves.
To program the configuration bits a developer must override this default behavior manually by adding special parameters to the flash settings configuration, as shown in Figure 1. Only after a developer has done this are they able to successfully write the configuration bits. A developer without experience or knowledge of this "feature" could easily be thrown off and left scratching their heads for days, especially since these parameters are nicely hidden within multiple submenus.
Figure 1 – IAR Overide Parameters
The moral of the story is that developers and project teams need to schedule time to regularly update themselves and learn more about the tools they are using on a day-to-day basis. In addition, project managers need to recognize that the schedule must have time allocated for learning the tools. Developers are usually aware of their toolchain's day-to-day features, but it’s the tool's little intricacies that can truly make the difference and provide the most powerful features.
Do you know all the intricacies of your toolchain? If not, what are your next steps to raise the bar?
Jacob Beningo is principal consultant at Beningo Engineering, an embedded software consulting company. Jacob has experience developing, reviewing and critiquing drivers, frameworks and application code for companies requiring robust and scalable firmware. Jacob is actively involved in improving the general understanding of embedded software development through workshops, webinars and blogging. Feel free to contact him at firstname.lastname@example.org, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.