Zitat von Siro
Den Teil hast Du richtig verstanden.
Was Du nicht verstanden hast, ist, daß NXP (und andere) in ihre Peripherie auch Schreibpuffer einbauen.
Und diese sind dem M3-Kern nicht bekannt. Insofern kann ein DSB-Befehl auch nicht wissen, wann diese Puffer weggeschrieben sind. Und darum ist Dein Vorschlag hier falsch.
Der DSB-Befehl nutzt nur bei Operationen im Kern etwas. Beispiele finden sich in der ARM-Literatur ja zu Hauf.
Joseph Yiu, der Autor vom Buch "The Definitive Guide to the ARM Cortex-M3" schreibt zu dem Thema übrigens folgendes:
Normally the Cortex-M3 wait until the previous write is completed before the interrupt return. However, some microcontrollers has a write buffer in the peripheral bridge. The write buffer accelerates single write transfers to peripherals so that the processor don't have to wait until the transfer is done (peripheral bus might be running at slower clock speed).
However, for clearing an interrupt request, the write buffer reply to the processor that transfer is done, while the actual write transfer actually haven't been completed in the peripheral. So the processor executed interrupt return, and found that the interrupt request from the peripheral is still high and think that it is a new interrupt request.
Adding memory barrier instruction (e.g. DSB) doesn't always help because the buffer is outside the processor. But it might introduce just enough delay to allow the interrupt to be cleared.
Calling a function to clear the interrupt pending register NVIC also introduce some extra clock cycles of delay. So the interrupt request is deasserted when interrupt return is executed.
Another way to solve this problem is to carry out a dummy access to the peripheral, e.g. a read access to the same peripheral, to ensure that the previous write is completed before executing the interrupt return.
Zitieren
Lesezeichen