| View previous topic :: View next topic |
| Author |
Message |
kgng97ccs
Joined: 02 Apr 2022
Posts: 97
|
| Counting number of MCU resets |
 Posted: Fri Jun 16, 2023 10:34 pm |
 |
|
I am using the PIC18LF46K22 MCU, CCS C compiler v5.115, and MPLAB IDE v8.92.
I would like to count the number of resets that happen after a device has been put into operation. This number will be incorporated into a BLE signal that is transmitted regularly.
However, just before the device is put into operation, I would like to set the count to zero, as the count is likely not going to be zero because of some earlier testing.
I am thinking of this:
1. I reserve a memory location in the EEPROM to store the reset count (number of resets), and set the count to zero first.
2. Each time the device resets, I read the last count from the EEPROM, increment it by one, and write the new count to the EEPROM; this is done at the beginning of the program before the master while loop. This step is likely to be repeated many times during testing.
3. Just before the device is put into operation, I reset the count in the memory location to zero.
Questions:
I am looking for ideas on how to reset the count in the memory location to zero. The device has a second button (button2).
One option I can think of is to hold down button2 and then press the reset (MCLR) button, such that if this is detected by the program, the program will write a zero to the memory location.
Would this work: “if (input(button2_pin)==0 && input(MCLR_pin)==0) …”?
I will appreciate comments and ideas from the community. Thank you. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19236
|
|
| Posted: Sat Jun 17, 2023 1:16 am |
|
|
No.
Problem is that is MCLR is held low, the chip won't start. It'll only start when
MCLR is _released_.
This is a perfect use for restart_cause.
Call this near the start of your code. Store what it returns. It has to be
called 'early', since some of the things it depends on are changed as other
things are done by the processor. So
| Code: |
void main(void)
{
int cause;
cause=restart_cause();
//Then your test becomes
if (input(button2_pin)==0 && cause==MCLR_FROM_RUN)
{
//reset your counter here.
}
|
Now I'm assuming here that you don't have the processor possibly sleeping
when MCLR is pushed?. If you do, then instead:
| Code: |
if (cause==MCLR_FROM_RUN || cause==MCLR_FROM_RUN)
if (input(button2_pin)==0)
{
//here there was a MCLR reset and the button is pressed
}
|
|
|
|
kgng97ccs
Joined: 02 Apr 2022
Posts: 97
|
|
| Posted: Sat Jun 17, 2023 6:09 am |
|
|
Thank you, Ttelmah.
1. Currently, button2 is used to perform a certain function if it is pressed for at least 3 seconds: | Code: | timeout_ct = 0;
while (input(button2_pin)==0 && timeout_ct++<3000) delay_ms(1);
if (timeout_ct >= 3000) put_device_to_low_current_mode();
else return; |
I am lost as to how to use the same button to perform another function if it is pressed for a shorter time of, say, between 1 and 2 seconds, and then released.
I will appreciate your help in providing some example code to do both (long press and short press).
2. The 18LF46K22.h file has these options for restart_cause():
| Code: | #define WDT_TIMEOUT 7
#define MCLR_FROM_SLEEP 11
#define MCLR_FROM_RUN 15
#define NORMAL_POWER_UP 12
#define BROWNOUT_RESTART 14
#define WDT_FROM_SLEEP 3
#define RESET_INSTRUCTION 0 |
Is it correct that the "MCLR_FROM_SLEEP", "MCLR_FROM_RUN", and "NORMAL_POWER_UP" options always refer to a manual press on the MCLR button? |
|
|
PrinceNai
Joined: 31 Oct 2016
Posts: 455
Location: Montenegro
|
|
| Posted: Sat Jun 17, 2023 6:18 am |
|
|
| Quote: | | Is it correct that the "MCLR_FROM_SLEEP", "MCLR_FROM_RUN", and "NORMAL_POWER_UP" options always refer to a manual press on the MCLR button? |
The first two yes, it just depends what state the PIC was in at the moment. The third one no. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9120
Location: Greensville,Ontario
|
|
| Posted: Sat Jun 17, 2023 6:49 am |
|
|
re: 'timed button'. I recall CCS has a 'timed button' code in the FAQ section ? It could be modified to return the actual delay( time in loop) and then you decide what to do, short press,long press, in between press.
there's similar code for incoming serial data.....where 'if no data for xx seconds, return to main() ..... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19236
|
|
| Posted: Sat Jun 17, 2023 6:52 am |
|
|
NORMAL_POWER_UP, is when power is applied to a chip that is off.
On the button, presumably you scan this with an interrupt or something?.
If so, then do this detection _before_ you start the detection scan of the
switch. Simply have the test for the boot mode, and if it was an MCLR
based start, then just test the button input. If it is pulled down, trigger
the reset of the count.
After this, wait for it to release (so your other scanning won't get upset),
and when it is released, or when the reset wasn't an MCLR reset, then start
the scanning for the normal button detection. |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Sat Jun 17, 2023 4:37 pm |
|
|
kgng97ccs wrote:
| Quote: |
I would like to count the number of resets that happen after a device has been put into operation.
This number will be incorporated into a BLE signal that is transmitted regularly.
However, just before the device is put into operation, I would like to set the count to zero, as the
count is likely not going to be zero because of some earlier testing. |
I have doubts about what would be the purpose of knowing the reason for the reset, I think this topic has been answered.
I would like to know if in your project it would be the same to make a power-on counter, or you also want to know the reason for the restart?
In that case you would only need an input or button to reset the counter to zero.
_________________
Humber |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Sun Jun 18, 2023 10:53 am |
|
|
| Humberto wrote: |
I have doubts about what would be the purpose of knowing the reason for the reset... |
Could be that he's trying to figure out if he has a processor hanging / firmware stability / customer doing something stupid and denying it issue.
I've worked on an industrial project that sometimes wasn't remotely reachable, but would reappear 'online' later. We couldn't replicate it so we stuck in similar code to monitor & subsequently report an abnormal startup cause. Turns out our product never restarted for any reason, but the COTS network equipment was actually the culprit. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19236
|
|
| Posted: Sun Jun 18, 2023 1:54 pm |
|
|
and of course the point is he wants to use an existing button to trigger the
reset. Very easy indeed, just as you can do this for a bootloader. Just
check the button immediately at boot, before you start the timer based
operation he is normally using for it. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
