Brown Out Indicator? or Register?

co tang87699 said:

Is there a way to determine what would cause a brown out? Does certain register get set first then the brown out kicks in?

Hmmmm...... that would be nice.

Jens-Michael Gross said:

YOu need the optional crystal orb module so you can see into the future.

Crystal orb module is very, very expensive part. We on earth make BOR foreseeing modules from comparator. If you have very slow supply fall time (battery discharge) you can simply use ADC measurements to foresee BOR coming.

Ilmars said:

Crystal orb module is very, very expensive part. We on earth make BOR foreseeing modules from comparator.

But back to the original question: Well if a brownout happened, it was (surprise!) due to a brownout. That means due to low supply voltage. Why the supply voltage was low cannot be detected.
There are two types of brownouts: If the brownout is caused by a slowly dying battery, then once it happens, the CPU is usually already crashed before and the system won't recover from it until the batery is changed. So a brownout is followed by a power-off and power-on. No way to detect anything after it happened. This type can be indeed detected by measuring hte supply voltage and shutting th esystem down properly long before the battery reaches critical limit.

The other type is a short drop of supply voltage. It can be cause by a temporary shortcut, an overload in some external peripheral, whatever. It happens unpredictably and you can only detect that it happened once it happened. No ADC surveillance will help predicting it.

Jens-Michael Gross said:

Which often turns the brownout detection into a self-fulfilling prophecy.

Why you so desperately concentrate on BOR alone :/

Sometimes it is necessary to make power-fail detection circuit together with back-up power storage like capacitor and corresponding software to save valuable data into NVRAM (flash of msp430 for instance). So, such circuit effectively will be "BOR foreseeing module" indeed. What's the problem?

Ilmars said:

Why you so desperately concentrate on BOR alone :/

Ilmars said:

So, such circuit effectively will be "BOR foreseeing module" indeed. What's the problem?

However, I wasn't concentrating, I was contrmplating about additional pitfalls.

Sorry can't tell whether these answers was heading into the woods or coming back to the road. The main problem is that the program I'm working on randomly reset itself. I'm currently looking at either hardware or software. I pointing more closely to software but I'm not sure hence these questions...

Can a stack overflow cause the CPU to reset randomly?

co tang87699 said:

...

Can a stack overflow cause the CPU to reset randomly?

Honestly right now, I'm at a total lost. I stripped my program down to port initialization and clock setup and have the main program running in a loop with Nop. It still randomly reboots. Now I'm thinking it not a software fault more likely a hardware fault. Not sure what it could be.

co tang87699 said:

I stripped my program down to port initialization and clock setup and have the main program running in a loop with Nop. It still randomly reboots.

btw: do you disable the watchdog? Or feed it in your endless loop?

I'm going to hack away at it some more, it going to ake sometime due to the randomness but I'll definitley post it once I exhausted all options.

I think I got it, I copper pour the top and bottom board but didn't assign it to any nets, meaning I should have grounded it. The whole PCB acted like an antenna and was picking up stray emi from the near by electronics and some how causing a brown out on the MCU. Tested overnight and not a single reset. Going to test some more hoping I got it.