STM32 disabling interrupts global in GCC how

[mehmet karakaya (Gast)]

hello dear forum,

I m doing a project with STM32F103 uC

I have a critical code where I want this code not be interrupted by any 
interupt - and after this critical code is executed I want enable 
interupts again

however I want that STM32 doesnot "oversee" any interrupt which is 
occured during this "disabled" time

It should execute any pending ISR whenever I enable global interrupt 
again

i.e this ISR should not be left unexecuted

how can I do this in GCC ?

thank you

[Nop (Gast)]

I'd go for this one (should already be defined in the CMSIS header 
files):

/*disable all interrupts*/
static inline __attribute__((always_inline)) void __DISABLE_IRQ(void)
{__asm volatile("CPSID i");}

/*enable all interrupts*/
static inline __attribute__((always_inline)) void __ENABLE_IRQ(void)
{__asm volatile("CPSIE i");}

See also the ARM documentation in CPSIE:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0321a/BIHBFEIB.html

[Nop (Gast)]

Note that "CPSID i" is called "disable interrupts", and the SysTick is 
an exception, not an interrupt. However, "CPSID i" turns also off the 
SysTick exception.

You can also use "CPSID f" instead of "CPSID i", to include fault 
handlers:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/BABHBAAB.html

[(prx) A. K. (prx)]

mehmet karakaya schrieb:
> i.e this ISR should not be left unexecuted

Interrupts are sticky, so disabling core interrupts just delays 
execution of a handler. It does not get lost unless interrupts are 
disabled long enough, to let a second interrupt of the same kind happen 
meanwhile.

[Peter D. (peda)]

Every interrupt source has it's pending flag. And whenever this flag was 
set by an event, the CPU execute the interrupt, after enabled. If you 
enable the interrupt after 10 years, the interrupt was still executed at 
this time.

[W.S. (Gast)]

mehmet karakaya schrieb:
> I have a critical code where I want this code not be interrupted by any
> interupt

At first (very first!) try to avoid such kind of code. There is always a 
option to solve a problem in a different way.

Then consider to use the Keil compiler, because the Keil is capable to 
use SVC's (supervisor calls) - but the GCC is not capable to do so. If 
you insist to use the GCC, then you need to write a wrapper for SVC's in 
assembler.

The purpose of the SVC is, that the SVC can be done in Software and the 
called code runs not in user mode, but instead in supervisor mode. This 
may be priorized properly, so you have exactly what you want - without 
using such "disable_int" and so on.

W.S.

[Dr. Sommer (Gast)]

W.S. schrieb:
> If you insist to use the GCC, then you need to write a wrapper for
> SVC's in assembler.
It's surprising to see you recommending to avoid Assembly code ?

[Nop (Gast)]

W.S. schrieb:
> The purpose of the SVC is, that the SVC can be done in Software and the
> called code runs not in user mode, but instead in supervisor mode.

Which makes sense if you are using an RTOS. But if there is an RTOS 
anyway, it should provide easy means for code parts that must not be 
interrupted. However, when going bare metal, I think there is no user 
mode because all code runs as privileged.

There are a number of occasions where disabling interrupts makes sense. 
When fumbling around with the core clock, for example. Or when writing 
to the flash. Ok, it is ill-advised for synchronising data between 
application and interrupts, that has a design smell.

In general, GCC has some advantages over Keil. No code size limit, and 
GCC exists cross-platform so that you can develop, debug and test the 
code e.g. on a host PC. When developing free software, Keil is out of 
the game anyway because it would be self-defeating to require a non-free 
tool to build free software.

[W.S. (Gast)]

Nop schrieb:
> However, when going bare metal, I think there is no user
> mode because all code runs as privileged.

This is rather not the case. But I think, we do not need to have 
arguments. Simply spoken the SVC rises the privilege to the programmed 
level and when all other interrupt levels are tuned accordingly, then 
our TO mehmet karakaya has the final solution. But he seems to be 
absent...

W.S.