Cortex M3 unerklärliches Interrupt Verhalten

[Renegr]

Hallo Siro,
sorry, wenn ich das Thema (auch) nochmal aufgreife. Wie hast du dein Problem denn gelöst?
Der Timer-IRQ Request ist ja noch nicht gelöscht, wenn die Funktion zurückkehrt. Laut dem letzten Satz "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. " müsste also das gleiche Register hinterher nochmal ausgelesen werden, um wirklich sicher zu gehen, dass der IRQ-Request auch gelöscht ist. Ich habe jetzt schon viel Beispielcode gesehn, aber sowas nicht.

Gruß
René

[Siro]

Hallo Renegr,
vorab ein frohes Weihnachtsfest.

ich habe es so gelassen, wie im ersten Eintrag also

__asm("DSB"); /* Data Synchronization Barrier, !!! Write Buffer */

Dies stellt zumindest eine gewisse Zeit sicher, damit das Interrupt Flag wirklich gelöscht sein müste.
Ein erneutes Löschen des Interrupt-Flags geht aber auch, das habe ich ausprobiert.
also:

LPC_T3IR.bits.MR0INT = 1; /* Interrupt Bit loeschen */


gefallen tut mir so etwas aber nicht. Der Grund: Je nach Einstellungen des Compilers (Optimierung)
wird nämlich mehr oder weniger Code erzeugt, was sich natürlich in einer veränderten Laufzeit wiederspiegelt.


Ein wirklich "GUTE" Lösung habe ich somit noch nicht gefunden. Aber es funktioniert bei mir, auch mit verschiedenen Optimierungsstufen.

Ich find das schon sehr Schade, daß man sich nicht mehr hundertprozentig auf den Code verlassen kann, so schön und gut das mit den Write Puffern ja sein mag,
aber man hat keine hundertprozentige Kontrolle. Isser fertig oder noch nich ?? Vermutlich eine Zeile später schon.....oder doch nich......

Wenn es da andere Möglichkeiten gibt, bin ich für jede Info dankbar.
bis dann
Siro

[Renegr]

Hi,
naja wie richie bzw Joseph Yiu schreibt scheint die einzig sichere Variant wirklich zu sein, das Register nochmals auszulesen. Möglicherweise willst du deinen M3 mal hochtakten, er verträgt wohl bis 120MHz, dann könnte das "DSB" Timing doch wieder nicht mehr ausreichen.
Aber egal, welche Workarounds man braucht, ich find den M3 super. Das einzig traurige an meinem LPC1768 auf dem mbed ist, dass einfach zu wenige Pins nach draussen geführt sind und somit Port 3 und 4 gar nicht zur Verfügung stehen

Gruß
René

[Siro]

Hallo Rene,

Wenn ich den Prozesor hochtakte, vermute (hoffe) ich eigentlich nicht, dass es eine Änderung des Timings zur Folge hätte.
Ich vermute, dass die Read/Write Buffer irgendwie an den Takt gekoppelt sind. Aber das ist reine Spekulation,
zudem habe ich nicht vor den hochzutakten, der LPC1769 kann wohl von Hause aus 120 MHz.

Aber wenn "Joseph Yiu schreibt" lieber 2 mal "zugreifen" sagt, werd ich aus Sicherheitsgründen meine Software auch dahin gehend ändern.
Ich habe es leider noch nicht gefunden im "Definitive Guide" Wo steht denn das auf den 380 Seiten ? ich hab noch die erste Auflage von 2007.
Die Frage muss ich wohl an Richie1234 stellen.

Das ist ja Schade, daß sie beim "mbed" nicht alle Pins herausgeführt haben. Die RXD3+TXD3 kannst Du ja an Port 0 abgreifen und die beiden PWM1.2+PWM1.3 am Port 1,
aber wie ich eben sehe sind ja noch mehr Pins garnicht dran. 14 Pins mit RSTOUT fehlen wenn ich mich nicht verzählt habe.
Inzwischen habe ich aber eine eigene Hardware. Und Ja, ich bin auch begeistert vom CORTEX M3. Hab jahrelang mit den 18er PICs gearbeitet (gefummelt,gebastelt,optimiert).
Das sind "unbeschreibliche" Leistungsunterschiede, die ich nicht mehr missen möchte. Plötzlich habe ich Rechenzeit übrig und das ohne Optimierungen der Software ....
Viel Spass wünsche ich Dir noch

Siro