BREAKPOINTS

What is a Breakpoint.?

          A breakpoint makes your program stop whenever a certain point in the program is reached. For each breakpoint, you can add conditions to control in finer detail whether your program stops.

          A breakpoint is a means of acquiring knowledge about a program during its execution. During the interruption, the programmer inspects the test environment (general purpose registers, memory, logs, files, etc.) to find out whether the program is functioning as expected.

1. Classification

Classification can be done based on the either the condition or the implementation of the breakpoints.

1.1 Condition Based Breakpoints 

Instruction Breakpoint: 

          Instruction Breakpoints are used to interrupt a running program immediately before the execution of a programmer-specified instruction.

Data breakpoint: 

          Data Breakpoints can also be placed based on other conditions such as reading, writing, or modification of a specific location in an area of memory.

1.2 Implementation based Breakpoints

          The Instruction breakpoint implementation is the most commonly used breakpoint and is discussed below.

Hardware Breakpoint:

          A Hardware Breakpoint is implemented by special logic that is integrated into the device.

To support the hardware breaking, the hardware usually contains programmable comparators (comparator – Register + compare logic). The comparators shall be programmed to hold specific addresses in the program where breaking is required.

          When the code is being executed, and the address on the program address bus match the address value written into any of the comparators, the Hardware breakpoint logic generates a signal to the CPU to Halt.

          The availability and implementation of the hardware breakpoint are architecture dependent. The number of hardware breakpoints are usually limited (3 typically) as it requires dedicated hardware.

Software Breakpoint:

          As the name states, this type of breakpoint is implemented in Software. There is no dedicated hardware involvement as in the former case. The logic used for the breakpoint is purely handled in software.

          The hardware architecture usually contains a breakpoint instruction or opcode (typically 1 byte). Whenever a breakpoint is set at a particular instruction, the leading 1 byte of this instruction is replaced with the opcode corresponding to breakpoint instruction. In certain cases a normal HALT instruction may be used instead of a specific breakpoint instruction.  

          The original 1 byte of the modified instruction is placed in the breakpoint table (similar to interrupt vector table). During execution whenever a breakpoint is encountered, the CPU halts and debugger replaces the breakpoint opcode with the original 8-bits of the instruction.

          When the execution is resumed on user input, the debugger flushes the instruction pipeline and re-fetches the next set of instructions, this time with the original opcode instead of the breakpoint opcode. The execution then continues normally as if the instructions were not modified.

Hardware Breakpoint vs Software Breakpoint

        The hardware breakpoints have less overload due to the dedicated hardware. In case of software breakpoints the overload is high due to the flushing of instruction pipeline and re-fetching of instructions.

          The Software breakpoints require modification of the executable binary and hence it shall not be possible in few cases where the binary is loaded into ROM/Flash. Adding SW breakpoints in the binary loaded in RAM is possible. No such memory specific limitation with Hardware breakpoints as the binary is not modified for adding breakpoints.

          The advantage with SW breakpoints are that they can be unlimited unlike a very small number of HW breakpoints.

2. Breakpoint Facts

• When the user tries to check the disassembly of the code where a software breakpoint is places, it shall be surprising to see that the breakpoint instruction opcode is not visible. Rather the original instruction opcode is shown. This is because the IDE usually checks the breakpoint table for any content before it displays the contents. If there is a breakpoint, the IDE always displays the original instruction opcode.

• Some IDEs are able to detect the memory map and places Hardware and Software breakpoints accordingly. 

• There are 2 types of Data breakpoint and are usually termed as – Catchpoint and Watchpoint and not as breakpoints. They are usually available only in high end modern IDEs.

                  Catchpoint - Stops your program when a certain kind of event occurs.
                  Watchpoint - Stops your program when the value of an expression/variable changes.

------------------------------------------------------------------------------------------------------

Alternate Coding for Nested Switches

            C Programming allows a great degree of freedom when a software is designed using it. It allows nesting of simple constructs to form a complex constructs to establish desired functionality.

These designs usually work fine. They shall be logically correct. But when building a large piece of software which will be maintained across time and space, some of these practices are more prone to error. When building Safety critical applications it is essential to avoid such complex constructs to keep the software less error prone and more safe.

One such complex construct is Nested-switch blocks (Switch within a Switch or If-Else within a Switch). C programming allows Nested-switch programming and the compiler works just fine. However the Nested-switch blocks are not recommended according to safe-programming guideliness. MISRA-C, the automotive safe programming guideline does not allow Nested-swtich blocks.

When faced with such scenario, it is necessary to mitigate the complex construct with some simple design or re-structure the code to eliminate the scenario. Often, along with safety, these approaches reduce the code size and increase the speed too.

In this article, lets see a pseudo-code on how to eliminate the Nested-switch blocks with a simpler code.

Consider a user menu based application, where it is required to perform a function based on the user selected menu options. The application shall present the user with a set of main-menu options and for each main-menu option a set of sub-menu options are also presented.

The user shall select a menu option and then a sub-menu option. The selected options are stored under enum variables,

mState & smState

---

typedef enum { 
MenuState1 = 0,
MenuState2,
MenuState3,
} MenuStates;

typedef enum {
MenuSubState1 = 0,
MenuSubState2,
MenuSubState3,
MenuSubState4,
} MenuSubStates;

MenuStates mState;
MenuSubStates smState;

---

Now let us assume that the following functions shall be executed based on the selected main-menu and sub-menu states.

MenuState1 -> MenuSubState1 -> Task11()
MenuState1 -> MenuSubState2 -> Task12()
MenuState1 -> MenuSubState3 -> Task13()
MenuState1 -> MenuSubState4 -> Task14()

MenuState2 -> MenuSubState1 -> Task21()
MenuState2 -> MenuSubState2 -> No Action
MenuState2 -> MenuSubState3 -> Task23()
MenuState2 -> MenuSubState4 -> Task24()

MenuState3 -> MenuSubState1 -> Task31()
MenuState3 -> MenuSubState2 -> Task32()
MenuState3 -> MenuSubState3 -> Task33()
MenuState3 -> MenuSubState4 -> No Action

The above scenario shall be designed using Nested-Switch blocks as below,

---

switch (mState)

{
case MenuState1 :
   switch (smState)
   {
        case MenuSubState1:
                Task11();

                break;

        case MenuSubState2:
                Task12();

                break;

        case MenuSubState3:
                Task13();

                break;

        case MenuSubState4:
                Task14();

                break;

        default :
                break;

   }
break;

case MenuState2 :
   switch (smState)
   {
        case MenuSubState1:
                Task21();

                break;

        case MenuSubState3:
                Task23();

                break;

        case MenuSubState4:
                Task24();

                break;

         default :

                break;

   }
break;

case MenuState3 :
   switch (smState)
   {
        case MenuSubState1:
                Task31();

                break;

        case MenuSubState2:
                Task32();

                break;

        case MenuSubState3:
                Task33();

                break;

        default :
                break;

   }
break;

default :
break;
}

---

In the above code, the respective task is performed based on the values of mState (Main-menu option) and smState (sub-menu option).

It is evident from the above code that a nested-switch implementation is complex. And the code size only increases with more states. Maintaining such a code is tedious and would require complete re-implementation at times.

Therefore the above code should be replaced with an alternative implementation for simplicity and scaling. A better and safer approach for the above scenario is to use a Multi-dimension Array based implementation.

The Nested switch implementation shall be replaced with a multi-dimension array implementation with following considerations,

• Create a multi-dimension array (dimension = Nesting level + 1). In this case the nesting level is 1. Hence a 2D array.
• Considering the 2 state variables (mState and smState) as indexes, fill the Function pointers as array values.
• Modify the enum declarations to add an additional value to indicate the size.
• For cases where no action is to be done, fill with NULL.

The enum declarations and the code will look like below,

---

typedef enum {
MenuState1 = 0, 
MenuState2, 
MenuState3,

MenuStateSize
} MenuStates;

typedef enum {
MenuSubState1 = 0,
MenuSubState2,
MenuSubState3,
MenuSubState4,

MenuSubStateSize
} MenuSubStates;

MenuStates mState;

MenuSubStates smState;

void (* const TaskTable[MenuStateSize][MenuSubStateSize])(void) = {

       {TASK11, TASK12, TASK13, TASK14},

       {TASK21, NULL, TASK23, TASK24},

       {TASK31, TASK32, TASK33, NULL }

};

if(TaskTable[mState][smState] != NULL) //Check for NULL

{

           (*TaskTable[mState][smState])(); /* Calls the appropriate Task function based on the main-menu and sub-menu states. */

}

---

In above code, nested switch case is replaced by an array of function-pointers.

Note : It is essential to check for NULL and also the array indexes are within range to avoid issues.

Though the code reduces complexity, the usage of pointers shall sometimes be not liked.

So the developer shall decide the method desired based on his/her own requirements.

---

Thank you !

Linker Directives Basics - Based on the GHS/RH850 Toolchain

What goes into the Target?

When we compile an Embedded program, the code is transformed into a binary file, a format that can be downloaded into the target hardware for execution. 

The transformed binary code usually contains 4 types of code items in it arranged together as specified by the developer.

The 4 different program sections in a binary file (or a program) are, 

• .text - segment for executable instructions. Also known as Code segment.
• .bss - segment for uninitialized data . The stationery init code zeroes this area at startup.
• .data - segment for initialized data.
• .rodata - segment for constant data.

Note : The data referred in the .bss/.data/.rodata are the global variables. The local variables are "executable instructions" and they are part of .text section.

---------------------------------------------------------------------------------------------------------------

Where it goes in Target?

After the compilation is successfully completed, different code sections are still available as fragments.

The Linker binds these compiled fragments together and assigns them with the target hardware's address. This operation is called Linking. This is established with the help of the Linker Directives(.ld) file which instructs the linker on how to perform the linking operation.

Therefore the linker directives usually contain the different code segments and their respective memory addresses. The linker directives shall also include other information that is specific to the compiler or hardware architecture or the application.

In this blog, we will cover what is a linker directive file, its contents, and details about each directive based on the Green hills (GHS) toolchain and the memory models based on Renesas RH850. 

--------------------------------------------------------------------------------------------------------------

Linker Directives - GHS

Linker directives files (.ld) are used to define program sections, and to assign them to specific addresses in memory.  In this section, the structure and the contents of the GHS linker directive are explained. 

These files may contain the following directives (sections):

• OPTION - Specifies Linker options
• CONSTANTS - Sets constant values for use in memory and section maps.
• MEMORY - Defines a memory map by specifying the name, starting address, and size of memory regions.
• SECTIONS - Defines a section map by specifying the name, attributes, and address (memory locations) of program sections.

Below is an example of how the different sections in a linker directives file look. It also shows the default program sections that shall be present in a program. Custom linker directives shall be created based on the default linker directive file provided by the IDE.

Note: Comment lines are prefixed by a hash symbol (#).

# ==============================================================

OPTION ("-checksum -map")

CONSTANTS {

heap_reserve = 1M

stack_reserve = 512K

}

MEMORY {

dram_rsvd1 : ORIGIN = 0x80000000, LENGTH = 32K

dram_memory : ORIGIN = ., LENGTH = 10M-32K

dram_rsvd2 : ORIGIN = ., LENGTH = 0

flash_rsvd1 : ORIGIN = 0xbfc00000, LENGTH = 32K

flash_memory : ORIGIN = ., LENGTH = 10M - 32K

flash_rsvd2 : ORIGIN = ., LENGTH = 0

}

SECTIONS {

# Section for executable instructions from user code.

.text : > dram_memory

# These 5 symbols are necessary for internal GHS operation.

.syscall : > .

.secinfo : > .

.fixaddr : > .

.fixtype : > .

.profile : > .

# Sections for various data from user code.

.robase ALIGN(8) : > .

.rodata : > .

.data : > .

.bss : > .

.heap ALIGN(8) PAD(heap_reserve) : > .

.stack ALIGN(8) PAD(stack_reserve) : > .

# These special symbols mark the bounds of RAM and ROM memory.

# They are used by the MULTI debugger.

__ghs_ramstart = MEMADDR(dram_rsvd1);

__ghs_ramend = MEMENDADDR(dram_rsvd2);

__ghs_romstart = MEMADDR(flash_rsvd1);

__ghs_romend = MEMENDADDR(flash_rsvd2);

}

# ==============================================================

--------------------------------------------------------------------------------------------------------------

Now the Linker Directives in detail.

The OPTION Directive

To include command-line options in a linker directives file. The syntax is,

OPTION ("option")

Example 1. Using the OPTION Directive

To specify the -checksum and -map options in a linker directives file, add the following line:

OPTION ("-checksum -map")

To use the OPTION directive to specify files to be linked, using the following syntax:

OPTION ("file_name")

--------------------------------------------------------------------------------------------------------------

The CONSTANTS Directive

To specify the constants for use in a linker directives file. The syntax is,

CONSTANTS {name=value}

Example 2. Using the CONSTANTS Directive

To set the constant foo to the value 0x2000 in a .ld file, add the following line:

CONSTANTS {foo=0x2000}

Multiple constants can be specified, separated by a semicolon,

CONSTANTS {foo=0x2000; bar=0x4000}

Constants specified in this manner can be used in place of absolute values in section and memory maps.

--------------------------------------------------------------------------------------------------------------

The MEMORY Directive (Memory Maps)

The linker uses a memory map to define regions of memory, to which the sections of the executable can be assigned. A memory map is formatted as follows:

MEMORY

{

...

memname: ORIGIN=origin_expression, LENGTH=length_expression

...

}

where:

memname - Specifies the name of a memory region.

origin_expression - Specifies the starting address of the memory region.

length_expression - Specifies the length of the memory region.

All three of these elements must be specified for each region to produce a valid memory map. If a memory map is passed to the linker, only the memory regions named and defined in it can be referenced in an associated section map.

Example 3. Format of a Memory Map

The linker directives file, memory.ld contains the following memory map:

MEMORY

{

dram_memory : ORIGIN = 0, LENGTH = 4M

flash_memory : ORIGIN = 0x40000000, LENGTH = 1024K

internal_memory : ORIGIN = 0xffff8000, LENGTH = 0x2000

alt_reset : ORIGIN = 0xfff00100, LENGTH = 256

}

Note: Use “M” (meaning megabyte) and “K” (meaning kilobyte ) in memory maps, as shown in the first two lines of the example above.

--------------------------------------------------------------------------------------------------------------

The SECTIONS Directive (Section Maps)

The linker uses a section map to write program sections in the executable to particular memory regions. A section map is formatted as follows:

SECTIONS

{

...

secname [start_expression] [attributes] : [{ contents }] [> memname]

...

}

where,

secname - 

Specifies the name of a section

start_expression - 

Specifies the starting address of the section. 

If omitted, the section starts at the next available address. Usually, this is the address immediately after the previous section. However, if a memory map has been specified and there is not enough space to hold the section in the current memory region, the linker will search for the next valid area of memory (specified in the memory map) into which the section will fit. 

The starting address may be further modified to fit the alignment constraints of the subsections included by contents.

attributes -

Specifies the attributes of the section. Any number of attributes shall be included. The list of attributes is detailed separately on this page.

contents - 

Specifies section inclusion commands and assignments. There is no limit to the number of commands and assignments.

Section inclusion commands are of the form filename(secname), which directs that the section secname from filename should be included. To include the section secname from all files, use 

{*(secname)}.  Leaving the {contents} section empty is also equivalent to adding {*(secname)}.

The special variable dot (“.”), represents the current offset within the section. You can assign symbols to dot using the syntax “symbol=.;”. You can create holes in the section using the dot. For example, “.+=0x100;” would create a 0x100 byte hole or a gap inside a section.

memname

Allocates the section to memory region memname, which is pre-defined in the memory map.

If both a start_expression and a memname memory region are specified in a line in the section map, then the start_expression takes precedence.  If more than one section is assigned to a memname memory region, the section that appears first in the section map will be written to that region first.

All sections in input files that participate in memory the layout must be referenced in the section map.

Example 4. Format of a Section Map

The linker directives file, sections.ld contains the following section map, which references certain of the named memory regions.

SECTIONS

{

# RAM SECTIONS

.data : > dram_memory

.bss : >.

.heap ALIGN(16) MIN_SIZE(stack_reserve) : >.

.stack ALIGN(16) MIN_SIZE(heap_reserve) : >.

# ROM SECTIONS

.ROM.data ROM(.data) : > flash_memory

.text : >.

.syscall : >.

.rodata : >.

}

In this example, .data is written to the memory region dram_memory. Since no memory region is specified for .bss, this section will be written to dram_memory, directly after .data.

Example 5. Including and Renaming Sections

The section map lines given in this example demonstrate the syntax of the most commonly used forms of section inclusion. For the sake of clarity, only the executable section name and the { contents } argument are given.

.data :{*(.data)}

.data :

The first line above includes the .data sections from all object files in the .data section of the executable. Since the executable section and the object file sections have the same name, it is not necessary to specify a { contents } argument in this case, and the syntax given in the second line is sufficient.

.newdata :{*(.data)}

The line above includes the .data sections from all object files in the .newdata section of the executable.

.newdata :{foo.o(.data) bar.o(.data)}

The line above includes the .data sections from foo.o and then bar.o in the .newdata section of the executable. The .data sections from all other object files are included, by default, in the .data section of the executable.

.newtext :{lib.a(foo.o(.text))}

The line above includes the .text section from the object file foo.o contained within lib.a in the .newtext section of the executable. The .text sections from all other object files are included, by default, in the .text section of the executable.

.newbss :{lib.a(*(.bss))}

The line above includes the .bss section from all object files contained within lib.a in the .newbss section of the executable. The .bss sections from all other object files are included, by default, in the .bss section of the executable.

Note: Library filenames are case-sensitive. You may give just the library name, rather than a full path.

--------------------------------------------------------------------------------------------------------------

SECTION ATTRIBUTES

The following section attributes can be used to configure the section behavior:

ABS

Sets a flag in the output file that indicates that this section has an absolute address and should not be moved. Program loaders and other utilities, that manipulate the output-image should not include this section in any movement related to position independent code or position independent data.

CLEAR / NOCLEAR

Sets or removes the CLEAR attribute of the section. If CLEAR is present, an entry is made in the run-time clear table, which is often used by startup code to initialize memory regions to a particular value.

The CLEAR attribute is set by default for.bss section or other such data sections (we will see other sections similar to .bss  later).

PAD (value)

Places value bytes of padding at the beginning of the section. This is equivalent to specifying padding at the beginning of the section contents.

Example: The following two definitions are equivalent:

.stack pad(0x10000) : {}

.stack : { . += 0x10000; }

ROM (sect_name)

CROM (sect_name)

These attributes allocate the contents of a section, sect_name, to ROM at link time, while reserving space for the data to be copied to RAM at startup.

MIN_SIZE (size)

Instructs the linker to pad, if necessary, to ensure that the section is at least size bytes in length.

MIN_ENDADDRESS(address)

Instructs the linker to pad, if necessary, to ensure that the section extends to at least address.

MAX_SIZE(size)

Indicates that an error should be generated if the section exceeds size bytes in length.

MAX_ENDADDRESS(address)

Indicates that an error should be generated if the section extends beyond address during final layout.

Example 6. Using CLEAR and NOCLEAR

The section map is by default set to CLEAR:

.sbss NOCLEAR :

The line above overrides the default CLEAR attribute of .sbss.

.mysbss NOCLEAR :{*(SMALLCOMMONS)}

The line above disables the default clearing that results for SMALLCOMMONS:

.heap CLEAR PAD(0x10000):

The line above causes the heap, which is normally uninitialized, to be cleared at startup.

Example 7. Using ROM

A section created with this attribute will inherit the attributes and contents of the original section. The original section is marked uninitialized; that is, it is modified to reserve address space only, as if it were all padding with no contents.

To place the .data section in ROM with instructions to have it copied to RAM at startup, you would include, as a minimum, the following lines in your section map:

.data :

...

.ROM.data ROM(.data) :

An entry is automatically made in the ROM copy table to ensure that during program startup the ROM image of .ROM.data is copied into the space reserved for .data. 
--------------------------------------------------------------------------------------------------------------

Memory Model - Renesas/RH850

The Renesas RH850 and the V850 architectures, support the following memory models,

• Normal data: The default memory model, where all data is placed within the data area and is accessed using normal load and store operations.

• Small data: Data is assigned either automatically by the compiler or manually by the user (or both) into a small data area and is referenced using a reserved register (r4) as a base pointer, allowing for smaller code for data accesses. The total size of the Small is limited to 64 Kbytes.

• Zero data: Similar to Small data, although the zero-register (r0) is used as the base register to access data within 16 bits of address 0. The total size of the Tiny Data Area is limited to 4 Kbytes.

• Tiny data: Data is assigned by the user into small sections accessed using the Tiny Data Area (TDA) base register (ep) and the V850 short load/store operations providing for the smallest possible code for data accesses. The total size of the Tiny Data Area is limited to 4 Kbytes.

The usage of Small Data Area (SDA), Zero Data Area (ZDA), and Tiny Data Area (TDA) improve the program size and speed because addressing objects in this area requires fewer instructions. The developer can assign different initialized, non-initialized, and constant data to each of these small/zero/tiny data areas. 

To accommodate these memory models and assigning different data into these Data areas, the linker directive file is prepared with specific information for each data area.
--------------------------------------------------------------------------------------------------------------

GHS program sections for RH850 memory models

Based on the RH850 memory model, the various program sections for the data are given below,

Memory Allocation for Initialized Variables - data, sdata, tdata, zdata.

Memory Allocation for Un-initialized Variables - bss, sbss, zbss.

Memory Allocation for Constant Variables - rodata, rosdata, rozdata.

Only initialized data are placed in the TDA. Therefore only tdata section can be added in the linker directives file.

The developer shall include any or all these program sections in their linker directives file and assign them memory locations. 

--------------------------------------------------------------------------------------------------------------
uk0pr-46
EXAMPLE TO BE ADDED.

ADVANCED LD FEATURES TO BE ADDED.