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.

AM263P4-Q1: How to reset everything when starting new debug session?

Part Number: AM263P4-Q1
Other Parts Discussed in Thread: AM263P4

Hello,

my experience with microcontrollers so far is that if I start a new debug session everything is reset and registers have their default value, so basically like a POR.

With TI, or specifically this controller (?) and CCS20.4, it is different and I did not manage to achieve what I want and expect, yet. 

The default way does some kind of reset, but does not reset the peripheral registers like EPWM what will result in half broken PWM signals and unexpected behaviour. Also, it is potentially dangerous in the context of power electronics, because the PWM signals will just continue, while the controller is halted and reprogrammed.

Setting "Apply NRESET/SRST Pin On Debug Header" to "Pulse this pin on debug probe startup" in the advanced settings of the target config does indeed issue a HW reset resulting in clean register, but the startup will get stuck at "GEL Expression: OnTargetConnect()". I can cancel the popup in CCS and it will continue with the log entry "Cortex_R5_0: GEL: Error while executing OnTargetConnect(): Evaluation cancelled", but this is annoying and I don't know if the cancelation causes other issues. Also, this reset pin option is not available with XDS110, only with XDS200.

What do I have to do that when I click “Start Debugging”, the controller is reset completely and a new debug session is started, no extra steps involved?

Best regards,
Frank

 

  • Hi Frank,

    To achieve a complete system reset when starting a debug session on the AM263P4, you need to either configure CCS to perform a System Reset automatically on connect, or enable hardware reset with a modified GEL file to prevent the OnTargetConnect() hang. The default CPU Reset only resets the R5F core, not peripherals like EPWM, which explains your observed behavior.

    Response

    Understanding the Reset Behavior

    Your observation is correct - the default debug connection behavior on the AM263P4 does not perform a complete system reset. A standard CPU Reset or Restart within the debugger will only reset the R5F core and not the entire System on Chip (SoC) or its peripherals [1]. This is why your EPWM registers retain their previous state, causing the dangerous PWM continuation you've experienced.

    The reset behavior is controlled by GEL (General Extension Language) files located at ${MCU_PLUS_SDK_PATH}/tools/ccs_load/am263px/. When the debugger connects, the OnTargetConnect() function within the am263px_main.gel file is executed, which calls AM263Px_multicore_reset_and_halt() - a function designed only to hold the R5F and M4F cores in reset for IDE connection, not to reset all peripherals [2].

    Solution 1: Configure Automatic System Reset on Connect

    The most straightforward solution is to configure CCS to automatically perform a System Reset when connecting:

    Steps to Enable Automatic Reset:

    1. In CCS, go to Run > Debug Configurations...
    2. Select your target configuration from the list on the left
    3. Navigate to the Target tab
    4. Under the Auto Run and Launch Options group, check the box for Reset the target on a connect [3]

    Note: This feature is not supported by all targets and debug probes [3]. After enabling this option, when you start debugging, the system will perform a reset equivalent to a Power-On Reset (POR), resetting the whole SoC including all peripherals.

    Solution 2: Manual System Reset Procedure

    If automatic reset on connect is not available or doesn't work with your setup, you can perform a manual System Reset after connecting:

    1. In the CCS Debug view, select the Cortex_R5_0 core
    2. Navigate to Run > Reset > System Reset
    3. After the reset, the core will be halted. To start the application from the beginning, navigate to Run > Resume [4]

    This System Reset is equivalent to a POR and resets the entire SoC including all peripherals [4].

    Solution 3: Fix the Hardware Reset GEL Hang Issue

    You've correctly identified that enabling hardware reset via "Apply NRESET/SRST Pin On Debug Header" causes the debugger to hang at "GEL Expression: OnTargetConnect()". This occurs because the GEL script attempts to access the device while it is still in reset [5].

    For XDS200 Debug Probe:

    There is a documented workaround specifically for the XDS200 probe:

    1. Go to View > Target Configurations
    2. Right-click on your .ccxml file and select Properties
    3. Go to the Advanced tab
    4. Select the Cortex_R5_0 core
    5. Ensure the Reset Type is set to HW Reset
    6. Change the Initialization script from the default .../mcu_plus_sdk/tools/ccs_load/am263px_r5.gel to .../mcu_plus_sdk/tools/ccs_load/am263px_r5_noDAP.gel [6]

    The hang is caused by a dummy DAP write performed by the default GEL file, and the am263px_r5_noDAP.gel file omits this write [6].

    Alternative GEL Modification Method:

    If the above workaround doesn't fully resolve your issue, you can manually modify the GEL file:

    1. Locate the GEL file at: {CCS_INSTALL_DIR}\ccs\ccs_base\emulation\gel\AM263x\AM263x.gel
    2. Open the file and find the OnTargetConnect() function
    3. Add the line GEL_Delay(100000); at the very beginning of the function to add a 100ms delay [5]

    This delay allows the device to come out of reset before being accessed by the GEL script.

    XDS110 Limitation:

    Unfortunately, the hardware reset pin option is not available with the XDS110 debug probe - it only works with XDS200 [6]. If you're using XDS110, you'll need to rely on Solution 1 (automatic system reset on connect) or Solution 2 (manual system reset) instead.

    Recommended Approach

    For your use case with power electronics where PWM continuation during debug is dangerous, I recommend:

    1. First, try Solution 1 - Enable "Reset the target on a connect" in the debug configuration. This should provide the cleanest automatic reset behavior.

    2. If using XDS200, implement Solution 3 with the modified GEL file to enable hardware reset without the hang issue.

    3. If using XDS110, you're limited to software-based system reset options (Solutions 1 or 2), as hardware reset configuration is not supported with this probe.

    Additional Considerations

    When reloading code during an active debug session, you don't need to terminate the session. You can use Run > Load > Load Program... (or Reload Program...), and CCS will prompt for a reload if it detects a rebuilt executable [7]. However, this reload does not perform a system reset, so peripheral states will persist unless you manually execute a System Reset afterward.

    Citations

    1. AM263x/AM263Px MCU+ SDK User's Guide - System Reset vs CPU Reset
    2. AM263x/AM263Px MCU+ SDK User's Guide - GEL File Initialization
    3. AM263x/AM263Px MCU+ SDK User's Guide - Auto Reset on Connect Configuration
    4. AM263x/AM263Px MCU+ SDK User's Guide - System Reset Procedure
    5. AM263x/AM263Px MCU+ SDK User's Guide - Hardware Reset GEL Modification
    6. AM263x/AM263Px MCU+ SDK User's Guide - XDS200 Hardware Reset Workaround
    7. AM263x/AM263Px Application Note - Debug Session Management
  • this AI answer is not helpful and full of bs

  • Hi Frank,

     On TI EVMs, the System Reset does WARMRSTn through XDS110, which will basically reset everything.

    but the startup will get stuck at "GEL Expression: OnTargetConnect()". I can cancel the popup in CCS and it will continue with the log entry "Cortex_R5_0: GEL: Error while executing OnTargetConnect(): Evaluation cancelled", but this is annoying and I don't know if the cancelation causes other issues. Also, this reset pin option is not available with XDS110, only with XDS200.

    You can comment out the GEL reset api in .gel file, if you are doing it by the NRESET pin header.

    What do I have to do that when I click “Start Debugging”, the controller is reset completely and a new debug session is started, no extra steps involved?

    It would still be a two step process, reset the controller, then click start debugging