[Request] "Reset_code" function

[pinhe...@gmail.com]

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....

Any help/suggestion/commitment welcome.

Enjoy your day

David

[Rob CJ]

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: jal...@googlegroups.com <jal...@googlegroups.com> namens pinhe...@gmail.com <pinhe...@gmail.com>
Verzonden: vrijdag 9 juni 2023 15:44
Aan: jallib <jal...@googlegroups.com>
Onderwerp: [jallib] [Request] "Reset_code" function

 

--
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 jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/7431f8b1-4c70-4bc3-a640-6c1a3cbef875n%40googlegroups.com.

[David VB]

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

[Rob CJ]

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: jal...@googlegroups.com <jal...@googlegroups.com> namens David VB <pinhe...@gmail.com>
Verzonden: woensdag 3 april 2024 21:32
Aan: jallib <jal...@googlegroups.com>
Onderwerp: Re: [jallib] [Request] "Reset_code" function

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/4f1245ea-2911-4800-a0ec-391f6ff683a6n%40googlegroups.com.

[David VB]

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.....