Please enable JavaScript to view this site.

winIDEA Help

Version: 9.21.296

Debug

In this topic:

Debug Interface

Real-Time Memory Access

Access Breakpoints

Software Breakpoints

Code Execution on Session Startup

Interrupts

Multi-Core Debugging

Multi-Core Synchronization

 

 

Debug Interface

The Debug Interface uses a four-wire LPD, which is a proprietary debug interface developed by Renesas. While it may seem similar to a UART-based interface at the physical level, it is entirely different in terms of connection and functionality. The LPD interface also has its own specific Debug Adapter.

 

The RH850 G3 devices originally supported JTAG. winIDEA does not support JTAG because the LPD interface has proven to be faster and more reliable.

A challenge with factory-new chips is that they come with the JTAG debug connection enabled by default. Therefore, winIDEA offers a Force FP5 Query before debug in Hardware | CPU Options | SoC Advanced which sets the device to LPD4 debug port.

 

 

Real-Time Memory Access

RH850 Debug Interface features a real-time memory access into the internal RAM that does not require user program to be stopped and allows reading the memory while the application is running.

 

Warning_orange

Large amounts of memory read affect the application performance.

 

Watches Window can be configured to inspect memory in run-time. Run-time access is enabled in:

Debug | Debug Options | Memory Access

Debug | Debug Options | Update

 

Memory Window and Special Function Registers can be configured to be updated in run-time too.

 

 

Access Breakpoints

Two break events can be configured to stop the CPU on data access. Open Debug | Hardware Breakpoints.

 

OCDRH850-accessBPs

 

Depending on a RH850 core implementation, a break event can be restricted to a specific ASID value when MMU is used. The CPU can break on address match or mismatch. Access type can be read, write or read/write and access size can be 8-bit, 16-bit, 32-bit or any. Additionally, a break event can be conditional with the data value match or mismatch. Set mask bits to FFs to ignore the compare address or data values. Note that CPU core resources are used for the breakpoints, hence the CPU has to be stopped when setting the breakpoints.

 

Warning_orange

The same on-chip debug resources are shared among two hardware execution breakpoints and access breakpoints. Consequentially, debug resources used by one debug functionality are not available for the other. In practice this would mean that no access breakpoint can be set for instance on instruction address, when all available execution breakpoints are set already.

 

Real-time access must be disabled when access breakpoints are used. Otherwise, access breakpoints may exhibit unpredictable behavior.

 

Write-access breakpoints are pre-execution breakpoints. This means the CPU will stop before retiring the instruction with the actual write operation on the bus. This behavior is different to all other CPU families. In order to resume execution, a single-step needs to be performed first to get over the write instruction. After this, a normal program execution is possible by issuing RUN command, for example.

 

 

Software Breakpoints

Warning_orange

Software breakpoints are not supported on RH850.

 

winIDEA does not support Software Breakpoints Renesas RH850. There are several reasons for this decision:

Code Flash Stress - Implementing software breakpoint involves patching the flash memory sector with a dbtrap instruction. This process includes reading the matching flash sector into a buffer, patching the breakpoint location, erasing the sector, and writing the modified buffer back. This activity can place undue stress on the code flash, affecting its longevity.

Debugging efficiency - The process of implementing software breakpoints considerably slows down the debugging experience.

Flash memory life cycle - Flash memory has a limited number of program/erase cycles it can endure.  The frequent use of software breakpoints in a development context can quickly exceed these limits.

Alignment with user needs - In practice, the availability of 12 hardware breakpoints is sufficient for the average user's debugging needs, minimizing the reliance on software breakpoints.

 

 

Code Execution on Session Startup

RH850 G3 Debug interface is inaccessible after power-up or hardware reset. In the reset-debug mode entry sequence the RESET pin needs to be released and debug interface unlocked before a core reset can be asserted via debug control register. During the unlock procedure an application stored in flash inadvertently starts and runs for about 20-25ms.

This can be a serious problem, for example, when writing initialization code for a safety CPU like the P1x family. A bug in the code can cause a safety exception and lock up the debug interface. A development workaround is to insert a dbtrap opcode before critical sections. See example below. Remember to remove it when proper initialization is done!

 

OCDRH850-emulationNotes

 

During an active session the CPU is not reset with the RESET pin. Instead, reset is applied internally using the Debug control register thus preventing application run-off. This means, after the initial RESET at starting a debug session, resets are not visible at the RESET pin.

 

 

Interrupts

For more predictable debugging, maskable interrupt requests are disabled during source step debug command. For instance, if there would be a periodical interrupt (e.g. timer), the program would keep entering in the interrupt routine with every source step, if interrupts would not be disabled. Consequentially, it is not allowed to step over the source line or function, which changes the interrupt flag in the Program Status Word (PSW) register, otherwise the PSW register could have a wrong value after the source step. The program must be run over such parts of code.

It is also recommended to check the Suspend peripherals while stopped option in the CPU Options | Reset for more predictable interrupt behavior during the debug session.

 

 

Multi-Core Debugging

When a microcontroller or SoC features two or more cores, each core is debugged in an individual winIDEA instance. In Renesas parlance core is named Processing Element, or PE. In order to debug a second (non-primary) core (PE2 on RH850/F1H), first primary winIDEA instance and workspace is opened, which allows compiling the complete (SoC) project, downloading the code in the MCU program flash and debugging the primary (main or PE1) core.

 

 

Multi-Core Synchronization

The operation of the all cores is inherently synchronized (so all cores start and stop at the same time). This behavior can not be changed by the user. Though, a single-step is performed on one core, while the others are stopped.

 

 

More resources

Breakpoints - Overview

Multi-Core Debugging - Overview

 

 

Copyright © 2024 TASKING