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.

Detecting reset due to watchdog timeout on AM3358

Other Parts Discussed in Thread: AM3358

Is it possible to detect, during boot time, whether the reset that we're currently booting from was caused by the hardware watchdog timing out, as opposed to another kind of reset, on the AM3358?

I looked through the TRM, but didn't see anything along these lines.

  • The PRM_RSTST register contains this info, see section 8.1.13.5.3 of the TRM.

    It appears it doesn't get cleared by u-boot or the kernel, so you can still read it from userspace after boot.  For an example on directly accessing the PRCM module from userspace, grab my "jbang" project from github, add a file src/rstst.cc with the following contents:

    #include "defs.h"
    #include "util/device.h"
    #include "ti/subarctic/prcm.h"
    #include "map-phys.h"
    #include <stdio.h>
    
    Prcm &prcm = map_phys<Prcm>( 0x44e'00'000 );
    
    let main() -> int
    {
    	let st = prcm.dev_rststat;
    	dev_send( prcm.dev_rststat, st );  // clear bits
    	if( st & ( 1 << 0 ) ) puts( "cold reset occurred" );
    	if( st & ( 1 << 1 ) ) puts( "software warm reset occurred" );
    	if( st & ( 1 << 2 ) ) puts( "security violation reset occurred" );
    	if( st & ( 1 << 3 ) ) puts( "watchdog 0 reset occurred" );
    	if( st & ( 1 << 4 ) ) puts( "watchdog 1 reset occurred" );
    	if( st & ( 1 << 5 ) ) puts( "external warm reset occurred" );
    	if( st & ( 1 << 9 ) ) puts( "icepick warm reset occurred" );
    	return 0;
    }

    and modify to Makefile to include programs += rstst (in addition to or instead of jbang), and the rule

    rstst: rstst.cc map-phys.cc

    Type make rstst if compiling natively or e.g. make rstst CROSS_COMPILE=arm-linux-gnueabihf- if using a cross-compiler. GCC 4.9 is required, older versions will not work. (I've tested it with debian native g++ 4.9.2-10 and the Linaro 2014.11 arm-linux-gnueabihf cross-compile toolchain.)  Ancient versions of make might also have issue with my makefile, in which case you can try compiling it manually (include at least -std=gnu++1y as compiler flag).

    Note that I'm clearing the reset status bits, so only the first run of the program will report anything. This is necessary since reset-cause flags will otherwise persist across warm resets and you won't be able to tell which reset was responsible for the most recent one.