LPC1768 ADU Burst Mode Problem

Hallo zusammen,
Ich verwende bei meinem LPC1768 sechs Kanäle des ADU im Burst Mode mit einer Abtastrate von 1000 Messungen pro Sekunden pro Kanal. Habe also 6000 Interrupts pro Sekunde. Läuft auch alles einwandfrei. Meistens jedenfalls. Ich hatte ein sporadisches Fehlverhalten meines Gerätes und es lieft in einen Fehlerzustand. Nach einem erneuten aus und wieder einschalten lief alles wieder einwandfrei wie gewohnt. Habe es als ESD Problem oder was auch immer eingestuft. Nun trat plötzlich wieder dieses Problem auf also begann ich zu suchen und habe mein Gerät immer wieder ein und ausgeschaltet und beobachtet wann es schief geht.

Nach x Einschaltungen ging es schief: 47,21,34,48

Da muss also was sein. Die gesamte wichtigen Stellen der Software für den ADU abgesucht. Da war eigentlich nichts ungewöhnliches.
Also habe ich Tests eingebaut. Habe unter anderem das Global Result Register AD0GR eigentlich versehentlich zweimal gelesen. und man staune mit unterschiedlichem Ergebnis. Die Kanalnummer änderete sich (CHN). zwar nicht immer, aber manchmal. Dann habe ich zwischen diesen beiden Leseoperatioen alle Interrupts ausgeschaltet, damit nicht einer dazwischen funkt. Und trotzdem kam es zu unterschiedlichen Ergebnissen, aber wie gesagt nicht immer. Ich fing dann an die Prioritäten meiner Interrupts zu ändern. und stellte fest, daß mein beschriebenes Problem nur auftritt, wenn es einen höher priorisierten Interrupt als den ADU Interrupt gibt. Zum Beispiel Timer oder Uart. Solange der ADU eine höhere Priorität hat, tritt das Problem nicht auf. Wenn ich aber alle Interrupts sperre während ich 2 mal das Result Register lese, kann doch eigentlich garnichts passieren. es sei denn ich würde mir dafür soviel Zeit lassen, daß die nächste ADU Konvertierung schon fertig wird, dann würden sich sicherlich die Channel Bits ändern. Also müsten die CHN Bits doch immer gleich bleiben. Was sich ändert ist das "DONE" Bit, da dies beim ersten Lesen des Registers gelöscht wird, das ist ja auch völlig korrekt, aber warum ändert sich die Channelbits ???

Ne Woche ist rum und ich habe mir mal das neueste Errata-Sheet von NXP herunter geladen. Nu war ich ja erstaunt, da gibt es einen neuen Fehler, der hört sich an, als hätte er mit meinem Problem zu tun. Da steht man soll nicht das Ergebnis vom AD0GDR Benutzen sondern die entsprechenden AD0DR0..7 verwenden. Also habe ich mal den Code entsprechend geändert und siehe da auch nach 500 Einschaltungen trat kein Problem mehr auf. Bin jedoch etwas verunsichert. Denn der Burst Modus läuft ja weiter und um im Interrupt festzustellen welche Kanalwandlung grad fertig wurde, verlasse ich mich natürlich auf die drei CHN Bits. Wie soll ich sonst den Kanal ermitteln. Dann lese ich aber nicht wie vorher den ADU Wert aus dem AD0GDR-Register sondern je nach ermitteln Kanal aus den dazugehöigen Datenregistern AD0DR0..AD0DR7
Das scheint auch zu funktionieren. Die Frage bleibt eigentlich: Kann ich mich auf die CHN Bit verlassen oder nicht ?
Vielleicht hat ja schon jemand ähnliche Erfahrungen mit dem Burst Mode gemacht.
Für Info wäre ich Euch dankbar.

Siro