Is there a register in the RH850 U2A chip that can indicate whether it is currently in Debug Mode (connected to a debugger)?

Hello, expert:

Is there a register in the RH850 U2A chip that can indicate whether it is currently in Debug Mode (connected to a debugger)?

  • Unfortunately there is no way to know if a debugger is attached, the CPU does not have access to the debug control unit.

    How I have dealt with this is to reserve a RAM location that is initialized to 0 via the C-startup, and use the debugger to write a known value that could be checked by the running program.

  • Thank a lot for the reply  : ) 

    The reason why I've asked this is that we are encountering an issue related to the debugger. Specifically, when using a Lauterbach debugger to perform a soft reset (RH850 U2A16 4 cores attached), execute code from the start address, the ECM continuously raises DCLS interrupts (ECM 256 288 320).

    This results in a high CPU load.

    However, this issue does not occur when using the E2 debugger.

    Do you have any suggestions regarding this issue?

  • Hello,

    The DCLS error is caused by a lockstep verification failure. At first, lockstep can be disabled by setting bits 19 to 17 in Option Byte 9.

    To avoid any lockstep problems, RAM and register initialization has to take place.

  • Make sure that one of the first things done in the startup code is to initialize all registers to zero (e.g. mov rN,r0) to prevent lock-step errors.

  • Hi, all experts: 

    Thank you for your reply

    I don’t believe the issue lies with RAM/Register initialization. Allow me to provide more details:
    We are using AutosarOS, and the Autosar startup code initializes the chip registers/RAM. **When no debugger is connected, the program runs normally.** And also This issue occurs exclusively on the RH850 U2A16 chip with Lauterbach. On the RH850 U2A8 chip, even with ECM enabled, the DCLS error does not appear.

    I conducted further testing on the RH850 U2A16 chip as follows:

    1. The program runs normally when using the E2 debugger.
    2. When using the Lauterbach debugger and starting the debug session from the start address with only two cores attached, the program runs normally.
    3. However, when using the Lauterbach debugger and starting the debug session from the start address with all four cores attached, the issue occurs, and ECM continuously reports the DCLS fault.
    4. But when using the Lauterbach debugger with the hot-plug feature, the program runs normally, regardless of whether two or four cores are attached.

  • That is very odd that the problem only occurs when using the Lauterbach debugging from reset.  I believe that the cores are started differently when debugging is active, this leads me to believe the problem may be in your Lauterbach init script.  Can you share this, or is it the standard startup script for the U2A8 device?

  • Hi:

    I can provide both U2A16 & U2A8 cpu setup:

    Lauterbach.zip

  • The LB scripts and commands have evolved a bit since I last used it.  As I have neither a LB for RH850 nor the U2A hardware to test, it is quite difficult to interpret the script commands related to handling multicore control.  But I am wondering about the three lines in the script:

    SYStem.CONFIG CoreNumber 10.   <- setup 10 hardware threads?
    SYStem.CONFIG CORE 2. 1.
    CORE.ASSIGN 1. 2.

    The PDF for RH850 (debugger_rh850.pdf) has this statment:

    Assign target cores to the individual instances. Use either “SYStem.CONFIG.CORE
    <core_index> <chip_index>” or “CORE.ASSIGN <core_index>”. The parameter <chip_index>
    must be the same for all cores on the same chip.

    Your script uses both commands which may be problematic, I'm not sure.  I don't understand why 10 hardware threads are being configured.  You might want to review the commands in this script, and possibly involve Lauterbach tech support.

    Looking at the provided demo scripts from the LB web site, I see that the debugger is explicitly setting the start address of the PC for logical core1.  This may be used if the reset vector is not properly set, but I am wondering if your core that is triggering the lock-step fault is starting from the wrong place which could easily trigger that fault.  If you single-step with this core can you verify that the correct startup sequence is being executed?

  • Hello wtx,

    please contact the Lauterbach Support regarding the issue.

    Best regards,

    Erik

  • Sorry for the late reply. We contacted Lauterbach's official support, and they suggested that we use the hotplug-in feature as a temporary workaround for the issue.