CODEWITHSUNDEEP
armembeddedinterruptstm32interrupt-handling
Mạnh Hùng
Mạnh Hùng

Reputation: 98

stm32 - Interrupt handle

In external interrupt function, I want to reset by calling main function. But afterwards, if I have a new interrupt trigger, MCU thinks that It's handling in interrupt function and It doesn't call interrupt function again. What is my solution? (in my project, I'm not allowed to call soft Reset function)

Upvotes: 1

Views: 2706

Answers (3)

adrianzx
adrianzx

Reputation: 21

Calling Main() from any point of your code is a wrong idea if you are not resetting the stack and setting the initial values.

There is always a initialization function ( that actually calls Main()) which is inside an interrupt vector, usually this function can be triggered by calling the function NVIC_SystemReset(void) , be sure than you enable this interrupt so it can be software triggered.

As far as I know, when get inside and interrupt code, other interruptions are inhibit, I am thinking on two different options:

  • Enable the interruptions inside the interruption and call the function NVIC_SystemReset(void)
  • Modify the stack and push the direction of the function NVIC_SystemReset(void) so when you go out of the interruption it could be executed.

Upvotes: 2

Jeroen3
Jeroen3

Reputation: 935

Reset by calling main() is wrong. There is code in front of main inserted by the linker and C-runtime that you will skip by such soft-reset.

Instead, call NVIC_SystemReset() or enable the IWDG and while(1){} to reset.
The HAL should have example files for the watchdog timer.

SRAM is maintained. Any value not initialized by the linker script will still be there.

Upvotes: 2

Clifford
Clifford

Reputation: 93446

Calling main() in any event is a bad idea, calling it from an interrupt handler is a really bad idea as you have discovered.

What you really need is to modify the stack and link-register so that when the interrupt context exits,, it "returns" to main(), rather than from whence it came. That is a non-trivial task, probably requiring some assembler code or compiler intrinsics.

You have to realise that the hardware will not have been restored to its reset state; you will probably need at least to disable all interrupts to prevent them occurring while the system is re-initialising.

Moreover the standard library will not be reinitialised if you jump to main(); rather than the reset vector. In particular, any currently allocated dynamic memory will instantly leak away and become unusable. In fact all of the C run-time environment initialisation will be skipped - leaving amongst for example static and global data in its last state rather than applying correct initialisation.

In short it is dangerous, error-prone, target specific, and fundamentally poor practice. Most of what you would have to do to make it work is already done in the start-up code that is executed before main() is called, so it would be far simpler to invoke that. The difference between that and forcing a true reset (via the watchdog or AICR) is that the on-chip peripheral state remains untouched (apart from any initialisation explicitly done in the start-up). In my experience, if you are using a more complex peripheral such as USB, safely restarting the system without a true reset is difficult to achieve safely (or at least it is difficult to determine how to do it safely) and hardly worth the effort.

Upvotes: 4

Related Questions