PSoC 5LP WDT Reset Detection

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
GrRa_284656
Level 2
Level 2
5 sign-ins 10 replies posted 5 replies posted

Hi to all!

   

The PSoC® Creator™ System Reference Guide, Document Number: 001-94480, Rev. ** (page 97) states:
"The CySysResetReason() function can be used to detect if the watchdog has triggered device reset"

   

It seems to me that this function does not exist!

   
    
          
   
   
    
          
   
   
    
      Does anyone have the specifications for this function?    
    
      Or this is a documentation error?    
    
          
    
     Thank you to all!    
    
          
    
     Graziano G. Ravizza    
   
   

 

   

 

   

 

   

    

   

         

0 Likes
7 Replies
GrRa_284656
Level 2
Level 2
5 sign-ins 10 replies posted 5 replies posted

Hi,

   

Since I think CySysResetReason() function does not exist, I'm testing the use of RESET_SR0 register to detect the source of the reset.

   

At the very beginning of the main code I put the test:

   

void main()
{
    uint8 ResetReason;    /* Reason of Reset */

   

    ResetReason = CY_GET_REG8(CYDEV_RESET_SR0);
   
    if ((ResetReason & 0x08) == 0x08)
    {

   

        // THE RESET source was WATCHDOG!
    }   

   

...and so on

   

BUT seems the code does not recognize that the source of the reset was a WDT (I'M SURE was a WDT!)

   

What do you think?

   

Something wrong? Any suggestions?

   

Thanks to all!

   

Graziano

0 Likes

Hey,

   

Can you please attach the project. We can have a look at the project.

   

 

   

Thanks,

   

Hima

0 Likes

Ref PSoC 5LP

Note the absence of any meaningful response from Cypress. If they actually knew anything about the reset handler, they would have told you that unless you are doing a bare-metal implementation, without any boot loader code, you cannot access RESET_SR0 in any meaningful way. RESET_SR0 is read during the boot process:

Reading RESET_SR0 directly is supposed to result in it clearing, but maybe or maybe not the 2 upper bits? The documentation is hopelessly contradictory.

I think part of the reason for confusion here is that Cypress documents the physical hardware separately from the firmware that uses it. At the hardware level, RESET_SR0 supposedly clears when read. Except those upper 2 bits, which may not. Or maybe they do.

But RESET_SR0 is read by firmware during the boot process, and the value is supposed to be stored (via an intermediate transfer to CYREG_PHUB_CFGMEM23_CFG1), so the firmware that you write never has access to the value of the register before it is cleared - only a copy of it. Which may or may not be further manipulated by the boot firmware.

See Cm3Start.c

For unknown reasons, my firmware configuration (#defines) is such that the intermediate transfer never occurs, to the CyResetStatus value is not meaningful.

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I tried this with CY8CKIT-059.

It seems that accessing CYREG_PHUB_CFGMEM23_CFG1

we can see the value of RESET_SR0.

So m print_reset_status()

=========================

#define BIT_LVID_RESET 0x01

#define BIT_LVIA_RESET 0x02

#define BIT_HVIA_RESET 0x04

#define BIT_WDT_RESET  0x08

#define BIT_SOFT_RESET 0x20

void print_reset_status(void)

{

    uint8_t reset_status =     *((uint8_t *)CYREG_PHUB_CFGMEM23_CFG1) ;

    snprintf(str, STR_BUF_LEN , "CYREG_PHUB_CFGMEM23_DFG1: 0x%02X : ", reset_status) ;

    print(str) ;

    if (reset_status & BIT_LVID_RESET) {

        print("LVID ") ;

    }

    if (reset_status & BIT_LVIA_RESET) {

        print("LVIA ") ;

    }

    if (reset_status & BIT_HVIA_RESET) {

        print("HVIA ") ;

    }

    if (reset_status & BIT_WDT_RESET) {

        print("WDT ") ;

    }

    if (reset_status & BIT_SOFT_RESET) {

        print("Software Reset ") ;

    }

    print("\n\r") ;

}

=========================

schematic

001-schematic.JPG

pins

002-pins.JPG

Tera Term log

Note:

At first, I pushed the reset button, value was 0x00

Then to show the command list, I chose "help"

then I entered "soft" to cause software reset and reset reason was reported correctly

then I entered "wdt" to cause wdt reset and so on.

When we see a line "Reset Test (...", this means the PSoC returned from reset.

000-TeraTerm-log.JPG

moto

StKr_1203736
Level 3
Level 3
First like received 10 replies posted 10 sign-ins

Unfortunately, my efforts at using even the most trivial example code provided by Cypress have failed. I tried installing the CY8KIT-050, because I bought one. The supplied disk is from 2013, so it is worthless. I downloaded the installation file WITHOUT PSoC creator (I am already using 4.2, and I don't want it overwritten) and installed it. The files go in Program Files (X86), and any attempt to load them from there results in a series of errors about file and path names being too long. I tried moving them to the root of C:, and would up with other errors - the #included "project.h" does not exist because.. it is generated code, and until it is built it does not exist. But I cannot build without it.

In reality, I have no interest in the demo code. The demo code that was emailed to me was trivial and told me nothing. The code above tells me nothing. The problem is, immediately after startup, regardless of the reason for startup (power up or watchdog timer), the value of CyResetStatus is ALWAYS 0xA0, which indicates a SOFTWARE RESET + GPIO1, not a WATCHDOG RESET.

THE VERY FIRST LINE IN MY main():

uint8 ResetReason = CyResetStatus;      // save cause of reset for later processing

PLEASE STOP PARROTING THE DOCUMENTATION TO TELL ME WHAT BITS MEAN. I have seen this over and over again from multiple people. THAT IS NOT THE PROBLEM. PLEASE STOP PARROTING THE DOCUMENTATION TO TELL ME WHAT BITS MEAN.

The problem here is that 0xA0 is the WRONG VALUE. I have my code setup to start the watchdog timer, and then hang in a do-while loop. The processor resets, and the CyResetStatus value indicates a SOFTWARE RESET + GPIO1. PLEASE DO NOT TELL ME AGAIN WHAT THE BITS MEAN.

I think that the problem is that this line in Cm3Start.c is never executed:

*(reg32 *)(CYREG_PHUB_CFGMEM23_CFG1) = *(reg32 *)(CYREG_RESET_SR0);

It appears in Cm3Start.c THREE (count em!) THREE TIMES for different configurations. See lines 161, 306, and 397. In my source code set, ALL THREE are greyed out, and thus not compiled. This makes it VERY difficult for the code to be executed, because it does not exist!

PLEASE DO NOT TELL ME AGAIN WHAT THE BITS MEAN.

I am using the GCC compiler.

Line 161 is #ifdef OUT because I am not using __ARMCC_VERSION

Line 306 is #ifdef OUT because this line is not true:

   #if(CYDEV_PROJ_TYPE != CYDEV_PROJ_TYPE_LOADABLE && CYDEV_PROJ_TYPE != CYDEV_PROJ_TYPE_LOADABLEANDBOOTLOADER)

Line 397 is #ifdef OUT because I am not using __ICCARM__

As a result, when line 480 executes, the value written to CyResetStatus IS WRONG. It has NO CONNECTION to the value of RESET_SR0 because RESET_SR0 is NEVER READ.

PLEASE DO NOT TELL ME AGAIN WHAT THE BITS MEAN.

I have to assume at this point that the problem lies here:

Line 306 is #ifdef OUT because this line is not true:

   #if(CYDEV_PROJ_TYPE != CYDEV_PROJ_TYPE_LOADABLE && CYDEV_PROJ_TYPE != CYDEV_PROJ_TYPE_LOADABLEANDBOOTLOADER)

PLEASE help me understand what these configuration macros mean, and what I need to do to fix them.

PLEASE DO NOT TELL ME AGAIN WHAT THE BITS MEAN. I know what the bits mean. There is something else wrong here.

Steve

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Dear Steve-san,

So you are mad at me?

I'm very sorry for making you upset, please believe me I was not meaning it.

Having said that the sample I posted yesterday was at least working with my CY8CKIT-059.

And when I typed "wdt", it caused WatchDog reset and flag was correctly set.

So I re-targeted the device of my project to CY8C5868AXI-LP035 which is used in CY8CKIT-050.

Actually the project is from the second discussion below (as it was newer version)

Perform Reset PSOC5 with a flag displaying a custom reset cause

And I made sure that the 050 project could be built.

Unfortunately as I don't have access to CY8CKIT-050 right now, I can not test it.

(Please connect P12[6] and P12[7] to UART)

Then I read Cm3Start.c as you mentioned 161, 306, 397 as below

Block containing the line 161 (greyed)

000-161.JPG

Block containing 306 (alive!)

001-306.JPG

Block containing 397 (greyed)

002-397.JPG

So IMHO, with my sample project attached the flag might be set correctly.

And in case my sample works for your hardware.

Please compare setting/definitions of your project/environment which greyed all of above.

Best Regards,

4-Mar-2020

Motoo Tanaka

P.S. Just in case, if your environment greys even my project,

I attached the hex file so that you can download it to your board and test the behaviour.

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Dear Steve-san,

After posting my previous response, I re-read Cm3Star.c

The define macros are

============

#if defined(__ARMCC_VERSION) // if you are using MDK KEIL

...

#elif defined(__GNUC__) // if you are using default GCC came with PSoC Creator

...

#elif defined (__ICCARM__) // if you are using IAR

============

So what happening in your environment seems that you are not using any of

MDK KEIL, IAR WARM, nor default GCC came with PSoC Creator.

How about try setting the Toolchain to "ARM GCC 5.4-2016-q2-update"

in the Project > Build Settings > Toolchain:

and see if the line 306 (actually 195 - 367) will be activated?

003-Build-Settings.JPG

Best Regards,

4-Mar-2020

Motoo Tanaka

0 Likes