TMS570LC4357: TMS570 SWRST not causing EXTRST flag

Dustin Sjoerdsma

Part Number: TMS570LC4357

The datasheet for the TMS570LC43x states that the EXTRST (external reset flag) will be set during a SWRST event. However, when triggering a SWRST event, only the SWRST flag is set and not the EXTRST flag.

Here is the function call for initiating the SWRST:

void warmReset(void)
{
    systemREG1->SYSECR |= SYS_RESET_BIT;
    return;
}

During the reset, the _c_int00() function is called to initialize the processor. During this phase, the getResetSource() function is called which checks the state of the SYSESR register. This register shows the flag set during the reset event. Before this function is called, the SYSESR register is reading 0x00000010 (only the SWRST bit is set), when I would have expected it to be 0x00000018 (SWRST bit and the EXTRST bit).

Without the EXTRST flag getting set, the startup code is never able to return that a SW_RESET event has occurred, which causes future issues.

/* SourceId : SYSTEM_SourceId_008 */
/* DesignId : SYSTEM_DesignId_008 */
/* Requirements : HL_CONQ_SYSTEM_SR9 */
resetSource_t getResetSource(void) 
{ 
    register resetSource_t rst_source; 
        
    if ((SYS_EXCEPTION & (uint32)POWERON_RESET) != 0U)
    { 
        /* power-on reset condition */
        rst_source = POWERON_RESET;
        /* Clear all exception status Flag and proceed since it's power up */ 
        SYS_EXCEPTION = 0x0000FFFFU;        
    }

    else if ((SYS_EXCEPTION & (uint32)EXT_RESET) != 0U) 
    {      
        SYS_EXCEPTION = (uint32)EXT_RESET; 
        /*** Check for other causes of EXT_RESET that would take precedence **/
        if ((SYS_EXCEPTION & (uint32)OSC_FAILURE_RESET) != 0U)
        { 
            /* Reset caused due to oscillator failure. Add user code here to handle oscillator failure */ 
            rst_source = OSC_FAILURE_RESET; 
            SYS_EXCEPTION = (uint32)OSC_FAILURE_RESET; 
        }
        else if ((SYS_EXCEPTION & (uint32)WATCHDOG_RESET) !=0U)
        { 
            /* Reset caused due watchdog violation */ 
            rst_source = WATCHDOG_RESET; 
            SYS_EXCEPTION = (uint32)WATCHDOG_RESET; 
        }
        else if ((SYS_EXCEPTION & (uint32)WATCHDOG2_RESET) !=0U)
        { 
            /* Reset caused due watchdog violation */ 
            rst_source = WATCHDOG2_RESET; 
            SYS_EXCEPTION = (uint32)WATCHDOG2_RESET; 
        }
        else if ((SYS_EXCEPTION & (uint32)SW_RESET) != 0U)
        { 
            /* Reset caused due to software reset. */ 
            rst_source = SW_RESET; 
            SYS_EXCEPTION = (uint32)SW_RESET; 
        }
		else
		{
			/* Reset caused due to External reset. */ 
            rst_source = EXT_RESET; 
		}
    } 
    else if ((SYS_EXCEPTION & (uint32)DEBUG_RESET) !=0U)
    { 
        /* Reset caused due Debug reset request */ 
        rst_source = DEBUG_RESET; 
        SYS_EXCEPTION = (uint32)DEBUG_RESET; 
    }
    else if ((SYS_EXCEPTION & (uint32)CPU0_RESET) !=0U)
    {     
        /* Reset caused due to CPU0 reset. CPU reset can be caused by CPU self-test completion, or by toggling the "CPU RESET" bit of the CPU Reset Control Register. */ 
        rst_source = CPU0_RESET; 
        SYS_EXCEPTION = (uint32)CPU0_RESET; 
    }
    else
    {
        /* No_reset occured. */ 
        rst_source = NO_RESET; 
    }
    return rst_source; 
}

Additionally, to confirm that the EXTRST flag is functioning correctly, when I perform an actual external warm reset, by driving the nRST pin low, the result is the SYSESR register being 0x00000008 as expected.

I am currently working off of the TMS570LC43x Hercules Development Kit and have used the WARM_RSTn button to test the above.

To summarize, should the SWRST flag automatically also flag the EXTRST flag?

TRM: https://www.ti.com/lit/ug/spnu563a/spnu563a.pdf?ts=1643142714687&ref_url=https%253A%252F%252Fwww.google.com%252F

Relative page of TRM is page 199

over 3 years ago

0 Dustin Sjoerdsma over 3 years ago

Prodigy 20 points

I would also like to link this thread:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/693755/tms570lc4357-data-abort-after-software--or-watchdog-triggered-reset

This seems to be a similar issue to what I am facing. I do not think this issue was properly solved.

0 QJ Wang over 3 years ago in reply to Dustin Sjoerdsma

TI__Guru**** 197446 points

Hi Dustin,

I noticed the issue on LC43x HDK. I will check SWRST on other board. If the EXTRST is not set, we need to change the code in getResetSource(void) or add code to c_int00() to handle SW reset.

0 QJ Wang over 3 years ago in reply to QJ Wang

TI__Guru**** 197446 points

Hi Dustin,

I run the same test on LC43x launchpad. The EXTRST bit is set by SW reset ( systemREG1->SYSECR = 0xC000;). Before issuing SW Reset, the SYSESR is cleared to 0x00000000. After SW reset, the ESR=0x018.

0 Dustin Sjoerdsma over 3 years ago in reply to QJ Wang

Prodigy 20 points

Hmmm. That is odd my findings are not consistent with this. Where in the code is your breakpoint located for checking the SYSESR register? Right before the getResetSource() function is called?

Is this a REV E board with a TMS5704357 onboard? Do you know the exact chip number?

My findings is consistent with Jens post in the linked thread. I am going to include the statement here:

e2e.ti.com/.../tms570lc4357-data-abort-after-software--or-watchdog-triggered-reset

Hi Sunil,

I think we are talking about two different problems. I changed the getResetSource function as you described, but the EXT_RESET bit is never set when the function is entered. The function always returns the right reset source. It does not always return EXT_RESET as you assumed.

So when I do a software reset, getResetSource returns SW_RESET correctly. Then in _c_int00, all the initializations in the switch are skipped for the case SW_RESET, and my application crashes. When I just put the case SW_RESET at the top of the switch, it seems to work, but I'm not sure, if this is the right way do do this.

Regards,

Jens

and additionally consistent with this statement as well:

Hi Sunil,

I'm using the HDK at the moment, without any modification of the reset circuit. I checked the nRST pin with a scope; is not driven low when I cause a SW- or watchdog reset. nRST is only driven low when press the S3 button (signal WARM_RSTn). The reset triggered by the S3 button is detected as EXT_RESET (0x0008).
So I will patch the initialzation sequence for the short term and double-check it again when your suggested reset handler is ready.

Thanks and regards,
Jens

0 Dustin Sjoerdsma over 3 years ago in reply to Dustin Sjoerdsma

Prodigy 20 points

Hi QJ,

I wanted to follow up on this issue. Specifically to learn more about your test environment and to learn what may be different between yours and my setups. I want to confirm I will not see different results across chips/boards.

Any additional information on your development setup, such as development board rev #, specific processor extended number on the development board, and where you are testing your results would be greatly appreciated.

Thanks!

Dustin