winIDEA HelpDebug
In this topic:
•Code Execution on Session Startup
For general debug information refer to Debug chapter.
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.
|
Large amounts of memory read affect the application performance. |
Watches Window Rt.Watch pages can be configured to inspect memory in run-time. Run-time access is enabled in the Debug / Debug Options / Memory Access page and in the Debug / Debug Options / Update tab. Further, Memory Window and Special Function Registers Window (SFR) can be configured to be updated in run-time too.
 Debug / Debug Options / Memory Access. |
 Debug / Debug Options / Update. |
Access Breakpoints
Two break events can be configured to stop the CPU on data access. Open Debug / Hardware Breakpoints.
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.
|
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
|
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 lifecycle - 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
RH850G3 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!
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 PSW (Program Status Word) 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.
Refer to Multi-core Debugging for more information.
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.
