STM32F4xx __disable_irq(void)

[John F.]

Posted on July 01, 2013 at 15:36

Writing in 'C', I use __disable_irq(void) before reading a value that gets updated in an interrupt service routine.

__disable_irq(); //prevent serial interrupts
Count = TSp->DataAvailable; //get number of entries
TSp->DataAvailable = 0; //and clear structure member count
__enable_irq(); //allow serial interrupts

Is it

guaranteed

that when the instructions for ''

Count = TSp->DataAvailable;

'' execute, interrupts are disabled or do I need an explicit synchronisation barrier (ISB for example)? If so, do I need a barrier before enabling interrupts again? The compiler is Keil ARM if that makes any difference.

[alexandr]

Posted on July 01, 2013 at 23:29

Hi John,

as I undersood your problem, if your variable

TSp->DataAvailable

is 32 bit or less, you dont need to disable/enable interrupt, just to delare it ''volatile'' (vu32, vs32, etc).

[John F.]

Posted on July 02, 2013 at 09:06

Alex, thanks for your response. I want to be certain that the interrupt has completed and all memory operations are up to date before reading the value of variable

TSp->DataAvailable

. Then I want to be sure that the read of variable

TSp->DataAvailable

has completed before any subsequent interrupt. I am concerned that the internal machinations of the Cortex M4 and coupled memory might run in parallel or out of sequence. I read ''ARM DAI 0321A ARM Cortex-M Programming Guide to Memory Barrier Instructions Application Note 321'' which suggests that to disable interrupts (with CPSID) ''The CPSID instruction is self-synchronized to the instruction stream and there is no requirement to insert memory barrier instructions after CPSID. - Memory barrier instruction is not required.'' When enabling interrupts, ''If it is necessary to ensure a pended interrupt is recognized before subsequent operations, the ISB instruction should be used after CPSIE I.'' ''If it is not necessary to ensure that a pended interrupt will be recognized immediately before subsequent operations, it is not necessary to insert a memory barrier instruction.''. It appears I do not need any synchronisation barrier. If anyone knows differently - please let me know. Thanks.

[Tesla DeLorean]

Posted on July 02, 2013 at 14:15

Well the there are the Write Buffer(s), which cause the writes to hang out there as the code proceeds, but these do complete in order, and will be fenced automatically by data reads, although prefetch of code will by inserted.

[John F.]

Posted on July 02, 2013 at 16:05

Clive, thanks for your comments. To assist me, please could you identify the source of your information? For example, Data Sheet, Ref. Manual, ARM or Joseph Yiu's book? At this level of detail, I'm a bit lost to know where to look for definitive answers.

[Tesla DeLorean]

Posted on July 02, 2013 at 16:45

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337i/Babcffjc.html

''To prevent bus wait cycles from stalling the processor during data stores, buffered stores to the DCode and System buses go through a one-entry write buffer. If the write buffer is full, subsequent accesses to the bus stall until the write buffer has drained. The write buffer is only used if the bus waits the data phase of the buffered store, otherwise the transaction completes on the bus.'' One of the traps here would be if you wrote to the vector table, then you'd want to ensure the write actually completes before the processor fetches the address, because this is occurring over a different bus. Some of my interpretation comes from design characteristics of pipelined processors in general, and ARM designs specifically. Furber has a couple of books on the topic, and there are other texts on RISC IC design. In-order completion is a tenant of designs, as without it things get awfully unpredictable. Joseph Yiu's Definitive M3, 2nd Ed, Chap 6 is pretty good are explaining some of the inner workings.

[John F.]

Posted on July 02, 2013 at 17:24

Thanks for your help. John F.