Unable to find/cure intermittant PSoC3 Reset Cause

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

cross mob
Anonymous
Not applicable

 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.

0 Likes
60 Replies
Anonymous
Not applicable

 ERRATA

   

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

0 Likes
Anonymous
Not applicable

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.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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).

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
Anonymous
Not applicable

 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.   
   
        
   
    Bruce   
0 Likes
Anonymous
Not applicable

 Dana,

   

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.

   

Bruce

0 Likes
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

   

 

   

0 Likes
Anonymous
Not applicable

 Dana,

   

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.

   

Thanks,

   

Bruce

0 Likes
Anonymous
Not applicable

 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.    
    
          
   
   
        
   
        
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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).

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 Bob,

   

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,

   

Bruce

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Bruce,

   

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. 

   

Bob
 

0 Likes
Anonymous
Not applicable

 Bob,

   

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.

   

Thanks,

   

Bruce

0 Likes
Anonymous
Not applicable

 Bob,

   

Installed Creator 3.0 and compared the CyResetStatus code and found no difference from Creator 2. Testing is not yet complete to know what 3.0 does.

   

Changed the 9v Alkaline Backup battery on the CY8CKIT030 to a Lithium (1000 mAh) 4 days ago and have not experienced a Reset since (24 Hours was typically long enough to see a Reset). Conclusion; the Reset is most likely a power drop cause.

   

Why does'nt CyResetStatus report a LVIx cause? I believe I have the answer to that conundrum.

   

Keil Assembler and C compiler are hiding the reason.

   

If the Assembler would report a warning or an error when a mov DPTR uses a uninitialized address, then this problem would have been noted during assembly of KeilStart.a. Instead it generates an address of 0000. So CyResetStatus is being saved, but to the start of SRAM (One of my variables is stored there). An examination of KeilStart.lst will confirm this is the situation (Very considerate of someone to include the Source along with the Object code it produces).

   

Keil C Compiler does not complain when it sees what CyLib.c and CyLib.h have coded. The compiler creates a condition where a 'Project'.map entry is generated; this seems to indicate an instantiation has occurred. But I believe it is an incomplete instantiation because the EXTERN in KeilStart.a does not produce an address for CyResetStatus.

   

Keil Help a51 Global Variables gives some insight as to what is required of a C Global Variable for use by an assembly routine. It requires that the Module that Declares a Global Variable must include an instantiation in that Module (I tried to do the instantion in one of my modules but the 0000 address was unchanged). This is not being done explicitly in CyLib.c.

   

I now have a workaround by Declaring a "MyResetStatus" C variable with an  "_at 0x1FFF" (an 8k SRAM Chip) that references the _CyResetStatus variable.

   

And I will continue to improve my 12v Wall Power Pulse Power Supply and Vin storage capacity.

   

Bruce

0 Likes
Anonymous
Not applicable

 A followup.

   

Stil have not been able to get a ResetReason based answer.

   

Have added more VDDA and VDDD and VIN filters but the resets continue sporadically.

   

Lucked out and saw a reset happen when I heard a 2HP capacitor start motor shut down in the system. Don't know if the probable EMI was caused by the motor or the contactor shutdown. They are both in a metal enclosure with the "embedded" PSoC3 unit outside; however multiple sensor leads connect the PSoC3 with internal points.

   

I have added split Ferrite cores over the sensor leads. I did not have enough to do all of the leads, so I used the on-hand cores for the leads that did not have level-changing circuitry. Have gone 6 days without a reset. I just received additional ferrite cores and will complete the job. 

   

Reading Cypress PSoC documents about ESD and EMI seems to indicate these are damaging situations. But my experience with probable EMI shows that no damage is occurring, only a reset. I saw where filling unused program flash with NOP's is a recommendation. The NOP has an opcode of 0x00, isn't unused program flash all zeroes?

   

Would an EMI event that caused a transfer to unused program flash and executing NOP's finally wrap to location 0 and look like a reset has occurred? And go unreported?

0 Likes
Anonymous
Not applicable

 Don't know if a possible EMI event is happening and causing a NOP wrap, but I think I have a method to detect if main() is being accesed more than once.

   

Detecting a second execution of main() is clouded by the normal Component Initialization (user code) that occurs following a POR. All reporting variables are wiped out and the difference between a Reset and a second main() execution can not be determined. I may not be experiencing a Reset.

   

SRAM holds the key to the test. A Reset will clear SRAM. An inadvertant entry to main() will not clear SRAM.

   

A NOP Wrap or inadvertant entry would run main() the second time. It will not exercise the SRAM clear functions and thus will leave a SRAM Semaphore set. By setting the Semaphore the first time through main() as a result of a POR (or other Reset), and testing it as part of main(), it is posible to detect if this time through is as a result of main() running from a POR or as a result of a wrap (OR a program bug). Reporting the contents of the semaphore to my VB.Net PC program will provide the answer. 

   

Further, if a second main() execution is occurring, the Component Initialization can be bypassed which would allow resuming normal program flow. The Stack will contain remnants but I think this is not a show stopper. It can't be a frequent event.

   

The code has been updated and is running in the system. With only a few hours of running, no "reset" has been detected. Time will tell if this scenerio is a correct one.

   

May need to remove the Ferrite cores to allow a possible EMI event to get to the PSoC3.

0 Likes
Anonymous
Not applicable

 Got another "apparent" Reset. Ferrite cores are not the panacea.

   

The Semaphore described previously indicates that SRAM has been cleared. Thus the "apparent" Reset is a real Reset.

   

CyResetStatus and my MyResetStatus are still failing to report the reason.

   

Went back to my older Creator 2.0 project and noted that CyLib.c meets the Keil C to Assembler variable passing via an extern is satisfied. CyLib.c version 2.21 both declares and instantiates the CyResetStarus variable using an _at_ to the top of SRAM. Keil includes the requirement for a C program to Assembler call but this variable pass is started in the other direction; don't know if this is significant. Both CyLib.c and KeilStart.a51 have changes regarding CyResetStatus.

   

I have a 1 second While main procesing loop based on a 32K XTAL incrementing a semaphore. Incrementing so that if the loop takes longer than 1 second, a flag can be set and reported. I have never witnessed that flag being set. I also have a idle counter in said loop and it is indicating that there is sufficient computer capacity to satisfy my processing requirement. This loop includes a WDT Service call as do some of the longer routines that it invokes. If the WDT is the culprit, and ..ResetStatus is not reporting it, I have turned off the 1024Tick WDT and will wait and observe. With the WDT documentation indicating 2 to 3 second trip point, and my loop problem detection code, I did not expect that the WDT could be tripping. Reading further on ILO tolerance indicates that the WDT could trip at as low as 1 second. If this is the case, it would have been found sooner if the WDT documentation included the ILO tolerance.

   

An intermittant SRAM clearing Reset is definitely a show stopper. Controls based on counters and Real Time Clocks are destroyed by being cleared.

0 Likes
Anonymous
Not applicable

Not sure if you have already check that but the “RESET” problem can also be

   
     1.       Stack overflow   
   
     2.       Code called during main and interrupt but not being declared as re-entrant   
   
     3.       Out of range array index   
   
     4.       Null pointer or incorrectly loaded pointer value   
0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

A quick check on sensor lines is set up a DSO to single trigger and

   

set trigger of all channels as OR and to a level > Vdd, then < Vss,

   

the latter being more problematic I think. Thats where loose charge

   

gets injected into substrate and where it goes nobody knows but

   

random logic gets triggered.

   

 

   

Some layout techniques attached when you go to layout.

   

 

   

www.ti.com/general/docs/lit/getliterature.tsp

   

www.analog.com/en/data-conversion-knowledge-resource/grounding-pcb-layout/conversions/resources.html

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

Can't find what a DSO is. I assume it is a component; but even searching the component catalog says no find. Also, I may be at the component limit, had to remove an I2C to add a UART when changing radio link to Bluetooth. Couldn't run 2 varieties of radio links; became an exclusive OR.

   

H L, 

   

Give me some guidance on running down the 4 Reset items you reference. Some background:

   

1. Stack Overflow. Can I rely on the reported SRAM usage number? When I first started trying to run down this problem with Creator 2.0 the compile yielded "SRAM used: 2190 of 8192 bytes (26.7 %)." Today under Creator 3.0 SP2 the compile

   

yielded "SRAM used: 8236 of 8192 bytes (100.5 %).". This sure looks like the proverbial Blivet if it is true. Using

   

Debug of a running target, xdata shows all Zeroes from =x08c0 to almost the top of the 0x1FFF SRAM. So Stack

   

Overflow seems hardly possible. I have only witnessed the stack showing only a small number of entries. 

   

2. Re-entrant code not declared. I don't use any Assembler routines, only C. I am not aware of writing C re-entrant code.

   

3. Array Index. I am aware of the less than robust C support for arrays. So I use Enums to define array subscripts rather than use explicit numeric subscripts. Each Enum definition includes a ending "...Length Of" for use in places such as For Loops. So I don't think this condition will occur.

   

4. Null or incorrect pointer. Two places where I use pointers. EEPROM which is only used on startup to load Control parameters. UART Buffers that are used at least once per second and operate without any visual indication of bad data being transmitted. The reset problem sometimes takes days to have one occur.

   

I appreciate all the help, even that which ends up at an apparent dead-end.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

DSO = Digital Storage Oscilloscope

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Dana,

   

Nope don't have a DSO. Suspect I can't afford one. I am a Sole Propriatorship consulting firm with limited resources.

   

Right now I wish I did!

   

Bruce

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Each function in your code that might be called from an interrupt handler and from other places of the code need to be re-entrant. This is not a specific thing for assembler. I think you should get a warning by the compiler if that happens, though.

   

I think in the design-wide resources there is a place where you can configure the heapsize (and maybe the stack as well). Maybe use that.

   

Is there a chance you can test your project with the same input, but in a place were there is not so much EMI?

   

Btw: a simple Rigol DS1052E DSO is less than 350USD, so thats not so expensive (and if you look over at the EEVBlog and use the search there, you might be in for a surprise regarding its features).

0 Likes
Anonymous
Not applicable

1. If you are using PSoC3 which is 8051 core, you can only use the idata area(256 byte) for stack. However cannot remember if Keil does use soft stack or not.

   

2. it is nothing to do with assemeber or not, as long as there are chances the same function being called at the same time more than once, it needs to be re-entrant. ( That apply to multi-tasking system or program with interrupt functions), on most newer CPU that has large RAM size for stack, normally the compiler would make all functions re-entant automatially. But not for 8051 core., you need to specify that your self. But as hli point out, there should be warning if that happened.

   

3 and 4. May be use assert in the function for those protential issues?

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

An alternative to a DSO is to use a simple circuit, a fast comparator with a

   

latched output. It has to run on split supplies to handle < Vss transients.

   

Tie the comparator output to an LED or whatever, set comparator ref input

   

to ~ - .1 V, the other to the pin, and see if it captures anything on the pin.

   

 

   

Its also possible to use an older analog scope, set up trigger to ~ -1V, normal

   

trigger (not auto) and use scope trigger out at back of scope to clock a "D" to a "1".

   

"D" can be another PSOC board, or just plain old TTL. If scope trigger out not TTL

   

compatible, most of the time just use a few K ohm series R to "D" to make it work.

   

 

   

Where theres a will theres a way.....:)

   

 

   

Need a cheap logic analyzer, I bought two of these, they work great. Just beware

   

there is no input protection on inputs, so some users (me as well when I get around

   

to it) build a simple R with 2 protection diodes on a seperate breadboard. This is just

   

one of many links on ebay -

   

 

   

www.ebay.com/itm/Compatible-With-Saleae-USB-Logic-24MHz-8-Channel-Logic-Analyzer-/351142868115

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

 Stack. I use a simple hierarchy of calls. Don't have the possibility of the need for re-entrant code. The most I go on calls is a total of 5. With 4 on the stack during a debug, i see zeroes starting in idata at 0x40 (64 decimal) so the stack should not be the problem. Thanks for the idata info.

   

 

   

I only use interrupts to set semaphores. 

   

 

   

There is the possibility that there are multiple causes for the reset. When shooting intermittents, I have previously tried at most two tests at a time. If there is no cure, I re-instate the code that was being tested; then move on to another suspect area. Intermittants are the hardest things to find. Even harder when there are multiple causes; for this reason I have started to retest some suspects.

   

 

   

WDT is one that I dismissed as not a problem which I then turned back on. If I could trust CyResetStatus I would continue to dismiss WDT. But I am now re-visiting WDT. ILO, and the trimming of ILO, is very significant for the WDT. My code which analyzes the amount of idle time in my 1 second MainLoop and tests if the 1 second semaphore is not being serviced each second had biased me to thinking that the 1024tick WDT could never be the problem. But, if ILO is not trimmed, the WDT could bite in as short as 0.6 seconds. I can find trimming of IMO in the Generated Code but I can't find where ILO is trimmed.

   

 

   

Three days ago I again commented out starting the WDT. While this is shorter than some of the reset occurrances, it is encouraging that no resets have shown their "ugly faces".

   

 

   

Still thankful for the help,

   

Bruce

0 Likes
Anonymous
Not applicable

There is an ILO Trim system component. That may help. 

0 Likes
Anonymous
Not applicable

 To all that have stayed with my "Rants",

   

I just had the EUREKA Event.

   

With the WDT not activated for 3+ days, my 1 Second trap was just sprung. This indicates that my MainLoop was unable to complete the necessary processing when 2 32KXTAL semaphores were set. The semaphore is an incrementing semaphore and is asynchronous to the mechanisms that my project is all about. The MainLoop 1 second trap tests if it is ever at a count greater than 1. The semaphore causes the MainLoop workload to increase for the Control portion of my project and accounts for my not being able to find this bug during bench testing that does not fully simulate varying workloads.

   

The sprung trap took 3+ days this time to trip. Talk about an intermittent!

   

The conclusion I have drawn can only come about if you ignore the 1024Tick WDT with its async 2 to 3 times around equates to ~2 to 3 seconds. I believe it to be much less than that.

   

The conclusion is that the WDT is the cause of the resets. If the WDT was tripping at just under 1 second and the processing loop was only occaisionally taking just in excess of 1 second, then rather than trip my trap, the WDT would bite first. Under these conditions my 1 second trap was effectively useless with a running WDT.

   

Do I have a second reset cause? Time will tell.

   

If only CyResetStatus was working correctly, this nightmare could have been avoided. I have a MyCase on the CyResetStatus that I hope leads to it being fixed.

   

And thanks to HL for the ILO trim suggestion. With no ILO dependency in my project, I am not inclined to trim the ILO for a WDT; detecting "infinite" loops is not currently on my priority list.

   

THANKS TO ALL,

   

Bruce

0 Likes
Anonymous
Not applicable

 There is still another Reset cause.

   

Overnight another reset happened. WDT is still off. All the other remedies that have been tried are still in place; filters, backup battery, UPS, Ferrite cores.

   

I have spent some more time on trying to get my eyes on the value of CyResetStatus. Knowing (I think) that KeilStart.a51 is saving CyResetStatus to address 0x0000, I found that unless this address is prevented from being assigned to one of my explicitly  initialized variables, it will be overlaid during the execution of the plain vanilla Keil INIT.A51. To assure that address 0x0000 is not overlaid I have added the following line of C declarations (void of explicit initialization) and with comments:

   

 

   

uint8 xdata MyResetStatus _at_  0x0000; // This is where KeilStart.a51 is storing the CyResetStatus Byte

   

// This prevents the memory allocation of 0x0000 from being assigned to one of my other variables.

   

// Since Keil Vanilla INIT.A51 is used for variable initialization AND it does NOT initialize variables that are not

   

// explicitly initialized in the C code, this should make the ResetStatus available. I HOPE!!

   

 

   

Now I am wishing for a quick re-occurrance of a Reset.

   

Stay Tuned,

   

Bruce

0 Likes
Anonymous
Not applicable

Some compilers would ignore the declartion of variable if it was not being  referenced by the code. Check that it do not being removed.

0 Likes
Anonymous
Not applicable

 I checked the MyResetStatus with Debug and found the memory allocation at 0x0000. Keil does not complain.

   

Status: No Reset overnight. When you want a reset, it takes its own time to happen. 

   

Bruce

0 Likes
Anonymous
Not applicable

 Well it took 4+ days for another reset. I conclude it as a POR due to some power glitch. Some of my sensors are vendor supplied and require 5v excitation; possibly one of these is shorting the 5v source (currently VDDA). A shorting test of the CY8CKIT-030 shows that VDDA and V5.0v cause a reset but for some reason VDDD does not. All voltage regulators are short tolerant.

   

 

   

MyCase  and my reply to tech support on this problem. I think I have learned more about resets than I really wanted to, but the conclusions could be useful to the developer community. Therefore I am including it here. (Can't find how to get more readable cut and paste text.)

   

 

   

From the Architectural Manual (AM):
software reset A partial reset executed by software to bring part of the system back to a known state. A software reset will restore the M8CP to a know state but not PSoC blocks, systems, peripherals, or registers. For a software reset, the CPU registers (CPU_A, CPU_F, CPU_PC, CPU_SP, and CPU_X) are set to 0x00. Therefore, code execution will begin at flash address 0x0000.

   


hardware reset A reset that is caused by a circuit, such as a POR, watchdog reset, or external reset. A hardware reset restores the state of the device as it was when it was first powered up. Therefore, all registers are set to the POR value as indicated in register tables throughout this document.

   


So there are two different types of resets and the actions they impose.

   


From the Creator System Reference Manual (CSRM):
The value of the reset status register (RESET_SR0) is read and cleared any time the device is booted. That value is saved to a global SRAM variable. Note that the IPOR, PRES, and LVI reset sources clear the RESET_SR0 register, and the WDT, Software reset and XRES reset sources preserve the RESET_SR0 register

   

.
With only the CRSM definition, the conclusion is what you describe. The second portion of the third “run-on” sentence of the CSRM is the cause. The Tech Writer for that sentence is correct but it is incomplete and misleading. And is what caused me to do further research since I could not understand the reasoning behind CyResetStatus

   

.
How I interpret the two manuals combined:
If you split the third sentence and add the reason why each section happens, here is how the AM would add clarification:

   


1. “Note that the IPOR, PRES, and LVI reset sources clear the RESET_SR0 register,” this is as the result of the hardware reset which clears the registers. And this calls KeilStarta51 et. al. in the process. The purpose of CyResetStatus saving in KeilStarta.51 is to make the value of RESET_CR0 available to the user after main() is restarted. Otherwise the user is left to after having turned on LVI, LVD, etc. is hung out to dry because Creator will not say why a reset has occurred.

   


2. “and the WDT, Software reset and XRES reset sources preserve the RESET_SR0 register.” is as a result of the registers NOT being cleared by a Software reset. Essentially the software reset is a slightly modified jump to 0x000 (main). No cyfitter_cfg.c, no KeilStart.a51, nor INIT.A51.

   


Since main() user code normally starts out initializing the Components, in the case of a software reset the Components are still what they were prior to the software reset and do not need initialization. A hardware reset does need Component initialization.

   


Therefore two reset tests are required. RESET_CR0 and CyResetStatus (depending on the cause). And because POR has no bit assigned, the sequence of the tests is important. First test RESET_SR0 for a software reset, if not then test CyResetStatus for a non-POR reset (CyResetStatus not zero). The less-than-robust POR test is when it is not a software reset and CyResetStatus is zero, then it was a POR hardware reset (ASSUMING YOU CAN TRUST CyResetStatus). I cast my vote for a robust POR test.

   


So I again ask you to look at the Code in KeilStart.lst and see what address it has for CyResetStatus. My Creator 3.0 SP2 shows no address in the address table and shows 0000 in the instruction. A C variable Extern in Assembler requires both a declaration and an instantiation but not an initialization. An address from the instantiation and not initialization so INIT.A51 does not wipe it out. Go back and look at CyLib.c ver 2.21 for what I believe is a correct entry for CyResetStatus.

   


I need a working CyResetStatus.
Bruce

   
    
   
0 Likes
Anonymous
Not applicable

 I forgot to mke reference to AN6016 and the section identifying reset sources. 

   

I believe it to to be incorrect to identifying soft reset sources and therefore to be incorrect as to the conclusions.

   

I am reminded of a project manager of a monstrous project in the 1960's who had a plaque on his wall. It read:

   

THE TRUTH IS IN THE CODE

   

     AS THE MACHINE READS IT!

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

 One of these days I hope to be able to get past the Reset saga. But....

   

AN6016 should read AN60166.

   

A test of pressing the XRES button on the CY8CKIT-030 shows that SRAM is being cleared. Thus XRES is a HARDWARE Reset, not a Software Reset as documented. More documentation that is currently incorrect but may have been correct at the time of writing. The problem of software updates w/o documentation updates may be the cause; a difficult nut to crack since two different groups are usually involved. The truth is in the code!

   

After reworking my main(), I thought passing it on might be helpful. It is attached. The Confidential Statement can be disregarded; it is standard boilerplate and main() does not disclose any project confidential code.

   

Cheers,

   

Bruce

0 Likes
Anonymous
Not applicable

 Errata deja vu!

   

If you download the main(), change setting my robust POR indicator with 0x0100.

   

Found my error when I tried to interpret the value with my PC program.

   

Bruce

0 Likes
Anonymous
Not applicable

 An update.

   

 

   

Putting current limiting resistors in the external 5v sensor excitation did not stop the resets. Current is now limited to under 100 Ma if the sensor presents a short; the CY8CKIT-030 voltage regulators will not shut down if they are working correctly.

   

 

   

The shorting tests that I ran with the LVI's turned on (4.71v) did not provide other than an implicit POR status. The CY8CKIT-030 when run only on USB power constantly trips the LVI's; but because of the constant resets the status cannot be determined. There is no capability to vary the Kit voltages and I conclude that a PRES takes precedence over the LVI's when running the short tests.    ( VDDD short does cause a reset; my prior conclusion was due to an "operator error".) The LVI code took some time to figure out, so I include it here to make it available to others:

   

CY_SET_REG8(CYDEV_RESET_CR3,0x00); // PREVENT THE GLITCH

   

CY_SET_REG8(CYDEV_RESET_CR1,0x07); // enables HVIA, LVIA, and LVID can cause GLITCH

   

CY_SET_REG8(CYDEV_RESET_CR0,0xCC); // Set the LVIA and LVID Trip levels to 4.71v (1.71 + (12 * 0.250V))

   

CY_SET_REG8(CYDEV_RESET_CR3,0xC0); // and make them a reset via the PRESx path

   
        
   

After learning how to temporarily modify Generated Code (AN60616), I tried adding an "_at_ 0x0001" to CyLib.c to see if KeilStart.a51 would have an address value. NO! So the CyResetStatus fix is not so simple. (And yes the CyLib.c user mod was not overridden.)

   

 

   

Am looking at DSO's. I think the Hantek DSO5102BM is my choice. Anybody care to comment?

   

 

   

Bruce

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

A Rigol DS1054Z might be interesting. Compared with the Hantek it has 4 channels and up to 24M memory.

0 Likes
Anonymous
Not applicable

 hli, hello again,

   

Thanks for the tip. Looked at the Rigel.

   

+    4 probe     but don't have an immediate need for 4 probes        does provide a spare input if one goes bad

   

++  24 Mb      however I think the 2 MB is OK      don't forsee needing long captures in the near future

   

+-   Screen size now same as Hantek          previous size was a drawback

   

--    50MHz    limits max frequency due to Nyquist effect           with 4 probes this equates to 12.5 MHz per

   

-     $             a limited budget

   

I believe the Hantek 100MHz and 2MB and 2 probes remains my choice.

   

Thanks for the tip anyway,

   

Bruce

0 Likes