By the way, I have found the "PSoC® Creator™ System Reference Guide cy_boot Component v4.0" which references the CySysLvdGetInterruptSource function and also the PSoC 5 and the "PSoC® 5LP Registers TRM" plus the attached extract which was included in the "Brownout detection PSoC 4" post but am still none the wiser as to how to access it from our project.
PSOC 4 Brownout.jpg 257.7 K
One more question. Is it possible to change the brown out threshold voltage or even disable it completely if it is safe to do so?
AFAIK internal and external read/write operations might get damaged due to low voltage levels. I would consider improving the hardware if having too much brown-out reset.
Thanks for the reply. We are not getting frequent processor resets, just under some certain circumstances some "event" or operational change is resetting the PSoC - we don't know if this is due to brown outs, this is what we're trying to establish. Under most running conditions the system runs without a problem. Once we have more information we can look to improve the hardware if necessary but need this information to understand the cause of the problem.
I guess, to ask the question a different way, can anybody suggest the best way to get information to determine the likely cause of the processor resetting? We are monitoring power lines with scopes etc but haven't so far been able to see anything that would potentially explain it - maybe a disturbance is occurring on one of the IO lines for example - could that create a reset condition?
Any thoughts would be appreciated ass we're running our of time to deliver our prototype system. Thanks.
Disturbances may come from external sensors / switches and power line of course.
So take the usual precautions: Shielded cables shield grounded on one side at point only.
Try using a battery supply.
Any pins unused but brought out of the board?
Are you able to run the project while debugging? set breakpoints at NMI and other critical interrupts.
LVD is a signal which you may connect to an interrupt using the Global Signal Reference component.
Are you using WDT?
Did you check the RESET_SR0 Register after reset? (PSoC 5LP Registers TRM, page 286)
During the boot process the content of this register is copied into the CyResetStatus variable for easy access.
Maybe tracing this variable into eeprom after boot can give you a hint.
Many thanks for all the information and suggestions.
Cables are all correctly shielded. Unfortunately the power supply to the system is 24V DC at 300W so not easy to use batteries without raiding a couple of our automobiles (cars to us!).
We had just cut the tracks to a header "for future use" as they might be picking up, added additional PSU filtering. We finally put a shielding "can" over the PSoC and have now reduced the resets to the last 5% of maximum power so almost there. With these changes properly implemented in a reworked PCB we hope that it will fully resolve the problem.
However, we would still like to understand what is happening when it resets - thanks for pointing out the "Global Signal Reference" component - we hadn't even realized that was there so will look at the dropout information from that. Additionally, we'll check out the RESET_SR0 register and see what we can learn from that.
Learnt a lot here, thanks.