Embedded UML Target Debugger IBM Rational Rhapsody Target Animation

Transcription

1 Embedded UML Target Debugger IBM Rational Rhapsody Target Animation Index: Behind The Scene Features Overhead Usage Example Advanced Features Your Logic Analyzer for Embedded Software Even software modeled in UML isn t always free from errors. Therefore, debugging remains one of the key tasks in software development. In the context of so-called embedded systems, the hardware used is often proprietary, and some of the errors probably occur only when the software is executed on this hardware. In addition, many embedded systems have to manage limited hardware resources (e.g. memory). When debugging with conventional CASE tools, it is possible to execute the code generated from the model and to animate the model simultaneously. The program behavior can thus be monitored at model level. To this end, run-time information has to be generated on the target system and transmitted to the development PC which is usually handled through so-called code instrumentation. However, there is a major disadvantage to this approach. The code to be executed is unnecessarily loaded with overhead which considerably slows down the actual run-time. A debugging solution is now available that is compatible with Embedded UML Studio and based on a monitor like conventional embedded high-level language debuggers. It offers the benefit of real-time debugging with minimum overhead at UML model level.

2 One advantage of MDD (Model Driven Development) is that models can be tested and debugged at an early stage, usually based on simulation. According to experience, this method helps to identify numerous errors in early process phases. But in many cases, errors occur later, when the code is generated from the UML model and executed on the actual hardware. Target Monitor PC - Debugger Another disadvantage of simulation is the need to provide all external interfaces required for the simulation procedure which can be quite laborious. With the UML Target Debugger, the model can now also be executed on the actual hardware. All required run-time information is provided through a monitor at model level. Thus, animation takes place at model level in parallel to model execution. In addition, information can be transferred from the development PC to the target system, so that UML based tests can be automated on real hardware, e.g. with TestConductor. Behind the scene The debugging technique consists of a target debugger on the host side with a monitor solution on the target side. The target monitor is bundled along with the given Real-Time Operating System (RTOS) code running on the target. The model-based target debugger GUI on the host side receives back annotated trace data from the target monitor. The trace data provides details about the target behavior in real-time. The target debugger re-constructs the behavior of the target in real-time using UML interaction diagrams such as sequence diagram and timing diagram in the GUI. Features deterministic real-time behavior (other than with instrumented code, the new technology does not affect the run-time behavior) live animation of sequence diagrams to trace the event order on target see which instances of your reactive objects (with a statechart) have been created and destroyed navigate through a model element tree to show attributes or the current state of a statechart for any instance display the current values of the highwatermarks when used with the OO-RTX inject events from the host-side and track the reaction of the target (currently only events without arguments are supported) monitor the elapsed time-ticks between two events Willert Software Tools GmbH Page DatS - Embedded UML Target Debugger v9.0 EN

3 Overhead Target Monitor size The target monitor implementation size varies for different debug interfaces mainly based on the APIs available for each interface and the functionality it provides. For both, ARM7 and Cortex-M3, the target monitor memory size varies between1kbyte and 3Kbytes, which is adequate for memory size constrained real-time embedded target systems. ARM7 - memory usage Cortex-M3 - memory usage ROM (bytes) RAM (bytes) Total (bytes) Trace ULINK2* UART * RTA library ROM /302 RAM ROM (bytes) RAM (bytes) Total (bytes) Trace ULINK2* UART * RAM without buffer Time spent in Target Monitor The monitor routine is used for sending notifications such as event consumed, new object created, object destroyed, answering to query about state, attribute value, etc. Among these, the sending notification for event consumption would be the most often used command. The time spent in the monitor routine for sending event consumed notification (per event) for the different types of debug interfaces in both ARM7 and Cortex-M3, is shown to the right. Debug Interface Time spent in monitor routine [µs] ARM7 Cortex-M3 Trace ULINK UART Conclusion Any debugging solution will introduce overhead in the target/embedded software. However, in our solution, the target monitor remains in the production code and occupies between1kbyte and 3Kbyte. This is adequate for code size constrained small embedded target systems. Further, the overhead introduced (size, time spent inside monitor) by our solution is static, constant and known beforehand. Therefore, the end-user has the opportunity to include this delay in the system design phase. As a consequence, the end-user has the chance to make use of a model-based debug solution and at the same time adhere to temporal constraints, thereby not affecting the real-time behavior of the system. All debug interfaces have limited speed. Depending on the number of events, methods such as increasing the buffer size, flushing the overflowing buffer, etc. could be used to handle/enhance the debugging solution. The JTAG based solutions (especially Trace32) are faster (support higher data rates), which implies that more events per time unit can be supported. However, it could result in increasing the time spent inside the monitor routine. In overloaded cases, the end-user has to decide between flushing the events in the overflowing buffer and remaining in busy-wait scenario. Based on the quantitative results we estimate how many events can be transmitted per time unit. Serial (UART) interface and Trace 32 (Buffer E) have the least influence on the real-time behavior of the system. However, it is up to the end-user to consume this delay in the system design phase and decide on permitting the target monitor residing in production code. Target specific Support To achieve a minimal code and run-time overhead, the UML Target Debugger was developed with a very tight hardand software-integration. The downside of this is that for deployment of the UML Target Debugger a specific adaptation to the target Environment is necessary and not included in the product. This adaptation includes CPU specific issues and communication channel issues but may also involve specific requirements of the customers environment and can be made by the customer or Willert Software Tools can be commissioned to develop that. The efford is about one Day. For a number of commercially available platforms, adapters already exist and they are included without charge. They can be used as a base for a customer adapter and are not guaranteed to work on a similar environment. Willert Software Tools GmbH Page DatS - Embedded UML Target Debugger v9.0 EN

4 Usage Example For the first steps with our Embedded UML Target Debugger, it is recommended to use our example model instead of your own model. In this example we will use the Blinky, that comes with every Framework. You should start with the Rhapsody model: Willert\RXF-Eval_Rpy-C-ARM_V6.xx\Samples\Model\Blinky\Blinky.rpy In your Rhapsody Model make sure to have the LiveAnimation stereotype selected in addition to the RXFComponent stereotype for your active component. Make sure you have an empty GettingStarted uvision project you can deploy to. You will find this project in your Samples-Folder. You can now perform a Generate/Make/Run in Rhapsody, which will deploy the files to uvision. After deploying, you have to build the project. The Build process in uvision will generate a xmldata.xml-file. You will need this later. Now you have to configure uvision to communicate with the Target Debugger. Go to Edit -> Configuration and open the Tab Other. Enable UVSOCK and set Port to Embedded UML Target Debugger will use this Port to communicate with uvision. Willert Software Tools GmbH Page DatS - Embedded UML Target Debugger v9.0 EN

5 Now start the Embedded UML Target Debugger on the PC. You will find the Batch File in your Product Folder: Willert\RXF-Eval_Rpy-C-ARM_V6.xx\Tools\TargetDebugger\Embedded_Uml_Target_Debugger.bat XML File The Embedded UML Target Debugger first need to read the XML file which has been generated at the end of the build process in the IDE. This file is typically XMLData.xml which you can open using File / Open XML File or via button on the toolbar. Communication Plugin After the XMLData.xml file was opened, you have to select the target communication plugin you want to use from the drop down list. In the next step you can select the communication parameters depending on the communication interface. This example works with Keil JTAG communication. Choose your uvision-project-file and press OK. This will force uvision to switch to Debug-Mode and start program execution on Target, as the Embedded UML Target Debugger now listens for commands sent from target. In the tree view on the left you can now also see values of attributes, states and highwatermarks. You will see something like the next picture. Info: The Embedded UML Target Debugger also allows you to add your own I/O interface implementation. Willert Software Tools GmbH Page DatS - Embedded UML Target Debugger v9.0 EN

6 Advanced Features Filtering On a larger model, showing all events and attributes is confusing, because it will not fit in a window and will lead to overhead. Therefore we have implemented a filter which can show information for 8 objects as maximum. Please select the Filter tab and enable a filter for the itsproxy1 object (Proxy's first instance). Afterwards the button on the toolbar to enable filter has to be pressed. If the filter is enabled, only events from itsproxy1 are displayed. Event Injection Its also possible to inject events by the Embedded UML Target Debugger. This requires a right-click on the object to which the event will be sent. In the appearing context menu any event can be selected. So its possible to check out the reaction of the target, when the event is received by the object. The Console window shows information on events: which object sends what event to which destination object. You can also click on an attribute: at that moment in runtime, the Embedded UML Target Debugger on the PC will query the target to send the actual value - such information is sent only on request by the PC in order to reduce the I/O traffic as much as possible. The information shown on events is actually transferred in a compact way and not as the strings you see, again to reduce traffic and thus runtime disturbance. Willert Software Tools GmbH Page DatS - Embedded UML Target Debugger v9.0 EN

7 Timing Diagrams The Embedded UML Target Debugger is able to switch from the default sequence diagram view to a timing diagram view. It is a useful diagram, similar to the timing diagrams known from technical datasheets to visualize state changes proportional to the time axis. User defined Types The Embedded UML Target Debugger generally only supports displaying attributes, event arguments etc. interpreted as integer types. But attributes defined inside the UML model might also have different types like e.g. user defined enumerations. In order to handle these attributes and other attributes of the same class which follow behind user defined attributes in the struct, the Target Debugger needs to know their size in Bytes. The sizes are specified inside a <TypeList> in XMLData.xml, but this file gets overwritten with each building in the IDE. However it is supported to store an XML-snippet file called "User- Types.xms" in the IDE project directory and specify user defined type sizes in this file to include those types in every XMLData.xml generation and allow the Embedded UML Target Debugger to visualize it and other attributes correctly. The values of user defined types will also only be shown as integer values, like usually 0 for the first literal of an enumeration, 1 for the second and so on. Serial Communication Buffer Overflows Interrupt based serial communication, e.g. available for the ARM Cortex M3 Keil environment, relies on send and receive buffers. When compiling the monitor libraries (CreateAnimationLibrary project), the buffer sizes and overflow behavior can be set via defines: If WST_MONITORIO_WAIT is defined in the file WST_Product.h, the monitor will wait until it can send data again, when the transmit buffer is full. This way no event will get lost, but the real-time behavior is being influenced on a full buffer. If WST_MONITORIO_WAIT is not defined, events will get lost if the buffer is full. In this case the buffer will be overwritten by new events. The real-time behavior is not affected. In addition, the debugger is informed that events may have been lost. This information is displayed in the error window of the debugger. The best solution in such cases is to increase the value of SEND_BUFFER_SIZE in the monitor I/O file, e.g. WSTMonitorIO_Keil_CortexM3_UART.h, if the available RAM allows that. Willert Software Tools GmbH Page DatS - Embedded UML Target Debugger v9.0 EN

8 Product: EMBEDDED UML TARGET DEBUGGER Author: EIKE RÖMER MARCO MATUSCHEK PADMA IYENGHAR MICHAEL SPIEKER PABLO TECKER WALTER VAN DER HEIDEN JOHANNES TRAGESER Editor: WILLERT SOFTWARE TOOLS GMBH Hannoversche Straße Bückeburg Tel.: IBM is a registered trademark of International Machines Corporation Rational is a registered trademark owned byibm DOORS is a registered trademark owned by IBM Rhapsody is a registered trademark owned by IBM MS Word is a registered trademark of Microsoft Corporation Willert Software Tools GmbH Page DatS - Embedded UML Target Debugger v9.0 EN