Automatic code generation for NEC Electronics Flash MCUs

by Anders Holmberg, IAR Systems, Steve Redpath, NEC Electronics Europe, and Micael Borgefeldt, IAR Systems

For many years now, IAR Systems has developed language tools and debuggers for NEC Electronics. The strong partnership between the two companies ensures up-to-date tools, support for new cores and debugger functionality.

The NEC Electronics Flash MCU product line includes a wide range of general purpose, LCD control, CAN interface, motor control and remote control microcontrollers:

8-bit: 78K0S/78K0
16-bit: 78K0R
32-bit: V850ES/V850E1/V850E2

Many of these MCUs are popular in the automotive industry but we can see that they are used also in a growing number of industrial automation products and medical devices—event-driven systems that are typically used for monitoring, metering and control. These applications have in common that they often benefit from a state machine approach in the design phase.

In response to the need for an integrated chain of development tools for the Flash MCU product line, complete build integration between IAR visualSTATE and IAR Embedded Workbench is now available for both 78k and V850, allowing automatic code generation.

Using state machines in embedded systems

The concept of state machines is well known for anyone working with embedded systems software. It is also well known that designing and coding complex state machines can be a challenging task.

So, in what way are state machines challenging? A few of the challenges are the following:

How do I design my state machine? Pen and paper? A technical drawing tool? A CASE tool?
Transforming the design into code. How do I ensure that the complete design is actually coded and with the intended behavior? And how do I fit the design onto my MCU that I have chosen to be as small (in terms of memory) as possible?
Testing and validation. For a really complex design, how can I know that I have achieved sufficient coverage of states and transitions between states?
Adding new features and maintaining existing functionality.
Debugging the design on target. Mapping state machine concepts to the C or C++ level can be very difficult, especially in the presence of high-level design constructs such as concurrency and hierarchy.

IAR visualSTATE bridges the gap between the pen and paper and the MCU. It uses only the state machine subset of UML to avoid the notational overhead associated with full UML. Also, IAR visualSTATE can be used to design arbitrarily complex state machines with any number of parallel regions and to any hierarchical depth. And since the state machine subset is relatively small in terms of symbols, the design environment can be kept very simple and thus easy to use.

In figure 1 you can see a snapshot of the design environment. In addition you can simulate your design in a graphical simulator environment to make sure your design assumptions hold, starting when you have saved the very first iteration of the design.

Figure 1: A snapshot of the design environment

Automatic code generation

Addressing the design and initial testing is of course a good thing, but to cope with the second challenge we need to take a step further. Automatic code generation from design models of different types has been around for years and is in widespread use for desktop PC and server applications with excellent results. However, the trend has not spread into the typically resource constrained embedded space. One reason for the slow acceptance is the belief that automatic code generation from high-level designs invariably lead to extended code and resource waste.

The fact is that a modern and specialized code generator can outperform a human programmer while at the same time maintaining code style consistency by applying predictable transforms at all times. If you are using visualSTATE for code generation you have the choice of generating code that is extremely compact due to a novel way of packing the information into tables or generating code that is easy to understand. The tradeoff is thus clear:

Use the table format to utilize the memory of your chosen NEC MCU to its fullest and readability of the generated code is not a must. Due to the nature of the generated code execution speed can be a bit slower than for human readable code.

Use the human readable format if you really have to understand the generated code or must get it assessed for quality purposes. This format is also the first choice if you have tight speed requirements.

That said, it may turn out that for a small design the readable code is actually smaller (and faster) than the table based code.

One of the reasons that automatic code generation has been viewed as problematic is the fact that if your problem is limited to for example a set of state machines, the notational overhead needed to get a well-formed design model in a richer modeling language like full UML manifests itself as excess code at code generation time. That extra code is only extra structure and no real functionality. If you really need full-blown object-oriented features at the design stage, then going for a full UML tool is the right way to go. But for a typical control application it just holds the promise of complicating the design with no real advantage.

Thus IAR visualSTATE enables state machines to be implemented in anything from NEC’s smallest 8-bit 78K0 to the largest 32-bit V850 microcontrollers.

Reducing the need for painful testing

We already have mentioned the state machine simulator that can be used to try out design ideas and assumptions in parallel with the design work. In addition to the test environment visualSTATE features a formal model checker that utilizes powerful verification techniques to answer questions about the soundness of the design. The most important properties that the verification can detect are:

So called dead-ends, which are states or sets of states that once entered can never be leaved. A dead-end is the result of one or more conditions on a set of transitions that can never be fulfilled. A deliberately designed dead-end can have its use in some situations, but it is almost always a sign that some design assumption does not hold.

Unreachable states and transitions, which in some ways can be regarded as the same problem as finding dead-ends. The root cause is that a set of transition conditions can never be fulfilled.

One interesting aspect of the verification process is that it can detect that a state becomes a dead-end only after being visited for a number of times under certain conditions. This is thus an extremely powerful way of detecting a kind of bugs that otherwise might be very difficult to trigger by traditional testing. This kind of bug might hide for years in a consumer product until suddenly being triggered, which of course also means that it is almost impossible to reproduce it in the development and test environment. An example of how a verification report can look is shown in figure 2. It shows that the model used for this article has no dead ends, but have defined elements that are not used in the model. This can be seen as the equivalent to compiler warnings about unused variables and might be an indication that the design should be reviewed for the cause of these warnings.

Figure 2: Example of a verification report

Testing of the state machine in a real environment is of course a necessity and this is realized by using a combination of IAR Embedded Workbench with integrated debugger and NEC’s emulators which together provide a fully integrated and real time debug environment, and the capability to debug the state machine on target hardware in the same IDE on which it was developed. NEC Electronics provides a range of compatible emulators, target boards and starter kits for all its All flash 8, 16 and 32 bit microcontrollers for testing and evaluating your developed software.

Figure 3 is a snapshot from a debug session on a 78K0R Cool-it starter kit showing the C-SPY debugger augmented with a few visualSTATE-specific windows showing a snapshot of the system upon hitting a state machine breakpoint.

Figure 3: Debug session on a 78K0R Cool-it starter kit

In addition the current state vector can also be shown directly on the design level as in figure 4. The model information you receive during debugging is highly configurable to meet both space and time constraints in the debug environment and on the target controller.

Figure 4: Design level view of the current state vector

Imagine for example the electronic control of an industrial system or home appliance. A set of complicated and unforeseen events are selected by the operator leading to a dead-end state which could lead to the system or appliance being rendered inoperative. A combination of simulation and real time debug and test tools from IAR Systems and NEC Electronics means these types of bugs can be detected during the development stage.

Conclusion

State machines provide an effective means for developing real time embedded software but this should not be at the expense of code quality, efficiency or reliability. IAR Embedded Workbench and IAR visualSTATE coupled with NEC Electronics extensive range of Flash MCUs with dedicated debug and evaluation tools provide the embedded designer with a highly integrated and effective means to develop their system hardware and software.

NEC Electronics and IAR Systems go back a long time. The first contacts between the two companies took place in the mid-1980s when NEC asked IAR Systems for language tools for the µCOM87 family on an Intel MDS. IAR Systems was just a small startup company, but turned down this business opportunity since Intel MDS was not on its roadmap.

A few years later, IAR Systems got a second chance to deliver software to NEC, this time both language tools and a debugger. A development contract was signed and the rest is history. Since then, NEC Electronics is one of the major driving forces behind new technology and new features in IAR Embedded Workbench: C++, MISRA C, and the Japanese user interface.