Can constant use of watchdog timer reset damage the device?

[bugkiller]

Hi so I'm using CY8C4248LQI-583 MCU to my custom board. Normally, it works fine but sometimes it goes to hardfault and every function is pause. So I decide to add WDT reset so it can automaticaliy reset the system(1 hour term).  My device must to be keep on, it must not be turned off.

So my question is same as title. Does constant resetting device hurt system? Also, is there recommended reset time for the system?

Best regards, BK.

[BiBi_1928986]

Hello.

The time constant for watchdog is dependent on what your system requires.  For my systems, it's always been 2 seconds or less.

I'm aware of 2 things that can damage the PSoC.
1. excessive writes to FLASH using EM_EEPROM (datasheet spec is 100k writes to the same location)
2. writes to nonvolatile latch.  I couldn't find the spec, but I would assume it's similar to FLASH writes.

If you do any clock trim changes, that could also wear out the SFLASH (System FLASH, separate from user FLASH).

Other people can chime in.

[Len_CONSULTRON · Accepted solution]

BK,

Absolutely no harm to the device can come from resetting the watchdog.  The watchdog and reset mechanism is designed to operate for years of constant resetting.  I've designed products using watchdogs that need to be reset for many years now.  A number of of these products are still on a wall performing it job for twenty+ years.

BiBi is correct about reaching the wear endurance of non-volatile memory such as EEPROM, FLASH and non-volatile register latches.    The total number of erase cycles need to be determined for the life of your application.  Consult the datasheet for how many wear endurance cycles are allowed.

As to clock trimming effecting SFLASH ...  that's a new one to me.   It is my understanding that you can read non-volatile memory as much as you want.  It doesn't effect wear endurance cycles.  

[BiBi_1928986]

Hi Len.

Thanks for clarifying trim vs nonvolatile System FLASH.  I've never had to use the trim feature, but I was aware some trim data was stored in SFLASH.  I had assumed (wrongly) that when a clock is trimmed, the new values are stored back in SFLASH.  Having just read the TRM, I now see that trim data is moved from SFLASH into PSoC registers upon reset and these registers can later be modified by the user.  Cool.

[Len_CONSULTRON]

BiBi,

Factory trim values are loaded into SFLASH.   these values for all calibratable resources are determined during the IC-in-package testing phase.

Calibratable resources such as:

• IMO
• ILO
• VDAC
• IDAC
• ADC SAR
• ADC DelSig
• probably a few others I forgot.

These trim are the values to get the resource as close to the datasheet nominal specification of 20C as best it can.  It stores it into the specified area in SFLASH (theoretically only written once.).

When you initialize a resource, it loads the trim value from SFLASH (non-volatile) into the peripheral trim register (volatile) for that resource.

The application SW designer if desired can write new values to the volatile trim registers  as often as they want with no IC degradation.

A good example of this is a component that is the "ILO Trim".  This component will attempt to trim ILO on-fly to hopefully minimize the frequency tolerance if left with the original trim value.  This may be useful if the PSoC is going to exhibit large swings in temperature.

[bugkiller]

Hi @BiBi_1928986   @Len_CONSULTRON, first of all thank you guys for the such a detailed answer. My device has 2 separate mcu board and cypress board that I mensioned only do button process, remote control, display information etc. so it does not need EEPROM. In conclusion, I guess good to go? Thanks!

[Len_CONSULTRON]

BK,

I'd say that's true.