You are here

Unable to find/cure intermittant PSoC3 Reset Cause | Cypress Semiconductor

Unable to find/cure intermittant PSoC3 Reset Cause

Summary: 59 Replies, Latest post by SequoiaCPE on 11 Dec 2014 01:36 PM PST
Verified Answers: 0
Last post
Log in to post new comments.
user_51922177's picture
109 posts

 Using CT8CKIT030 for development purpose.

Getting an intermittant Reset that is not as a result of my code (working with defaults) and experiencing variables being set to values which indicate a Reset has occurred.

CyResetStatus returns all zeroes. Understand that a PRES is not included in the CyResetStatus save; thus a PRES is the probable culprit.

Using an ADC DeltaSig which turns on PRES. I have an external 4096Vref that I monitor to provide an emperical correction of the ADC results and also use the Offset with a volts conversion to fine tune any variations (an oscilloscope shows Vdda has variation and I use the ADC Vdda to Vddd {set at 5 volts] to reduce granularity. So basically I don't feel that the ADC PRES activation is necessary in my case.

Steps taken:

WDT not activated (turned off my code). No change noted.

Next attempt was to also include a 9v battery with the wall power jack contacts jumpered to make the battery functional with the plug inserted. Results were inconclusive.

Next attempt was to include a UPS to prevent utility power glitches to not cause a Reset (UPS was capable of backing up a small load and should switch in ~40 seconds). Results were encouraging but not a total success.

Latest attempt was to add a 47ufd 50v ceramic cap to Vin on an external board. This showed the most improvement but was not 100% effective.

Can the 5v Vdda and/or Vddd also have a filter capacitor added ala the Vin cap?

All sugestions for a resolution are wecome.

I can not live with my system occaisionally Resetting as it is a Data Acquisition AND Control project.

user_51922177's picture
109 posts


UPS switch time is ~40 Milliseconds (NOT 40 Seconds).

user_51922177's picture
109 posts

A follow-up.

Chip is PSoC3 with ES3 (Production) as confirmed by Generated Source code inspection.

Further testing shows the following with Debugging a test unit on the bench:

   RESET_CR3 does show 0x80 which confirms ADC is setting PRESA (Analog). (Curious as to why ADC does this PRESA?)

   RESET_CR1 shows 0x00 which indicates no LVI is enabled thus the PRESA setting appears to have no effect

Helps to clarify but does not help solve the problem. Apparently PRES is not the culprit. Nor LVI A or D.

The apparent Reset symptoms are many Data Acquisition variables are being set to 0 which is normal after a POR. Code inspection does not reveal other than normal variable updating; some variables are ADC outputs and others are Timer and/or Counter outputs. ADC output values undergo "Sanity" checks before updating any variables so that Control functions do not operate with bad data.

I am unable to reproduce the problem on the bench. The apparent Reset occurs infrequently, sometimes not occurring within a 24 hour time period. My site is located in a utility "challenged" location with a few power glitches per week, which seems to be the root cause of the problem. Finding a project fix is necessary since the system is used typically in rural areas.  The Vin filter capacitor addition seems to support a power induced Reset.

user_1377889's picture
10803 posts

esigning a stable power supply is not my usual job, but a varistor and an L at the high yoltage side and a zener at the low voltage side could damp a lot of peaks. More complicate but helpful coul be a brown-ot detector and some management to save the data (eeprom).


Afaik the ES-silicone is "Engeneering Sample" and ought to be replaced with production silicone. This will additionally allow to use a more actual version of Creator (3.0) and updated components (less errors).



user_14586677's picture
7648 posts





Power lines are pretty nasty environments due to large motor transients.


You could add some diag code, use ADC to capture Vdd, and FLASH the result

in EEPROM to keep track of transients. Note use of larger caps on Vdd definitely

good idea. Polymer Tantalum best choice due to order of magnitude better Z vs

f ESR curves. Compared to ordinary tants.


To keep the processor running attached some info on calculating energy storage

or Vdd cap size.


Lastly other inputs can cause reset like behavior if transient takes input outside

supply rails. That’s because charge gets injected into substrate and where in the

die it gets picked back up can cause crazy behavior. Wherever possible terminate

with low Z so transient cannot introduce large V spikes.  This can also happen on

outputs, less likely because they are low Z.


Regards, Dana.

/* Style Definitions */
{mso-style-name:"Table Normal";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-fareast-font-family:"Times New Roman";

user_51922177's picture
109 posts

 Hello again Bob, Good to see you are still active. 

The Code is "Production" but the parm Test is based on >= which results in an CY_PSOC3_ES3 parm which is used in all of the generated source.

Yes I am using Creator 2.0 Component Pack 3. Have resisted on going to Creator 3 because 2.0 seemed to be all that I needed. I can be convinced to go to 3.0 if that is required to shoot this bug. 

As to the power variations and filtering, the VDDA and VDDD are all internal to the CY8CKIT030 and are thus only available to external filtering. Vin shows more variation than VDDA and VDDD which is one of the reasons of trying a filter there. I have added 0.1ufd ceramic caps to VDDA and VDDD but have not seen any improvements as a result.

If the problem is not a LVI problem, then external filtering of Vin may not be a good exhaustive test. May be a Red Herring.

Backing away from a power problem for a moment, I used the following to report CyResetStatus:

   extern uint8 CYXDATA CyResetStatus;

   DAQ_Vars[16] = (uint16) CyResetStatus;

   (DAQ_Vars is a uint16 Array that is reported to a PC based program every second via a radio link.)
Is this good code for CyResetStatus analysis?
It is the DAQ_Vars array contents that is showing reset variables that are indicative of the problem. Reported items such as RTC and Total RunTime Counters are the indicators (the PC program watches these and cause a "Back Channel" transmission to correct bad values; the back channel actions are logged with both bad data and replacement data events). But this is only available when the PC is up and the Application is running which rules out this as a workaround.
Been chasing this for quite a while, only when it pops up to the top of the priority list! It is TOP right now.
user_51922177's picture
109 posts


The 47ufd Vin filter cap is a Polymer Hybrid, I was thinking of the 0.1 that is ceramic.

I use the EEPROM for a Static storage of the projects controlling parameters. I think that updating an EEPROM once per second will sooner or later burn out the EEPROM. But I appreciate all possible remedies that I may otherwise overlook.

I am indirectly capturing VDDA with an external 4096Vref dedicated to calibrating the ADC periodically. It is reported to the PC each second so I can monitor it. However it has a 1 second granularity so it will not report most transients. Once a "Reset" has occurred, it is to late to do much about it.

I placed 0.1ufd ceramic caps on VDDA and VDDD to try to limit voltage transients. The CY8CKIT030 does not allow access to the chip pins except via the "long" PC traces so they may be less than fully effective.

The main ADC inputs are derived via thermistor constant current op-amps that use VDDA for power (a self compensating circuit whose output is dependent on VDDA as is the ADC). So they should not go outside of the rails. Also long thermistor leads are good antennas and I was trying to avoid noise by using op-amp differential inputs. Simpler thermistor circuits are available but don't have this level of noise and voltage immunity.

Dana, I hope you continue to think about this problem. You made me re-think my design.


user_14586677's picture
7648 posts

The OpAmps in PSOC used differentially are not capable of any fast

rejection of noise due to their low GBW and slew rate. In terms of a

power line application. Stated another way they act as a LPF which

does reject low speed transients, but cannot handle feed forward

fast type signals due to layout, stray C, routing.


You can get zener arrays from guys like ON Semi, Vishay, etc.. They have the

advantage that zeners operate in avalanche or zener mode and are very fast.

And typically they are dirtball cheap.


Attached is some ref material that may be of use.


Regards, Dana.


user_14586677's picture
7648 posts

The EEPROM is limited in erase/write cycles for sure, especially hot.

So yiou could manage this in code if you wanted to get an idea of how

noisey the environment it is in.


Regards, Dana.


user_51922177's picture
109 posts


You sure reply quick! Thanks.

I am using Microchip MCP6021 10 MHz Low Noise Rail-to-Rail op-amps that are on my Analog Input board. The R2R gets me a wider range of temperatures without sacrificing granularity. If it is determined that the analog thermistor circuits are the problem, there would be no significant impact by placing 0.1ufd ceramic caps accross the differential inputs right at the op-amps; no time delay problems are foreseen. There are more than 12 such circuits so testing is somewhat of a chore. And I am aware of the ADCMUX programming to avoid cross-talk noise.

EEPROM. I use EEPROM for my mostly static control parms. I load a RAM Array with these parms primarily for speed and to avoid EEPROM problems with constant access. After a POR or a Reset, when the RAM Array is found empty, an EEPROM read refreshes the RAM. I don't think this concept is applicable for normal RAM resident data backup because the normal RAM data is subject to change on a per second time basis. The ADC is run once per second as is the control code which uses mainly the ADC results.

FYI, the PC application is capable of modifying the control parms and the EEPROM is updated accordingly. Allows for changing the control process with changing conditions. The EEPROM is a MANDATORY component with my design. Could not function without it.



user_51922177's picture
109 posts

 A set of questions for Bob Marlow or anyone with expertise related to CyResetStatus.

I have started to focus on the possibility that my attempts to display the contents of CyResetStatus.

Some code snippets are included to help make my case that this is a possible reason for not finding the apparent Reset causes.

my code to retreive and transmit:

    extern uint8 CYXDATA CyResetStatus;

    DAQ_Vars[16] = (uint16) CyResetStatus;      <--- Note the use of an explicit array index which is something I avoid
when I tried to use an enum for an index, Creator 2.0 threw a fit! Something to the effect that the enum was not defined (can't remember exact message and surprisingly can no longer reproduce the message). I thought that the explicit workaround would suffice, so I assumed that CyResetStatus would be reported correctly. 
Re-visiting CyResetStatus I found a series of baffeling lines of code in the Generated Source. First is the CyLib.c and .h entries:
CyLib.c has   uint8 CYXDATA CyResetStatus;       a Declaration without an initialazation and probably without memory allocation
     CyLib.h has   extern uint8 CYXDATA CyResetStatus;
Neither members use CyResetStatus. Nor does any other C code (excluding mine) use or initializes CyResetStatus. However the .map shows that this xdata variable has been allocated (CYXDATA EQU xdata in CyTypes).
Looking further I found that KeikStart.a is where all the code resides. It contains the Following:
     EXTERN XDATA:BYTE (CyResetStatus)     My Keil knowledge is extremely limited but this appears to tell the Assembler that LinkEdit will resolve this. Without memory allocation this poses a quandry. There is also:
     _CyResetStatus  EQU     CYDEV_SRAM_SIZE - 1     A reference to the Stack Top down.
Before I noticed the _CyResetInduced code, I was left wondering that if the EXTERN was needed, then why was the Stack involved. Or vice versa. 
But _CyResetInduced caused me to be further confused.
     _CyResetInduced EQU     CYDEV_SRAM_SIZE - 2   without an EXTERN but .map shows that there is memory allocated. Nor is there any assembler declaration for this variable. More confusing was the fact that there is no C code Declaration for this C variable.
So I am left with a tentative conclusion that CyResetStatus is NOT being correctly reported. Thus my reporting that NO Reset Reason can be found is most likely misleading.


Log in to post new comments.