Jeff,
I only skimmed the previous posts so maybe I've missed a nuance, but the
way to avoid tail-chaining is just before the ISR 'return' re-read the
register that was written to clear the interrupt flag. The read causes
the bus to stall until the previous operation (the write to clear the
flag) has completed.
For example,
void SPI2_IRQHandler(void)
{
volatile unsigned int dummy;
... some code...
SPI2_CR2 &= ~SPI_CR2_RXNEIE; // Turn off RXE interrupt enable
...some code...
dummy = SPI2_SR; // Prevent tail-chaining.
return;
}
Be sure to declare the variable 'volatile' for the read, otherwise the
gcc optimizer will optimize it out and the re-read instruction is
discarded.
I ran into this with a timer routine, and after getting it solved and
understood I realized that an earlier SPI routine bug (so I thought was
due to noise) was also explained. (BTW, Clive was that explained it.)
In the SPI case, I was being clever/efficient and not checking that the
interrupt flag was set because there was no reason for an interrupt to
occur without a flag--so I thought. Since then I put a readback of the
interrupt flag register in my ISRs before I exit as a safety precaution,
though in many cases I'm sure it is not needed.
The thing that took a while for me to realize is that the peripherals
must be thought of as some device on the end of a bus, usually running
slower than the processor, and as a result setting a bit doesn't mean it
is set in time for the next instruction.
Don
On Wed, 2014-01-15 at 11:44 -0500, skeezix wrote:
> On Wed, 15 Jan 2014, Frank Duignan wrote:
>
> # More likely the interrupt is tail-chaining (re-entering immediately) and
> this is happening so quickly that the port has no time to react. What mode
> is the timer set to? I.e
> # Interrupt on what, does it auto clear etc.
>
> uuuugh; any way to stop this?
>
> clive just sent a post:
> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Problem%20with%20DMA-USART%20Rx%20on%20STM32F407VG&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=148
>
> Reading that, it just sounds like an internal race condition that
> ther eis basicly nothing you can do about, except adding some NOPs or
> _something_ in the handler. If the handler is 'too trivial', there'll be
> timing issues and you get spurious callback.. what I'm seeing likely.
>
> So .. make sure your interupt handlers do something slightly
> heavier than a feather.
>
> Damn, thats not a fun resolution to multiple days of banging
> head on data sheets :(
>
> jeff
>
> --
> If everyone would put barbecue sauce on their food, there would be no war.
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> libopencm3-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
libopencm3-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
