After experiencing Hard Resets due to EMI from an adjacent unit, I came to the realization that EMI Resets were going to be a difficult to eliminate. The CY8CKIT-030 was used for a development test bench; I hardly expected to do a better job of PCB design than Cypress engineers. And I would not be able to control the environment that the embedded PSoC3 would be installed in.
This thread focuses on trying to figure out how to "peacefully" co-exist with Resets, both Soft and Hard varieties.
Since there are two varieties of Resets, the first item is to determine the type currently occurring.
Resets of the Soft variety are easier to work with; they leave SRAM as is and the Components and Registers are not reset to DWR settings. User code is resumed at main(). The main Soft Reset is the WDT Reset. RESET_SR0 contains the identity since the Registers are not reset. But lacking in support is a means to determine where in your code the WDT tripped, and a count of how many have occurred. Because the Stack has no meaning, and the Soft Reset clears the CPU registers, "crawling" the Stack (if idata was left uncleared) could possibly answer where the WDT tripped. A count of WDT events could be a user responsibility; SRAM as a count repository is possible (but an intervening Hard Reset clears SRAM and the WDT count would be lost). The normal main() function of initializing Components should probably be skipped with a Soft Reset. If the problem section of code can be determined, then selective initialization may cure the WDT problem.
Hard Resets pose a significant challenge. The action to be taken is highly dependent on the functions that the PSoC3 is designed to make.
With SRAM clearing as an option on a startup reset, the tradeoff of fast startup versus using a Global Variable as an SRAM clearing semaphore should be evaluated. Yes, CyResetStatus could be used to see what type of Hard Reset occurred (I have done extensive research of CyResetStatus and conclude it is not currently working for PSoC3 with Creator 3.0 SP2). But if the reset is of the PRESx variety then a working CyResetStatus does not set a bit (I experienced bad enough EMI to cause a PRESx set with LVID and LVIA not activated).
The Hard reset SRAM semaphore works by declaring a Global Variable that is not initialized. The last thing main() does is set the variable to a one. On entry to main(), examination of the variable shows if SRAM was cleared and thus a Hard Reset has occurred. A POR or XRES will show a zero semaphore. If the semaphore still contains the one, a Soft reset occurred (assumes that SRAM Clear remains the option).
How to handle a Hard reset is the main consideration. I will explore what I am considering in followup posts. I am not sure with my particular project how to handle Hard resets. This thread is to solicit comments and suggestions which are welcomed.
Thanks for your interest,