The Mother Board forums. Free tech support, motherboard ID, and more.
It is currently Sat Mar 28, 2020 4:22 pm

Post new topic Reply to topic  [ 1 post ] 
Author Message
PostPosted: Thu Nov 23, 2017 10:24 pm 

Joined: Thu Nov 23, 2017 8:30 pm
Posts: 1
Hi to all, I have met a trouble problem in project because I'm fairly new to the ARM architecture. And I'm currently working with a board that contains STM32F0 microcontroller and an RF modem, which sends an interrupt every time it receives a message. I'm trying to implement a sleep mode in a microcontroller to save power but I don't quite understand why it behaves the way it does.

I started with a simple program that puts the CPU into sleep mode at the beginning of the execution. Then it waits for the external interrupt to wake it up, execute the interrupt and continue with the main program. In the ISR I toggle an LED on pin PA0 every time the routine is called, but then use pin PA1 in the main() that toggles and LED on and off with a short delay, indicating that the microcontroller exited the sleep mode.

My code basically looks like this:

int main()


        HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_1);

And the ISR for the EXTI

void EXTI0_1_IRQHandler(void)
    HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_0);

    // Some other stuff


The ARMv6 Architecture Reference Manual states the following regarding the Wait For Interrupt on the page B1-243:

When a processor issues a WFI instruction it can suspend execution and enter a low-power state. It can remain in that state until the processor detects one of the following WFI wake-up events:

A reset.
An asynchronous exception at a priority that, if PRIMASK.PM was set to 0, would preempt any currently active exceptions.
If debug is enabled, a debug event.
If my understanding is correct, the second line applies in this case. Which means, that calling any interrupt regardless of its priority would wake up the processor, since the WFI was called from the main. For information, all the implemented interrupt priorities are set to 0 except for the EXTI, which is set to -1.

Now this is what actually happens. The LED on PA0 toggles appropriately, indicating that the ISR does indeed execute. But the LED on PA1 stays turned off, which means that upon completing the ISR, the CPU remains in a WFI. This is confirmed even during the debugging, while I inserted a breakpoint in the interrupt service routine. After letting the code run, it succesfully stops at the breakpoint. If I then continue debugging with a step-by-step function, the program jumps to the WFI instruction (upon which it continues to the main, since debugging can cause to terminate the WFI).

My question is, why does the CPU return to the WFI when the interrupt clearly gets called? Given my understanding, if the CPU is in WFI, it should continue with it's operation wherever it left off as soon as any interrupt get called.
Thanks all guys, if you provide any suggestions, I'll feel so happy, thanks.

Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group