AM263P4: UniFlash reset

Hi Nilabh,

To follow up on this.

What does the "cpu reset" or "system reset" actually do?

Regards

Neil

Thanks Nilabh,

If I pull the WARM_RESET line low should I expect to see the MCU reset back to the boot loader ?

Regards

Neil 

Yes that is correct Neil

What is happening when UniFlash says:

[INFO] Cortex_R5_0: GEL Output: CPU reset (soft reset) has been issued through GEL on program load

I very often see no reset of the processor and UniFlash fails.

Are there reasons why a "soft reset" would fail to reset the MCU?

The only way I can program the board is to try and time a physical reset and click "Load Image"

Regards

Neil

Hi Nilabh, I have been using xds110reset and I see the warm reset line toggle on an oscilloscope.

I do not see the MCU reset.

In the AM263PX TRM it states:

6.3.2.2.1 Warm Reset by WARMRSTn HW Pin

This reset pin is the warm reset request (active LOW) given externally from the pad..

By default, the input path to trigger a warm reset from external pad is disabled. To enable, the TOP_RCM.WARM_RESET_CONFIG.PAD_BYPASS bit should be written 3’b000.

That means that warm reset is not enabled and I need to enable it in software?

Is there an example anywhere on how to provide this enable?

Regards

Neil

Hi Nilabh, but this is the MCU creating the WarmReset ?

What I want is to be able to use the warm reset input from an external source to reset the MCU.

e.g. on the LP-AM263P dev board SW3 is connected via a resistor to the warm reset input to the MCU

the user guide text suggests it resets the MCU.

I do not see that action either on the LP or our own board.

Is there some configuration needed to enable an input to the warm reset pin of the MCU to cause a reset.

Thanks Nilabh,

Are here any restrictions where this call is used?

I am using the hello_world_am263px-lp_r5fss0-0_nortos_ti-arm-clang example.

When I call SOC_configureWarmResetSource(SOC_WarmResetSource_PAD_BYPASS);

The program traps in HwiP_user_data_abort_handler_c

Regards

Neil

Hi Neil, Let me look into it tomorrow.,

Hi Nilabh, have you managed to make any progress with this please? 

Regards

Neil

Hi Zackary,

Do you have a software example with this configuration that is proven to work ?

If so can I have access to it please both to quicken my testing time but also to make sure I do not configure the MCU incorrectly. Thanks.

Regards

Neil

Hi Neil,

Step 1: Enable the External Pad Input Path

Write 3'b000 to the TOP_RCM.WARM_RESET_CONFIG.PAD_BYPASS field using the MCU+ SDK API:

SOC_configureWarmResetSource(SOC_WarmResetSource_PAD_BYPASS);

This is the critical call that enables the WARMRSTn pin to accept external reset signals.

Step 2: Configure Glitch Filter Timing

The external reset input requires a minimum pulse duration to register as valid. Configure the timing registers to prevent noise-induced resets:

/* Set minimum LOW duration for reset assertion (16.384 ms recommended) */
SOC_configureWarmResetInputFallDelay(15);

/* Set minimum HIGH duration for reset deassertion */
SOC_configureWarmResetInputRiseDelay(15);

Timing values range from 0 (500ns) to 15 (16.384ms). For external push-buttons or monitoring circuits, value 15 is recommended for reliability.

Step 3: Hardware Design

Ensure your board layout includes:

• Pull-up resistor to VDDS33 (3.3V) on the WARMRSTn pin (required—the pin is open-drain)
• Open-drain buffer (e.g., SN74LVC1G07) if you need both reset input and reset status output simultaneously (prevents bus contention)

Regarding the Data Abort Exception

The HwiP_user_data_abort_handler_c fault you encountered when calling SOC_configureWarmResetSource() in the hello_world example suggests a timing or initialization order issue. To avoid this:

1. Call the configuration early in your initialization sequence—after Drivers_open() and Board_driversOpen(), but before entering main application logic
2. Do not call it from an interrupt handler or exception context
3. Ensure RCM (Reset Control Module) is accessible before the call

Here's the recommended initialization pattern:

int main(void)
{
    Drivers_open();
    Board_driversOpen();
    
    /* Configure warm reset EARLY, before main loop */
    SOC_configureWarmResetSource(SOC_WarmResetSource_PAD_BYPASS);
    SOC_configureWarmResetInputFallDelay(15);
    SOC_configureWarmResetInputRiseDelay(15);
    
    /* Rest of application */
    while(1)
    {
        /* Main loop */
    }
    
    return 0;
}

Verification

After reset occurs (triggered by pulling WARMRSTn low), you can verify the reset cause:

uint32_t resetCause = SOC_getWarmResetCause();
/* Check if SOC_WarmResetSource_PAD_BYPASS was the source */

If you continue to encounter the data abort exception after moving the configuration call to early initialization, please:

1. Share your complete initialization sequence (or a minimal reproduction case)
2. Confirm you're using the latest MCU+ SDK for AM263P4
3. Check if there are any custom GEL scripts or SysConfig settings that might interfere with RCM access

This configuration has been validated on the LP-AM263P board with SW2, and the same approach applies to your custom board design.

#include <stdint.h>
#include "ti_drivers_config.h"
#include "ti_drivers_open_close.h"

/* Configure external WARMRSTn pad as reset input source */
void configureExternalWarmReset(void)
{
    /* Step 1: Enable external pad input path
     * Write 3'b000 to TOP_RCM.WARM_RESET_CONFIG.PAD_BYPASS
     * This enables the WARMRSTn pin to accept external reset signals
     */
    SOC_configureWarmResetSource(SOC_WarmResetSource_PAD_BYPASS);
    
    /* Step 2: Configure glitch filter timing
     * Set minimum LOW duration to assert warm reset (16.384 ms recommended)
     * This prevents noise/glitches from triggering unintended resets
     */
    SOC_configureWarmResetInputFallDelay(15);  // 15 = 16.384 ms
    
    /* Step 3: Configure deassertion delay
     * Set minimum HIGH duration to deassert warm reset
     */
    SOC_configureWarmResetInputRiseDelay(15);  // 15 = 16.384 ms
}

/* In your main() or early initialization: */
int main(void)
{
    Drivers_open();
    Board_driversOpen();
    
    /* Configure warm reset BEFORE any other operations */
    configureExternalWarmReset();
    
    /* Rest of your application code */
    while(1)
    {
        /* Main loop */
    }
    
    return 0;
}

Best Regards,

Zackary Fleenor

Hi Zackary,

Thank you.

I tried your solution on the LP-AM263P and I did not see a reset of the MCU when I press SW3.

Regards

Neil

I am using the latest TI SDK provided.

We have no custom GEL scripts and I use the latest UniFlash to program the SBL & application to the LP-AM263P

For ref my board is a PROC171E2A(001)

Hey Neil,

I have corrected a typo in my previous response. The correct pushbutton is SW2 (SW2_RESETn). SW3 is connected to a gpio pin for external interrupts and does not have a hardware connection to the WARMRSTn pin.

Best Regards,

Zackary Fleenor

But according to the schematic I am looking at SW2 is the PORZ so I'd expect that to reset the MCU regardless of software?

SW3 is wired into the WarmReset line.

Regards

Neil

Hi Zackary, 

Thanks for confirming.

This is what I am running via CCS20.5.1 on the LP-AM263P board.

The data abort seems to have gone away with the latest SDK.

I do not see a reset when I press SW3.

I see the count increasing in the CIO window.

Regards

Neil

Hi Neil,

Thank you for the continued effort and debugging on your end.

After further investigation, I have compliled a list of things to check below:

• The Risk: If the physical button press on SW3 is transient or shorter than the required window to satisfy the glitch filter requirements, the Reset Control Module (RCM) will ignore the signal to prevent accidental resets from noise.
• Recommendation: Temporarily reduce the SOC_configureWarmResetInputFallDelay and RiseDelay to a much lower value (e.g., 0 or 1) to determine if the reset triggers. If it works with lower values, your previous timing was too long for human interaction speeds.

• Target Register: TOP_RCM.WARM_RESET_CONFIG
• Verification Method: In the Expressions window of CCS, add the register address for TOP_RCM. Check if the bit corresponding to PAD_BYPASS is high after your configuration function executes.

• Requirement: Ensure that the pin associated with WARMRSTn is not being overridden by another peripheral (like a GPIO or a different functional mode) later in the Board_driversOpen() or Drivers_open() sequence.
• Check: Verify that the pin is set to the correct mode that allows the RCM to sense the external signal.

• Check: Verify the voltage levels on the WARMRSTn pin using an oscilloscope during a button press. Ensure the signal is actually pulling low to the expected logic threshold.
• Check: Confirm if the WARMRSTn pin is being driven high by another component on the Launchpad that might be fighting the button press.

Summary of Next Steps

1. Decrease Glitch Filter values to minimum settings to rule out timing mismatch.
2. Use CCS Expressions to verify the TOP_RCM.WARM_RESET_CONFIG register state.
3. Audit PinMux settings to ensure no peripheral is "stealing" the WARMRSTn pin after initialization.
4. Oscilloscope measurement to confirm the physical signal reaches the required logic-low threshold.

Best Regards,

Zackary Fleenor

On the LP-AM263P

1. 0 or 1 does not change the behaviour

2. I see the value of 7 in the register which implies the write is being blocked ?

3. It's a minimal syscfg file, no GPIO settings etc

4.  I can see the level going to GND on a scope at pin 2 of SW3

Regards

Neil

One issue is that