Advanced Debugging on the RX600_LabProcedure (1)

Being able to view the preprocessed source files can help solve some troubleshooting issues when the error message from the compiler does not seem to make sense.. Then double click on th

ID 3L05I: Advanced Debugging with RX600

RX600 Series

Description: The purpose of this lab is to get the user accustomed to using some of the advanced

debugging features available on RX600 Series devices The features covered are the expression view, complex breakpoints, and branch trace

1 Demo Application Overview 2

Lab Sections 2 Viewing Preprocessed Files 3

3 Using the Expressions View 8

4 Complex Eventpoints 13

5 Branch Trace 19

6 Using Multiple Eventpoints Together 22

Lab Objectives

1 Learn to generate and view preprocessed

source files

2 Understand and use complex breakpoints

3 Demonstrate trace functionality

4 Setup and use multiple eventpoints

Skill Level:

1 Programming in C

2 Basic operations in e2Studio

3 Basic debugging techniques

Time to Complete Lab

90 Minutes

Lab Materials

Please verify you have the following materials at your lab station

• RDKRX63N

• USB debugger cable

• e2Studio Version 1.1.0.25

• RX Toolchain Version 1.02.00

• RX_Advanced_Debug lab workspace

1 Demo Application Overview

Before getting into the lab we will cover what the demo is actually doing The code is executing a state machine to handle a very simple communications protocol The MCU is acting as a receiver with a host sending it a series of data blocks An outline of how the protocol works is below

Some more information in regards to the protocol:

• The Device is in a waiting state when not receiving data from the Host

• All data transmitted are unsigned integers

• The ‘# of Data Blocks’ field tells the Device how many data blocks to expect and is 1 Byte

• The Sequence ID (1 Byte) of a block identifies the block The first block with have a Sequence ID

of 0, the 2nd block will have a Sequence ID of 1, and so on

• The ‘# of Bytes of Data’ (1 Byte) tells the Device how many bytes to expect in this block, not

including the CRC

• The CRC is a CRC-16 CCITT with an initial seed of 0x1D0F

The Host in this lab is simulated by the Demo_Communications.c source file It feeds data to the receive buffer of the state machine so that it can process it The actual data is stored in the file ComData.h

Since we are simulating the actual communications, we can assume that any problems in the code

are NOT due to transmission errors

2 Viewing Preprocessed Files

Overview:

This section will cover generating and viewing preprocessed C source files Being able to view the

preprocessed source files can help solve some troubleshooting issues when the error message from the compiler does not seem to make sense

Step 2.1 Run e2Studio There should be a shortcut on the Desktop If not, go to All

Programs>>Renesas Electronics e2Studio>>Renesas e2Studio

Step 2.2 Click on Browse and go to C:\Workspace\RX_Advanced_Debug Click OK to open the

workspace

Step 2.3 Go to Project>>Build All During the build you will see an error in the file

Demo_StateMachine.c The error that is thrown will look similar to:

\src\Demo_StateMachine.c(169) : C6578 (E) Case label value has already appeared in this switch at line 103

make: *** [src/Demo_StateMachine.obj] Error 1

Step 2.4 Verify that there is not another case block with the same name SM_ERROR You can also look

in the header file Demo_StateMachine.h to see the SM_States enumerator declaration for

the available state machine states

Step 2.5 To help troubleshoot this issue we are now going to look at the preprocessed source files Go

to Project >> Properties In the window that pops up expand C/C++ Build and select Settings Tool Settings tab should be displayed

To quickly locate an error you can go to Problems view and expand the Errors Then double click on the error to find the location in source code This

is shown in below

Also, the file with an error will be marked with a red box in Project Explorer view

(far left)

Step 2.6 On Tool Settings tab, choose Object under Compiler and change the Output file type to

Preprocessed source file (*.p/*.pp) Your window should look like below

Step 2.7 Click OK to go back to the e2Studio project

Step 2.8 Go to Project>>Build All

Step 2.9 To view the preprocessed output go to File >> Open File Navigate to the HardwareDebug\src

folder and open the file Demo_StateMachine.p This file should be in the following folder

C:\WorkSpace\RX_Advanced_Debug\RX_Advanced_Debug\HardwareDebug\src

Step 2.10 Scroll down in the file until you find the location where the error occurred Notice that while

the other cases still show their enumerator names, the case that was throwing the error

SM_ERROR now shows up as case (1) This means that somewhere in the code there is a

#define that is substituting (1) for SM_ERROR

Step 2.11 To find this #define we will use the Search feature in e2Studio Go to Search>>Search A

search window shows up

When outputting preprocessed source files the project build stops at the linker stage

The reason for this is that the object files are not generated and therefore the linker cannot run

You will likely get an error in the Console view For example the RX toolchain generates the

following error: ** L3300 (F) Cannot open file

Step 2.12 Make your Search window match the window below and click Search

Step 2.13 The search results will show up in the Search view Look in the results for an occurrence

where SM_ERROR was used with a #define

Step 2.14 Double click on the occurrence of SM_ERROR with #define to be taken to the line of code in

the source file

For an improved source code search options, you can use C/C++ Search tab For

example, you can select Macro from the Search For boxes to fine tune your search The results

will show only where SM_ERROR is used with a #define This is shown below

Step 2.15 Since this #define is not being used in the project it can be safely commented out

Comment out this line of code

//#define SM_ERROR (1)

Step 2.16 Go back to Project >> Properties as was done in Step 2.5 and reset the Output file type to

Machine code (*.obj) Click OK

Step 2.17 Go to Project>>Build All The project should build with no errors

This example is designed to demonstrate where a coder accidently named a state

machine state and an error flag with the same thing Other similar types of hard-to-see errors

can occur when you don’t keep track of #define statements between files One easy way to

prevent these types of problems is to follow a set of rules Rules like “all #define names will be

in all capitals” and “all states will have STATE_ at the beginning of the name” are examples

that are easy to follow and will prevent most types of these problems

Question

1 Why does the linker give an error while building the project when the compiler is configured to output preprocessed source files (*.p files)?

3 Using the Expressions View

Overview:

This section will explain how to watch variables using the Expressions window in e2Studio We will

connect to the hardware and run the debugger

Step 3.1 Connect the RDKRX63N to the laptop using the supplied USB cable Make sure to use the

USB port labeled J-Link

Step 3.2 On the Project Explorer view (far left), right click on the RX_Advanced_Debug project and

select Debug As>>Renesas GDB Hardware Launch

Step 3.3 If you see Renesas Hardware Debugging window, you need to setup the debug settings

Select Segger JLink from the list as shown below Click OK

Step 3.4 Now select R5F563NB from the MCU list as shown below Click OK

Step 3.5 If you see Confirm Perspective Switch window, click in Remember my decision box first and

then click Yes as shown below

Step 3.6 Click pull down arrow next to Debug icon to run debug configurations as shown below

Step 3.7 In Debug Configurations window, go to Startup tab and uncheck the Set breakpoint at box as

shown below Click Apply and Debug

Step 3.8 At this point, you should be connected to the debugger

Step 3.9 Click Restart icon to run the code

Step 3.10 Observe that the LCD display on RDKRX63N It should show a Renesas logo and display

RX Advanced Debug Lab

Step 3.11 Click Suspend icon to stop the code

Step 3.12 Go to Expression view This is shown below

Step 3.13 We are going to add a watch for a structure named DemoStruct Add this variable to the

Expressions view using your preferred method This variable should already be seen in the

Renesas Debug perspective in Demo_StateMachine.c file if you suspended in the code in

Step 3.11

Step 3.14 If the structure does not automatically expand, click the arrow sign next to the name Your

Expressions view should look similar to below

You can add variables to the Expressions view in a variety of ways

1 You can click on the Add new expression and type in the name of the variable

2 You can right click on Add new expressions and select Add Watch Expression In the

window opens up you can type the name of the variable This is the same as clicking

on the green plus sign (see in red circle above)

3 You can also highlight the variable in the editor window and then drag it into the

Expressions view

The Expressions view shows your data in several different formats: decimal, hex, binary,

and octal The Expressions view window also handles structures and pointers as shown

above You can expand structure and pointers to structures in the Expressions view as long

as the pointer is declared as a pointer of that particular structure type

Another feature of the Expressions view is that any valid C/C++ operations can be used with

variables and the evaluated result will be shown in the Expressions view For example the

address operator & can be used with a variable to find the address of it We will be using this

later in the lab

You can also edit the value of a variable straight from the Expressions view To do this click

on the value shown in the Value column and make the necessary change

4 Complex Eventpoints

Overview:

This section will explain how to setup and use data eventpoints Using masks will also be explained

Step 4.1 Open the Demo_StateMachine.c file and place a breakpoint where the state machine resets

itself after it has finished a reception This is the breakpoint we want to hit so that we know the state machine downloaded the data correctly See below for help in finding the location You can search for DemoStateMachineInit() if needed

Step 4.2 Click Restart icon to run the code If successful, the breakpoint set above should be hit in

less than a second

Step 4.3 Since breakpoint has NOT

Step 4.4 Verify that the project stopped at while(1) loop where an error has occurred But we do not

know why there is an error

been encountered click Suspend icon to stop the code

Step 4.5 The first thing we can check is to see how far the state machine got in processing the data

before it failed There is a global variable in the Demo_StateMachine.c file named

SequenceID that holds which data block is currently being processed Add SequenceID to the Expressions view as &SequenceID We will use the address of this variable later

Expand the name in Expression view and identify the block that caused the error

Step 4.6 Now that we know which data block caused the error we can further narrow down the problem

by seeing if there is a sequence ID mismatch or a CRC error We can figure this out by

looking for when the variable CurrentState is set to SM_ERROR Add CurrentState to the Expressions view as &CurrentState We will use the address of this variable later

Question

2 Which data block was being processed when the error occurred?

Step 4.7 Go to Eventpoints You should see a window similar to below

Step 4.8 Double click on Event Break You should see Edit Event Break widow as shown below

In Eventpoints view, you should see the following items

1 Trace Start – these are the conditions to start a trace

2 Trace Stop – these are the conditions to stop a trace

3 Trace Record – these specify which event to filter and record

4 Event Break – these are your complex breakpoints You can do

address break, data break, and use them together

5 Before PC – this is the same as hardware breakpoints

Step 4.9 Click Add button Add Eventpoint window shows up

Step 4.10 We want to stop when the variable CurrentState is written as SM_ERROR Change the

Eventpoint Type to Data Access On Address Settings tab, type in the address of

CurrentState in Address field from Step 4.6

The Add Eventpoint allows you to setup and control an event By default the Eventpoint Type will be Execution Address This allows you to put an

execution address in and the MCU will break at that address This is the same

as a hardware breakpoint What makes this different than putting an event in

the Before PC tab is that this event can be used along with other events such

as data breaks This will be demonstrated later in the lab

Notice that the Trigger is set to OR This means that any condition in the Event Break will stop the code From the pull down, you can select AND or

SEQUENCE AND requires all condition to be satisfied before stopping the

code SEQUENCE is used with events that occur one after the other

Step 4.11 Click on Data Access Settings tab Set Read/Write to Write Check the Compare Settings

box and enter 3 in the Compare field Your settings should be similar to below Note that the address of CurrentState may be different in your project Click OK

Step 4.12 Now click OK to close the Edit Event Break window

Step 4.13 Click on the arrow next to the Event Break to expend it You should see the new eventpoint

you just created under the Event Break But it is not yet sent to the debugger Click on Apply

to Target icon to send eventpoint settings to the debugger You should see that the

yellow warning sign next to the event disappear

The value of 3 is chosen for the Compare field because that is the number the SM_States enumerator will assign to SM_ERROR On the RX

toolchain the first enumerator option will get the value 0, the second option 1,

and so on Since the SM_ERROR option is the 4th in the list, it will get the value

of 3

Step 4.14 Click Restart icon to run the code and wait for the eventpoint to trigger

Step 4.15 Verify that the code stops but the current instruction shown is not one that writes the variable

CurrentState The reason for this is that the eventpoint will trigger only after the write has occurred and before the CPU was halted it had already executed the next instruction after the write What we need to know now is what was executed before the eventpoint was triggered

so that we can see which error occurred To do this we will use the trace feature in the next lab section

In most cases, the eventpoint we just set up will catch the condition we are looking for However, in this lab we intentionally made it more difficult to

find where SM_ERROR is written to CurrentState

You could also catch the error by setting breakpoints at every location where

the variable CurrentState is set to SM_ERROR This will work when there are

only few locations where this is done (like in this demo) but in a larger

application this would be hard to manage and you might run out of breakpoints

(especially hardware breakpoints) The ability to use a data breakpoint

resolves this issue

Masking is a powerful debugging tool By using the Mask Value field on the Data Access Settings tab, you can set a trigger to occur on a range of

values For instance, if you wanted to trigger on a value between 0x0010 and

0x001F then you would set the Compare field to 0x0010, the Mask Value field

to 0xFFF0, and set the Comparison drop down to Equals

The zeros in mask are don’t cares The ones in mask require the result

matches to the compare value Therefore Mask Value of 0xFFF0 will create a

trigger setting of 0x001X where X can be any value