Personal(Meaning me, JT, NOT to disregard present engineering efforts) Debug Approach:
- Is a reset observed when running the example Apps?
- What changes, if any, have been done to the example App (Connection Period, Scan Interval, etc.) if one was used as a reference?
- Are the resets periodic?
- Can an "abridged" version of the Trace Output be produced for an in-depth analysis? What messges are being produced?
- Is a Frontline Sniffer available to see if the Advertisements, Connections and associated packets being received and transmitted are what is expected?
In an earlier message, you mentioned you were using a Timer:
- Is the reset observed if the timer function is removed?
I can add to my list here, but I wanted some feedback from you.
Thank you for the suggestions.
The resets appeared to be happening at a time when nothing much was going on (no unusual trace messages), but it could possibly have been coincident with the fine timer callback.
It's entirely possible that the cause is a hardware issue - my test hardware is cobbled together and has a lot of dangling wires. Monday I will have properly manufactured boards to test, so I will hold off on further investigation until then. (Also because I seem to have broken my hardware just now .. )
If it persists with the new boards, I will do some more investigation and get back to you.
JT- My new hardware no longer suffers from reset problems -- most likely it was caused by flaky wiring.
Thanks for the suggestions!
These issues are not resolved yet.
Figuring out how to put it into sleep mode is the biggest issue for me right now — ideally using the lower power 32k crystal to get the best performance?
Right now I am seeing 50-60 microamps in my idle state, and i would really like to cut this down to 25 or less.
I don’t think I have yet been able to put it into sleep or deep sleep, and i’m not sure how to do it.