This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6412: AM64x Debug Infrastructure - Halt on Peripheral feature for Watchdog

Hello TI team,

thank you in advance for your help.

Related technical reference manual: spruim2h.pdf

Status:

We currently implementing a watchdog timer (main_rti0) to all components of the boot chain of the AM64 SoC. In detail:

  • R5 SBL
  • A53 SPL & u-boot
  • A53 Linux Kernel
  • A53 userspace

We completely rely on the TI u-boot (2023.01) and TI Linux kernel (5.10-rt) and following the release cycles of the processor SDK.

Issue:

During  development, we tend to use the Lauterbach Debugger and facing the challenge to make use of the

On-Chip-Debug "Halt on peripheral" feature for the main_rti0 alias watchdog for A53 core 0,

to prevent resets of the mentioned watchdog timer(s) during debug sessions.

This is related to missing guides and information about the "halt on peripheral" feature.

Target:

We are targeting to disable the watchdog timers during debug sessions with the Lauterbach debugger by

using the "halt on peripheral" feature.

Questions

1.) Can you provide further information/guides/examples about the On-Chip-Debug features for the AM64xx SoC and its registers?

2.) Can you provide information about the handling of enabled watchdog timers in general during usage of debuggers in general?

Note: https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/09_00_00_03/exports/docs/linux/Foundational_Components/U-Boot/Apps-SPL-Debug.html?highlight=watchdog

The Link above mentions a disableWatchdog() function, which is not yet implemented in the GEL debugger files for the AM64 SoCs.

3.) Is there a plan to support a "disableWatchdog() " function for AM64 in processor SDK in the future?

We would appreciate support by getting further information how to configure the registers when a watchdog is already running.

4.) Can provide specific information about the configuration of the "halt on peripheral" feature dedicated to the watchdog timers?

    (Programmers guide or similar)

5.) Clarification of On-Chip-Debug sections

  • Figure 13.1 On-Chip Block diagram
  • Table 13.2 Debug-Aware Peripheral Support

Figure 13.1 signals a path of the trace bus to the Peripheral Suspend block. It seems, that the DAPBUS is not connected to this block.

5.1 Can you confirm, that this is the correct interpretation or is this a mistake in the diagram?

Table 13.2 Debug-Aware Peripheral Support sections lists no supported processors for the Timers/Watchdog Timers, which relates to the diagram.

Figure 13.1.

5.2 Can you confirm that this table is correct and halt on peripheral function is not supported on any processors for watchdog timers?

5.3 Is it possible to stop all watchdog timers even though they are not related to the halted core?

Please note, that the support is related to following legacy forum entry:

e2e.ti.com/.../am6412-am64x-debug-infrastructure

Thank you in advance,

Steffen

  • I asked our Debug Subsystem expert to provide answers to your questions. I've inserted his answers below.

    1.) Additional information about on-chip debug features and their programming models is planned, release date is not yet available.  The specific questions about peripheral suspend and enabling watchdog timer debug is addressed below in response to question #4.

    2.) See #3 below.

    3.) At this time there are no plans to update the GELs.  We are following up on the discrepancy between the material noted on the Processor SDK webpage and the contents of the SDK.

    4.) The Debug Suspend Router programming model is equivalent to that of the Interrupt Router’s “MUXCNTL_n” register that is documented in section 9.3.3.2 of the TRM. 

    The Physical Address of the suspend router depends on the address space being used and the peripheral suspend destination that you are trying to configure.  It can be computed as follows:

    1. SOC Address Space (i.e. Processor view of SOC memory or AXI-AP view): 0x73D300000 + 0x4 + (n * 0x4).  Where ‘n’ is the value from Table 1 below (Peripheral Suspend Destination).
    2. Debug Address Space (i.e. APB-AP view): 0x1D300000 + 0x4 + (n * 0x4).  Where ‘n’ is the value from Table 1 below (Peripheral Suspend Destination).

    The 5-bit “ENABLE” field (bits 4:0 of MUXCNTL_n) of the MUX_CNTL_n register associated with the Peripheral Suspend Destination should be programmed to contain the peripheral suspend source that is desired.  See Table 2 below for AM64x (note values are in base-10).

    Table 1: Peripheral Suspend Destination

    MUX_CNTL_n

    “n”

    Associated Watchdog Timer

    10

    MCU_M4F RTI/WWDT

    42

    A53SS0 Core 0 RTI/WWDT

    43

    A53SS0 Core 1 RTI/WWDT

    44

    R5FSS1 Core 0 RTI/WWDT

    45

    R5FSS1 Core 1 RTI/WWDT

    50

    R5FSS0 Core 0 RTI/WWDT

    51

    R5FSS0 Core 1 RTI/WWDT

    Others

    Reserved for future use

     

    Table 2: Peripheral Suspend Source

    MUXCNTL_n:ENABLE[4:0]

    Associated Core

    1

    A53SS0 Core 0

    2

    A53SS0 Core 1

    19

    R5FSS0 Core 0

    20

    R5FSS0 Core 1

    21

    R5FSS1 Core 0

    22

    R5FSS1 Core 1

    24

    MCU_M4FSS0

    Others

    Reserved for future use

    5.1) This is a mistake in the diagram.  The peripheral suspend block is accessible via the APB-AP

    5.2) Table 13-12 is titled “Debug-Aware Peripheral Support” and includes entries for “TIMER instances” (this corresponds to DMTIMER instances) and “RTI/WWDT instances” (this is what you are referring to as “Watchdog Timer”).

    5.3) In AM64x, the suspend for all watchdog timers, except for the watchdog timer associated with the DMSC, can be associated with a user-specified core.  In the case of the DMSC’s allocated watchdog timer, only the DMSC M3 may suspend it.

    Regards,
    Paul

  • Thank you very much for the explanation!

    The instructions have been sufficient to halt the A53SS0 Core 0 RTI/WWDT on A53SS0 Core 0 halt.

    Writing following sequence: 0x10001

    INT_ENABLE                       0x10000

    MUX_CNTL_n:ENABLE     0x00001 ( A53SS0 Core 0 from Table 2)

    to register: 0x73D3000AC (A53SS0 Core 0 RTI/WWDT) .

    Confirmable by our side using the AXI-AP bus.

    We would appreciate further documentation about the On-Chip-Debugging capabilities anyhow.