1
\$\begingroup\$

I am facing a problem of micro controller reset, I am thinking of implementing the following to find the function in which it happens, then the root cause. As soon as I enter a function I will increment a global variable and store in eeprom. Once a reset happens I can identify the event, as I will start from main, and I will read the last eeprom value. From this I can know at which function reset happened. Now my main concern is whether I will finish the write cycle of that eeprom memory location. The reset happens approximately after every 2 hours. Any better ideas or it is OK to write in eeprom.

\$\endgroup\$
7
  • \$\begingroup\$ If you have a ram location that is not cleared by a startup you could use that. \$\endgroup\$ Mar 31, 2016 at 13:40
  • \$\begingroup\$ RAM will get cleared that is the reason I plan to use eeprom. I am not sure if any RAM not cleared by startup I need to check it. \$\endgroup\$
    – rajesh
    Mar 31, 2016 at 13:51
  • 1
    \$\begingroup\$ Check your startup code and/or linker script. \$\endgroup\$ Mar 31, 2016 at 13:59
  • 2
    \$\begingroup\$ you are going to wear out your eeprom doing that. although this sounds like a debug thing so perhaps not. send a unique character per function or set of characters out the uart and capture those on a scope. the last thing on the scope... \$\endgroup\$
    – old_timer
    Mar 31, 2016 at 14:05
  • \$\begingroup\$ you have to look at the specs for that eeprom. you could also use an external ram that is not in the same reset domain. in any of these cases you might not get the write out in time. all solutions have the timing problem. Is this an inside the chip reset or something outside, is the reset something you can catch on the scope? \$\endgroup\$
    – old_timer
    Mar 31, 2016 at 14:07

1 Answer 1

2
\$\begingroup\$

Your approach is unlikely to help. First, the reset may be totally unrelated to the current function: a watchdog timeout or a misconfigured ISR are common causes. Second, even if you discover the function which triggers the reset, there's no indication that this function is buggy. Perhaps a variable used by this function was trashed by a stack overflow which occurred somewhere else.

My advice is to strip down your firmware to the most basic core functionality and check if that part can run cleanly. Then you will include additional functions until the reset reappears, and search for errors in the function which was included last.

Also make sure you have plenty of stack space. If you have recursive functions, start by eliminating them or at least checking them scrupulously.

Since you mention you're using CAN, I suggest you check out XCP which can be used for error logging.

\$\endgroup\$
4
  • \$\begingroup\$ How long should I run the code to know the exact stack size. \$\endgroup\$
    – rajesh
    Mar 31, 2016 at 15:21
  • \$\begingroup\$ Stack is not depleted with time, the overflow occurs when you have a larger call tree that you have accounted for. That's why recursive functions are so dangerous by the way: it's hard to predict how deep the recursion can go. \$\endgroup\$ Mar 31, 2016 at 15:44
  • \$\begingroup\$ I am sorry to ask but my code is not multi tasking no rtos, then how recursive function can happen. I was of assumption that recursion will never happen. \$\endgroup\$
    – rajesh
    Mar 31, 2016 at 16:05
  • \$\begingroup\$ OS and multi-tasking have nothing to do with recursion. Think of quick sort algorithm which splits the array in two then calls the same function for each of the sub-arrays, and so on, until you get to arrays of size 1 which are by definition sorted. \$\endgroup\$ Mar 31, 2016 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.