Boot cause due to battery change

[KlJe_3653291]

we use a battery powered BLE 4100. PSoC4.

how can we detect if bootup due to battery change?

can we detect if boot cause is due to software reset or watchdog reset?

if no chip registers can we use onchip RAM in none init section and set this to magic value and check if values is the same then RAM has not been cleared and bootup cause is due to battery change.

if bootup cause is battery change we want to clear some child lock setting in NVM but this cannot be cleared if bootup due to software reset or watchdog reset.

[wcc3]

I'm looking at rev C of the PSoC 4 BLE Architecture Technical Reference Manual (document #001-92738).  In section 13.2, there's a long discussion about distinguishing reset sources.  The WDT and software resets are distinguished by bits in the RES_CAUSE register.

https://www.cypress.com/file/137266/download

[KlJe_3653291]

Yes but this does not give me a way to find the boot cause of battery change, in this case the boot cause is not software reset or watchdog reset

[wcc3 · Accepted solution]

I presume you have no other way of supporting the power bus while the batteries are out.

In that case, you're going to get either POR or a non-retention BOR.  Those fall under the clause "These resets cannot be distinguished using on-chip resources."

You distinguish those by their being none of the ones that you can distinguish.

First, check for RES_CAUSE != 0.  In this case, we have a software reset, protection fault reset, or watchdog reset.  The bits in RES_CAUSE will tell you which one.

Next, check the condition of the I/O devices that might have awakened you.  A POR or non-retention BOR will leave the bits that configure those in their reset state (i.e. not configured to cause an interrupt) whereas a Hibernate wake-up will leave them the way you set them.  If they're the way you set them, we have a Hibernate wake-up.

Next, check for a retention BOR by running the following sequence described in the Register TRM:

1. uint16_t oldKey = PWR_BOD_KEY;
2. PWR_BOD_KEY = 0x3A71;
3. if (oldKey == 0x3A71) { <We have a retention BOR.> }

If we haven't found any of the above resets, presume we lost power and act accordingly.

If you don't actually need to distinguish the various resets from the presumption of lost power, I think the check on the PWR_BOD_KEY register would be enough.  The software, fault, watchdog, and Hibernate wake-up resets do not (if I recall correctly) upset the PWR_BOD_KEY register.  Thus, if you skip the first two checks and go directly to the third, you may get the result you want.

[KlJe_3653291]

Thanks, check of the PWR_BOD_KEY register looks to do the job 🙂