Use the NXP Processor Expert to Jump-start Driver Development

Shock your coworkers with your processor expertise while having very little processor expertise. How is that possible? With NXP’s Processor Expert tool. We’ve taking advantage of this tool on a new project at DornerWorks which required us to develop hardware and software for a NXP Kinetis E Series microcontroller. We had fully functioning drivers for our board in minutes and we were able to take all the credit for it. Well, now we come clean—we had help from Processor Expert!  Here’s a list of things we liked and did not like with NXP’s Processor Expert.

The Expert (the good):

• We were amazed at how quickly we had drivers up and functioning properly. It was as simple as dragging the component in, configuring it in the GUI, and selecting “Generate Code”. We were sending and receiving CAN messages within a few hours of development.
• The generated code is well documented and NXP provides examples on how to use most components.
• Seamless integration with the MQXLite RTOS. The GUI allowed us to configure all of our tasks (stack size, priority, etc) and select which features of the RTOS to include. By adding or removing RTOS features we were able to keep the text size down.
• Configuring interrupts was very simple. Each component’s GUI has an interrupt tab that allows you to enable it and set its priority. The whole interrupt process in Processor Expert is a little obfuscated from the user. The generated code provides an “Events.c” file which provides ‘handlers’ for the interrupts. The actual interrupt handlers are a bit more complicated, especially when used with MQXLite. Fortunately, I haven’t had to look into this much because the “Events.c” interrupts seem to magically work thus far.
• Each component has a list of functions which you can select to be generated or not. I found myself looking through these functions to get a better idea on how the component operated. This feature was useful as another way to keep text size down and also as a way to have cleaner code in general.
• The NXP forum is available for support. Someone will always at least attempt to help you with your problem.
• All of the pins and capabilities of the processor are spelled out in Processor Expert. We rarely reference the datasheet because most of the information is provided already (up to you if you trust it or not). No need to go look up all the registers in the reference manual either as they are configured for you in the generated code.
• The tool is even helpful for hardware development. We found a way to export all the pins and their functions to a .csv file which we then used to create the schematic symbol.

The Novice (the not so good):

• Eclipse isn’t all bad but using Processor Expert does require you to use Kinetis Design Studio which is basically a version of Eclipse. Using your preferred editor is definitely possible but I find myself resorting to Eclipse simply because of its integration with Processor Expert. If there is an interface to the tool outside of KDS, it would be useful but I have yet to find it.
• Some components are more complicated than others which makes them difficult to configure. Processor Expert’s user interface sometimes makes finding the appropriate setting for a component more difficult than it needs to be. For instance, they have a “Basic” or “Advanced” view. I see no need for the differentiation as I always switch to “Advanced” when configuring a component.
• You have to manually install Processor Expert updates which are inexplicably hard to find
• All of the generated code is helpful but eventually while debugging you’ll have to dig into it and figure out what exactly it is doing. If this code was written yourself, you obviously would already have a deep understanding of it. As an example, when using the Flash component to write to flash, I noticed that my data was being written improperly. It turns out that the Flash_Write() function requires a pointer to a buffer on the heap and not the stack. This was not made clear in the documentation or function description.
• Processor Expert provides many different components and not all of them have sufficient descriptions. Many of these can be used to accomplish the same tasks which makes it difficult to decide which one is best for your application. There are even legacy components which make finding the appropriate component even harder. From the research I have done, the best components are the “_LDD” (Low-level Device Driver) ones.
• We prefer to use Git for software development. Things get ugly when you try to maintain the custom “.pe” file format which is used to store all of your Processor Expert configurations. All of the developers need to access this file but it is not mergeable. This required us to re-enter a lot of settings on our individual machines so that we could work on things in parallel. Even with giving it special attention, we ended up in a lot of broken builds. We eventually decided to version control the “.pe” file but not the code that it generated. Once we’re done making edits with Processor expert, we’ll commit the generated code and leave it unchanged (hopefully). I’m not sure a different version control tool would help either. The proper solution is to make the “.pe” file mergeable.
• The generated code is not without bugs. I’ve noticed a few in particular with our selected microcontroller and the package we’ve chosen for it*:
  • In the generated code for the ADC initialization (AdcLdd1_Init), the reference voltage selection in the ADC_SC2 register was configured correctly but then written to again later on in the init function, overwriting the proper bits. This required a considerable amount of time to find and reconcile. It seemed to be a bug in Processor Expert’s code re-generation; the correct code was there but it didn’t delete the old configuration.
  • A similar issue was encountered when initializing the flash component (FLASH1_Init). The flash needs a clock of 1MHz but the generated code was setting the FTMRE_FCLKDIV register to 0x13 which is not correct for a BUSCLK at 24MHZ. We changed this value to 0x17 and marked the component to not be generated again (to prevent overwriting our change).

 

NXP’s Processor Expert tool is extremely effective at rapidly providing drivers for your processor.  In our industry, you can’t stress enough how helpful that is. With our success using Processor Expert, other projects at DornerWorks have also started to use it. The tool is not perfect, but the good outweighs the not-so-good, and good engineering always improve the output of the tool. So our jobs are safe… even Processor Experts need help from time to time.

*Note: We were using KDS 3.2.0, PE 3.0.2.b151214, with the MKE06Z128VLK4 80-pin package.