7 Replies Latest reply on Jun 2, 2017 6:14 AM by AnFa_301266

    PSoC 5 Reset Troubleshooting




      We're having trouble with a PSoC 5 based application apparently resetting under certain conditions.  The reset happens and is recovered from very quickly and we haven't been unable to determine the "chicken and egg" - did the PSoC somehow cause the reset or did something else the PSoC to reset e.g. brown out.


      Looking around the forum and web there seems to be a function that should allow us to retrieve the cause of the last low voltage reset which would maybe give us a clue as to what is happening -  CySysLvdGetInterruptSource() which is part of the cv_Boot component.


      The only reference I can find to this function anywhere is in relation to the PSoC 4.  Is it possible to use this or something similar on the PS0C 5 and, if so, could anybody point me in the right direction to find it and impliment it?


      Many thanks.

        • 1. Re: PSoC 5 Reset Troubleshooting

          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.


          Many thanks.

          • 2. Re: PSoC 5 Reset Troubleshooting

            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?


            Many thanks.

            • 3. Re: PSoC 5 Reset Troubleshooting

              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.

              • 4. Re: PSoC 5 Reset Troubleshooting

                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.

                • 5. Re: PSoC 5 Reset Troubleshooting

                  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?





                  • 6. Re: PSoC 5 Reset Troubleshooting

                    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.

                    • 7. Re: PSoC 5 Reset Troubleshooting

                      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.