UPS switch time is ~40 Milliseconds (NOT 40 Seconds).
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.
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).
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.
Power Loss and Brownout2.doc 33.0 K
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 = (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.Bruce
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.
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.
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.
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.
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 = (uint16) CyResetStatus; <--- Note the use of an explicit array index which is something I avoidwhen 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 allocationCyLib.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.
Have a look into the "System Reference Guide" which you may access from help-menu, but I cannot tell the exact location in Creator 2.0. There is a chapter regarding "Preservation of Reset Status" (which hopefully does not differ much from Creator 3.0).
the "System Reference Guide" is where I learned about CyResetStatus.
but I suspect that there exists conditions where CyResetStatus is not showing the Reset Reason.
All my indications point to an intermittant Reset occurring. I have given much thought to as what else could be causing many variables being reset to the condition that exists following a POR. Some indications are not discernable due to the periodic ADC restoring many variables; but there are plenty of indications that the remaining variables are being reset.
I had a utility power glitch yesterday while on my computer that my PC's UPS announced; but a check of the PSoC3 did not exibit any variables being reset. Maybe just a "streak of one" but there seems to be some evidence that it is not an LVI reset problem. Have been unable to find a correlation of external events with the resets. Ordered some 9v Lithium batteries to see if their increased capacity will have an effect (the 12v power internal contacts are jumpered so that the battery acts as a short-term solution to power outages), expect delivery soon so further evidence may be available.
Looking through the Keil C to Assembler interface documents helps me to barely begin to understand that interface, The section on Globals sheds some light on how that interface works. It details the EXTERN purpose and some caveats about Type definition requirements. There is a confusing explanation of where an external reference does not require an EXTERN but requires an Assembler Declaration (possible Stack or Register linkage??), I think the _CyResetInduced falls into this category but I can't find the Assembler Declaration for it; could this lead to CyResetStatus being incorrect as a result. It appears that _CyResetInduced is Legacy code and is no longer used but still at least partially remaining in the assembler code.
I don't have any desire to become a Keil expert, just want to get on with my project. Early on in my project, I looked at the Keil C and Assembler hookup; at that time I decided that I would avoid Assembler if at all possible. I don't even know if this is the cause of not reporting my intermittant resets, but I am reaching a dead-end on finding something wrong in my C code; I have commented out all my code that even remotely could cause a reset without stopping them.
I am VERY appreciative of the help I have received on this Forum. Please keep it coming,
to get to the "right" side I would suggest you to:
-Get a PSoC3 that is not ES silicon.
-Download and install Creator 3.0 (it is co-existent with 2.0)
-copy and update your current project to latest component (Be warned, you cannot go back to pre-3.0 projects, so have a copy!!!)
-compare your supply design to the "Typical Applications" chapter of a power-supply vendor: www.mornsun-power.com/public/channel/ACDC/LS/LS03-R2S.pdf
Can you post your complete project, so that we all can have a look at all of your settings? To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.
The chip is part of the CY8CKIT030 and I believe it is NOT ES3. The Chip type is specified as PSoC3 Production. It is only in the Generated Source that it is equated to PSoC3_ES3 because Creator 2.0 does not have a PSoC3_Production designation. Changing 100 "pin" Surface Mount devices is outside of my capability.
Creator 3.0. I will download it over my Rural Snail DSL Internet connection. Appreciate the make a copy advice.
My project is rather large:
Flash used: 40290 of 65536 bytes (61.5 %).
SRAM used: 2190 of 8192 bytes (26.7 %).
For ease in maintaining, I have 20 Source Files based on a functional breakout.
It is not entirely self contained. Shares a Windows file for Enum definitions with th PC VB.Net application as a means of keeping noth synchronized.
It is littered with copious comments. Many were copied from the DataSheets. Some of mine may be obsolete or worse yet be erroneous (the TRUTH is in the code, not in the Comments!).
I am just in the process of replacing the CYFISNP Radio with a BlueTooth Radio (separate Project). Had to delete the CYFISNP I2C to make room for the BlueTooth UART. So it is about at the maximum number of blocks.
I think my DSL would take a long time to transmit and I am not sure that my Internet supplier would allow such tranmission size.
Besides I want to continue to treat it as confidential. Represents a large amount of work on my part. Hate to think about a "Non-Disclosure" agreement.
Not to mention the "Learning Curve" on your part.
Got the 9v Lithium backup battery today and installed it.
Creator 3.0 may take a while to download, install, and test a copy of my project. I will persue 3.0. I will also take an opportunity to run WinMerge against the KeilStart.a versions (2.0 vs. 3.0) to see if there might be an obvious difference.