The primary goal is to make the difference between a "normal" reset (POR, MCLR, Reset instruction...) and an abnormal condition (Stack under or over flow, Watchdog reset, brown out....).
Going then more in details is useful for debugging. A BOR or a WDT will need totally other ways of debugging. The problem with the table reproduced earlier are all those "u" values. There are some cases where the order of evaluation has its importance. And that's where I am stuck Evalutating the different conditions is not a problem in itself, but the order in which they are evaluated is. The "Mask" method does not solve this issue (or am I missing something ?) My guts tell me there *MUST* be a method to be able to determine without doubt what the cause of the reset was. I was expecting to find some info on the microchip website, in the AN or TB, but I must say that their search engine is kind of crap.... (sorry....) Furthermore, I have the impression that I have seen something like that a long time ago, but am unable to retrieve it..... Le jeudi 4 avril 2024 à 19:00:04 UTC+2, Rob CJ a écrit : > Hi David, > > Why not just define some masks that you use to determine the type of reset > that occured. Since it it all too PIC specific I think you could not make > a decent library forit. > > If I look at the status bits you cannot uniquely identify which reset > occured. > > So you could do the following but as said you cannot uniquely identify > what happend (example for a PIC16F19155). > > var word RESET_STATUS at PCON0 > > const word RESET_POR = 0b0000_0000_0111_0011 > const word RESET_TO_POR = 0b0000_0000_0111_0000 -- Same as PD > const word RESET_PD_POR = 0b0000_0000_0111_0000 -- Same as TO > const word RESET_BROWNOUT = 0b0000_0000_0011_0011 > > -- Check reset type. > if (RESET_STATUS & RESET_POR) == RESET_POR then > -- Power on reset. > elsif (RESET_STATUS & RESET_BROWNOUT) == RESET_BROWNOUT then > -- Brownout reset/ > end if > > > Kind regards, > > Rob > ------------------------------ > *Van:* [email protected] <[email protected]> namens David VB < > [email protected]> > *Verzonden:* woensdag 3 april 2024 21:32 > *Aan:* jallib <[email protected]> > *Onderwerp:* Re: [jallib] [Request] "Reset_code" function > > Hi, > > Still looking for this kind of function, returning a simple code to > reflect the reset condition of the PIC. > > My main problem here is to know how to deal with the "u" (unchanged) bits > > In other words: if I evaluate the conditions in the order given in the > table (reproduced earlier), and taking only the O and 1 into account > (ignoring u and x), will it work ? > > Does anyone know of an applicaiton note (from microchip) on the subject ? > > Kind regards, > David > > Le vendredi 9 juin 2023 à 19:31:10 UTC+2, Rob CJ a écrit : > > Hi David, > > I was wondering what I should do this weekend 🙂. > > BTW. I am on Holiday - in The Netherlands - and I had a quick look at some > PICs and it looks as if it is different for various PICs also from the same > range (12F/16F/18F). Initially I thought you could make a library but it > seems that you then have to add a piece of code for each specific PIC and > that is a lot of work because of the number of PICs that should be > supported. > > Of course we could start small with some PICs and extend it when needed > but still it would be a library with high maintenance. Not sure if we > should go that way. > > But maybe someone else has a bright idea on this topic. > > Kind regards, > > Rob > > > > ------------------------------ > *Van:* [email protected] <[email protected]> namens > [email protected] <[email protected]> > *Verzonden:* vrijdag 9 juni 2023 15:44 > *Aan:* jallib <[email protected]> > *Onderwerp:* [jallib] [Request] "Reset_code" function > > Hi, > > A suggestion to keep Rob busy this week-end ;-) > > I often have to test the Reset condition at start-up of a program. > > Since I'm lazy (of course....), wouldn't it be useful to write a > "reset_code" function who returns a code depending on the condition that > issued a reset in the pic (POR, WDT, Reset instruction, Stack overflow....) > ? > > See an example from a DS for PIC16F1777 where the reset_code could be 0 > (for POR, which is a normal condition) to 11, one per line in the table > > The difficulty here is to take into account for the various possibilities > existing in different families of PICs..... which is why I post my > request here.... > > [image: Capture d’écran 2023-06-09 154308.jpg] > > Any help/suggestion/commitment welcome. > > Enjoy your day > > David > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jallib/7431f8b1-4c70-4bc3-a640-6c1a3cbef875n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/7431f8b1-4c70-4bc3-a640-6c1a3cbef875n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jallib/4f1245ea-2911-4800-a0ec-391f6ff683a6n%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/4f1245ea-2911-4800-a0ec-391f6ff683a6n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/5991aaee-3661-4a63-b225-97230eda57c6n%40googlegroups.com.
