While perhaps a few MCU's make the distinctions necessary to help in isolating the fault that brought about the internally-generated reset, fewer make it possible to determine whether it was a brownout or a runaway code issue, or perhaps some other problem.

Reading the "fine print" is absolutely essential in understanding how to make best use of this feature. The first step, of course, would be a thorough attempt at simulation. Sadly, the 805x simulators I've seen up to now have no feature for providing external stimuli, aside from manual insertion. Consequently, it's difficult and time-consuming, though perhaps quite necessary, to attempt cycle-by-cycle insertion of interrupts, and other external stimuli to the simulated run. This, however, only breaks down the occurrence on a cycle-by-cycle basis, and, as we all know, real-world effects don't always synchronize with the machine cycle. I'm not sure how helpful it would be to simulate arrival of external stimuli on a T-state-by-T-state basis, particularly since fewer and fewer MCU's are actually 12-clockers. Further, I've no knowledge of how the MCU behaves, depending on when a "brownout" is detected. Does it matter?

With an external supervisor, there's no help available at all. Detecting whether it was a watchdog reset or a brownout reset is not readily possible there. It could be done, but ... well ... who's going to do that? Isn't it easier to switch to a version that actually does what's wanted?

RE