4

I'm working on one of Freesacle micro controller. This microcontroller has several reset sources (e.g. clock monitor reset, watchdog reset and ...). Suppose that because of watchdog, my micro controller is reset. How can I save some data just before reset happens. I mean for example how can I understand that where had been the program counter just before watchdog reset. With this method I want to know where I have error (in another words long process) that causes watchdog reset.

Lundin
  • 195,001
  • 40
  • 254
  • 396
Anmk
  • 193
  • 1
  • 9
  • `on one of Freesacle micro controller` which one? Can you post the datasheet? – KamilCuk Feb 06 '19 at 08:46
  • a watchdog reset implies that the code or other broke which means you are not running reliable code that can reliably mark where it was before the reset. Plus to do this you need additional time assuming the code is working. – old_timer Feb 06 '19 at 18:16
  • you need to go backward to the problem you are trying to solve and not use this as the solution. – old_timer Feb 06 '19 at 18:16
  • @old_timer I believe the OP is actually asking for how to debug the source of a wdog reset. – Lundin Feb 07 '19 at 11:51
  • @Lundin I agree but you can understand the general problem of debugging a watchdog reset. As you have nicely described in your answer. Also that saving the pc itself isnt the solution as I mentioned in so many words. debugging something like this takes some creativity and luck. – old_timer Feb 07 '19 at 15:32

6 Answers6

2

Most Freescale MCUs work like this:

  • RAM is preserved after watchdog reset. But probably not after LVD reset and certainly not after power-on reset. This is in most cases completely undocumented.
  • The MCU will either have a status register where you can check the reset cause (for example HCS08, MPC5x, Kinetis), or it will have special reset vectors for different reset causes (for example HC11, HCS12, Coldfire).

There is no way to save anything upon reset. Reset happens and only afterwards can you find out what caused the reset.

It is however possible to reserve a chunk of RAM as a special segment. Upon power-on reset, you can initialize this segment by setting everything to zero. If you get a watchdog reset, you can assume that this RAM segment is still valid and intact. So you don't initialize it, but leave it as it is. This method enables you to save variable values across reset. Probably - this is not well documented for most MCU families. I have used this trick at least on HCS08, HCS12 and MPC56.

As for the program counter, you are out of luck. It is reset with no means to recover it. Meaning that the only way to find out where a watchdog reset occurred is the tedious old school way of moving a breakpoint bit by bit down your code, run the program and check if it reached the breakpoint.

Though in case of modern MCUs like MPC56 or Cortex M, you simply check the trace buffer and see what code that caused the reset. Not only do you get the PC, you get to see the C source code. But you might need a professional, Eclipse-free tool chain to do this.

Lundin
  • 195,001
  • 40
  • 254
  • 396
1

Depending on your microcontroller you may get Reset Reason, but getting previous program counter (PC/IP) after reset is not possible.

Most of modern microcontrollers have provision for Watchdog Interrupt Instead of reset. You can configure watchdog peripheral to enable interrupt , In that ISR you can check stored context on stack. ( You can take help from JTAG debugger to check call stack).

There are multiple debugging methods available if your micro-controller dosent support above method.

e.g In simple while(1) based architecture you can use a HW timer and restart it after some section of code. In Timer ISR you will know which code section is consuming long enough than the timer.

Vagish
  • 2,520
  • 19
  • 32
  • Watchdog interrupt in the context of Freescale MCUs is typically an ISR where you end up _after_ reset, not instead of reset. The SP won't be preserved, even though the stack itself probably is. – Lundin Feb 06 '19 at 08:54
1

Two things:

  1. Write a log! And rotate that log to keep the last 30 min. or whatever reasonable amount of time you think you need to reproduce the error. Where the log stops, you can see what happened just before that. Even in production-level devices there is some level of logging.
  2. (Less, practical) You can attach a debugger to nearly every micrcontroller and step through the code. Probably put a break-point that is hit just before you enter the critical section of code. Some IDEs/uCs allow having "data-breakpoints" that get triggered when certain variables contain certain values. Disclaimer: I am not familiar with the exact microcontroller that you are using.
Duck Dodgers
  • 3,409
  • 8
  • 29
  • 43
  • 1
    ...amd flush & close the log after every write, otherwise the last part may not be in the file at the moment of reset. – Paul Ogilvie Feb 06 '19 at 08:44
  • Yes! Indeed. Good point @PaulOgilvie, some years ago, when I was writing a log on a microcontroller and wondering why nothing is written in the output, I kept thinking that that section of the code never got hit, until I realized the need for a missing `fflush()`. – Duck Dodgers Feb 06 '19 at 08:46
  • If you need to "flush and close the log"/fflush/stdio.h on a microcontroller, you are doing it terribly wrong. It will just a simple ring buffer residing in flash/eeprom. – Lundin Feb 06 '19 at 08:57
  • @Lundin, I wasn't familiar with that technique (neither back then, nor now until 9min. ago), but wouldn't that kill flash/eeprom in a short amount of time? I mean, it can take only as many read/write cycles. The devices had to be in the field 30 years or so. As far as I remember, we had a dedicated `/log` partition for logs from all modules (mine was not the only one). 2ndly, excuse my naivety but how would writing to the flash avoid needing to flush? We won't be opening a file, rather writing values directly into some predefined `struct` member variables which could be analyzed later? Or how? – Duck Dodgers Feb 06 '19 at 09:15
  • 1
    Unless you have some hard drive plugged to your MCU (or maybe MRAM/FRAM), you have no other option. Yes, it will kill flash/eeprom over time, you have to calculate the number of reads and continuously cycle through a whole page. "Flush" is a PC concept, assuming you have some manner of file system. – Lundin Feb 06 '19 at 09:21
0

It is written in your manual.

I don't know that specific processor but in most microprocessors a watchdog reset is a soft reset, meaning that certain registers will keep information about the reset source and sometimes reason.

You need to post more specific information on your Freescale μC for this be answered properly.

RedX
  • 14,749
  • 1
  • 53
  • 76
  • This is actually most often not written in the manual of any Freescale MCU. Relying on the contents of RAM after reset is safe in most cases, but often completely undocumented. – Lundin Feb 06 '19 at 08:34
0

Even if you could get the Program Counter before reset, it wouldn't be advisable to blindly set the program counter to another after reset --- as there would likely have been stack and heap information as well as the data itself may also have changed.

It depends on what you want to preserve after reset, certain behaviour or data? Volatile memory may or may not have been cleared after watchdog (see your uC datasheet) and you will be able to detect a reset after checking reset registers (again see your uC datasheet). By detecting a reset and checking volatile memory you may be able to prepare your uC to restart in a way that you'd prefer after the unlikely event of a reset occurring. You could create a global value and set it to a particular value in global scope, then if it resets, check the value against it when a reset event occurs -- if it is the same, you could assume other memory may also be the same. If volatile memory is not an option you'll need to have a look at the datasheet for non-volatile options, however it is also advisable not to continually write to non-volatile memory due to writing limitations.

pm101
  • 1,309
  • 10
  • 30
0

The only reliable solution is to use a debugger with trace capability if your chip supports embedded instruction trace.

Some devices have an option to redirect the watchdog timeout to an interrupt rather then a reset. This would allow you to write the watchdog timeout handler much like an exception handler and dump or store the stack information including the return address which will indicate the location the interrupt occurred.

However in some cases, neither solution is a reliable method of achieving your aim. In a multi-tasking environment or system with interrupt handlers, the code running when the watchdog timeout occurs may not be the process that is causing the problem.

Clifford
  • 88,407
  • 13
  • 85
  • 165