AVR64EA28: PIT-Interrupt

[S. L. (sldt)]

Hat jemand diesen zum Laufen gebracht?
  Irgendetwas scheint bei diesem Controller anders zu sein, aber in den 
Datenblättern kann ich keinen Unterschied erkennen, und in den Errata 
steht auch nichts.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

S. L. schrieb:
> Irgendetwas scheint bei diesem Controller anders zu sein
Verglichen womit?

[S. L. (sldt)]

Mit anderen, die die PIT-Funktionalität haben.

[Purzel H. (hacky)]

Es kann ja nicht allzu schwer sein das Datenblatt zu lesen. Oder soll 
eine alte Library zum Einsatz kommen ? Wild heruntergeladener Code ?

[Gerhard H. (Gast)]

Kein Problem.
Schau mal in den Code meines Projekts
Beitrag "Li-Akku Reihenschaltung einzeln nacheinander laden (Switch-Control) Asm@AVR64EA28"

Allerdings Asm.

[S. L. (sldt)]

Prima, verbindlichen Dank!
  Im Laufe des Nachmittags schaue ich es mir an.

[S. L. (sldt)]

an Gerhard H.:
Ich bin noch nicht weit gekommen, aber vorab eine Frage: in der 
mprog-Schleife steht sleep, ich sehe aber nicht, wo SLPCTRL_CTRLA 
gesetzt wird.

[Gerhard H. (Gast)]

S. L. schrieb:
> ich sehe aber nicht, wo SLPCTRL_CTRLA gesetzt wird.

Im Hauptprogramm soll hier nur Idle-geschlafen werden. Aber Du hast 
Recht, dazu muss man SLEEP aktivieren. Hab ich vergessen, ist aber 
bedeutungslos. Danke für den Hinweis.

[S. L. (sldt)]

Ich komme nicht weiter - dieses Programm lässt eine LED im 
Sekundenrhythmus blinken, auf einem AVR128DA28, AVR32DD28, AVR16EB28, 
ATmega4809, auch einigen 'tinyAVR® 1-series', aber nicht auf einem 
AVR64EA28.
  Vielleicht könnten Sie es ja bei sich ausprobieren, das wäre toll.

[S. L. (sldt)]

Nochmal etwas reduziert, ganz ohne sleep.

(wobei Letzteres ursprünglich für mich der Ausgangspunkt war, ich sollte 
unter 1 uA (bei 3.0 V) kommen)

[Ob S. (Firma: 1984now) (observer)]

S. L. schrieb:

Ich habe das Ding noch nie benutzt, aber beim ersten Durchlesen des 
entsprechenden Teils des DB (konkret: AVR128DA...) bin ich auf folgendes 
gestoßen:

24.5.1
Initialization
To operate the PIT, follow these steps:
[...]
Note: The RTC peripheral is used internally during device start-up. 
Always check the Synchronization Busy bits in
the RTC.STATUS and RTC.PITSTATUS registers, and on the initial 
configuration.

Ich kann nicht erkennen, dass sich dein Code an irgendeiner Stelle um 
diese Bits schert. Ich würde also in erster Näherung vermuten, dass er 
auf den anderen Target nur zufällig entsprechend deiner Intention 
verhält.

[S. L. (sldt)]

Okay, nächster Versuch - selbes Resultat.

Date-Code des verwendeten AVR64EA28: 2326URR

(und jetzt bin ich kurz davor, mit dem AVR16EB28 weiterzuarbeiten)

PS:
> Ich kann nicht erkennen, dass sich dein Code an
> irgendeiner Stelle um diese Bits schert.
Also auch in den ersten Versionen wurde zumindest RTC_PITSTATUS geprüft.

[900ss (900ss)]

S. L. schrieb:
> Also auch in den ersten Versionen wurde zumindest RTC_PITSTATUS geprüft.

Um das Gerät einzuschalten muss der Netzstecker gesteckt werden und dann 
der Netzschalter auf ON gestellt.

Also ich hab zumindest den Stecker gesteckt, Gerät geht aber nicht. ;)

[S. L. (sldt)]

an 900ss:

Oh, Sie können sicher aufzeigen, was an der Version von 17:47 falsch ist 
- helfen Sie mir.

[900ss (900ss)]

Wenn 2 Bedingungen gefordert sind und du nach deiner Beschreibung nur 
eine erfüllst, dann funktioniert es halt nicht.

S. L. schrieb:
> wurde zumindest RTC_PITSTATUS geprüft

Ob S. schrieb:
> Always check the Synchronization Busy bits in
> the RTC.STATUS and RTC.PITSTATUS registers,

Ich habe nicht in den Sourcecode geschaut sondern nur deine Beschreibung 
gelesen.

[900ss (900ss)]

In deinem 2. Sourcecode im IRQ steht:

sbi     IN_LED,LEDpit

Möchtest du eine LED einschalten? Mit dem "IN" Register? Ohne mich jetzt 
mit der CPU näher beschäftigt zu haben erscheint mir das fehlerhaft.

[S. L. (sldt)]

an C-hater:

Übrigens finde ich diese 'Note' zwar im Datenblatt des ATmega4809, aber 
weder in dem für AVR128DA28/32/48/64 noch im Preliminary für 
AVR64EA28/32/48; also eine simple Suche nach 'during device'.

[S. L. (sldt)]

an 900ss:
Ihre Hilfsbereitschaft in allen Ehren, aber sie ist leider von keinerlei 
Sachkenntnis getrübt. Zumal ich schrieb, dass das Programm auf den 
anderen Typen läuft.

[900ss (900ss)]

S. L. schrieb:
> keinerlei Sachkenntnis getrübt.

Nee, ich hab auch keine Ahnung. Aber ich schrieb dass auch:

900ss schrieb:
> Mit dem "IN" Register? Ohne mich jetzt mit der CPU näher beschäftigt zu
> haben erscheint mir das fehlerhaft

[S. L. (sldt)]

an 900ss:
Das ist seit mindestens fünfzehn Jahren so bei den AVR8 - aber speziell 
für Sie aus dem Preliminary Data Sheet AVR64EA28/32/48:

IN[7:0] Input Value
This bit field shows the state of the PORTx pins when the digital input 
buffer is enabled.
Writing a ‘0’ to bit n in this bit field has no effect.
Writing a ‘1’ to bit n in this bit field will toggle the corresponding 
bit in PORTx.OUT

Und jetzt sollten Sie sich heraushalten.

[900ss (900ss)]

S. L. schrieb:
> Das ist seit mindestens fünfzehn Jahren so bei den AVR8

Ich hab es jetzt auch nachgelesen.

Ich hab das so nie genutzt. Ich versuche den Code so zu schreiben dass 
da steht was ich möchte. Wenn ich also einen Aushang setzen möchte, dann 
nehmen ich das OUT Register, dafür ist es da. Dann bin ich später nicht 
verwirrt und andere auch nicht. Alles andere ist für mich Unfug wenn es 
keinen zwingenden Grund gibt das anders zu machen.

Und der freundlichen(?) Bitte, mich da raus zu halten, komme ich gerne 
nach. Mein Code auf AVR funktioniert auch ;)

[S. L. (sldt)]

Sehen Sie, da haben Sie heute noch etwas gelernt; auch wenn es in Ihren 
Augen Unfug ist.
  Ich armer Tor hingegen bin so klug als wie zuvor.

[Gerhard H. (Gast)]

S. L. schrieb:
> Ich armer Tor hingegen bin so klug als wie zuvor.

Bin leider gerade auf Reisen und kann da  vorerst nix testen. Ich kann 
auf die Schnelle keinen Fehler entdecken. Arbeitet (d)ein Programm denn 
grundsätzlich auf dem EA- hast Du z.B. mal ne LED eingeschaltet? Hast Du 
die aktuellsten Device-Packs? Wie schaun die Fuses aus - Stichwort 
Watchdog? Und dann hast Du immer noch die Möglichkeit, für Dein Programm 
noch mehr (für Deinen Test wesentliche) Teile meines Programms zu 
übernehmen. Der PIT läuft, so einen Blinktest mach ich da auch gerne.

[900ss (900ss)]

S. L. schrieb:
> aber
> weder in dem für AVR128DA28/32/48/64

Abschnitt 24.10 Synchonization

Ich soll mich zwar raushalten aber meine Mutter war auch schon immer 
genervt :)

[S. L. (sldt)]

an Gerhard H.:

Vielen Dank für die Rückmeldung!

Fuses sind die ab Werk; Device-Pack ist aktuell.
  Wenn ich das LED-toggeln in die main_loop setze, glimmt die LED, und 
ich messe an ihr die entsprechende Frequenz.

Und eigentlich war ich der Meinung, ich hätte von Ihrem Programm alles 
relevante übernommen bzw. gegengeprüft. Aber natürlich bleibt der 
Sachverhalt, dass es bei Ihnen läuft und bei mir nicht.


an 900ss:
Schon richtig, hat aber erstens mit dem Fall hier nichts zu tun und ist 
zweitens nicht das, was C-hater (alias Observer) schreibt ('... used 
internally during device start-up').

[Gerhard H. (Gast)]

S. L. schrieb:
> Und eigentlich war ich der Meinung, ich hätte von Ihrem Programm alles
> relevante übernommen bzw. gegengeprüft.

Ich war im von mir genutzten aktuellen Microchip Studio7 auch öfter der 
Meinung alles relevante berücksichtigt zu haben. Dennoch gibts immer 
wieder Phänomene mit Schreibweisen, die vllt. auf Studio/AVRASM- 
Programmfehler deuten könnten.

Ich würde mal die gesamte Interrupttabelle und den Clock+RTC 
Initialisierungsteil von mir komplett übernehmen. Die zentrale Frage 
scheint ja wohl zu sein warum der Interrupt nicht auslöst. Sollte sich 
der Teufel bis dahin nicht finden lassen helfe ich gern nächste Woche 
intensiver.

Vermutlich ist es (wie meistens) eine Lappalie.

[S. L. (sldt)]

Erstmal ganz herzlichen Dank.
  Ich werde mich (allerdings erst morgen) nochmals daransetzen und Ihrem 
Tipp folgen, würde mich im Erfolgsfalle natürlich melden. Und notfalls 
bleibt mir ja noch immer der Umstieg auf den AVR16EB28 - der läuft bei 
mir.

[Gerhard H. (Gast)]

S. L. schrieb:
> notfalls bleibt mir ja noch immer der Umstieg auf den AVR16EB28 - der
> läuft bei mir.

Bemerkenswert. Leider nur mit 1/4 Flash :)

[Johann L. (gjlayde)]

900ss schrieb:
> Wenn ich also einen Aushang setzen möchte, dann nehmen ich
> das OUT Register,

Um ein Pin zu toggeln braucht man dazu eine IN, XOR, OUT Sequenz ... die 
im Gegensatz zu einem SBI aber nicht atomar ist.  Also noch IN SREG, 
CLI, OUT SREG drumrun, mindestens aber CLI, SEI je nach Kontext.

Mit dem Laden der XOR Maske ist man dann bei mindestes 6 Instruktionen, 
maximal 7 Instruktionen und 2 Register.  Wer's braucht...

[S. L. (sldt)]

> Leider nur mit 1/4 Flash

In der geplanten Anwendung sind auch die 16 KiB mehr als üppig.
  Und mit ca. 0.70 uA bei 3.0 V ist der EB brauchbar - eine 
Aussage/Entscheidung, die ich eben bislang für den EA gar nicht treffen 
kann, da bliebe nur das (blinde) Vertrauen in das 'Preliminary Data 
Sheet'.

[900ss (900ss)]

S. L. schrieb:
> hat aber erstens mit dem Fall hier nichts zu tun

Ich hatte verstanden, dass dir der Abschnitt zur Synchronisation fehlt 
im Datenblatt. Das wunderte mich und ich habe dann danach gesucht.

[900ss (900ss)]

Johann L. schrieb:
> Mit dem Laden der XOR Maske ist man dann bei mindestes 6 Instruktionen,
> maximal 7 Instruktionen und 2 Register.  Wer's braucht...

Stimmt schon, dann schreibe ich aber einen Kommentar dahinter oder nehme 
einen anderen Namen um Leute, die das nicht wissen, nicht zu verwirren. 
Man könnte dann auch das Register TOGGLE_LED nennen.... na ja
Ist auch kein Drama, das ist ja nicht der Fehler hier. Mich hat es nur 
verwirrt.

Ich habe hier nur einen ATMEGA128DA48, auf dem der PIT IRQ läuft. Wenn 
ich einen AVR64EA28 hier hätte, würde ich das jetzt probieren. Ich sehe 
so erstmal auch keine Fehler. Aber ohne HW geht's halt nicht.

[Johann L. (gjlayde)]

900ss schrieb:
> Johann L. schrieb:
>> Mit dem Laden der XOR Maske ist man dann bei mindestes 6 Instruktionen,
>> maximal 7 Instruktionen und 2 Register.  Wer's braucht...
>
> Stimmt schon, dann schreibe ich aber einen Kommentar dahinter oder nehme
> einen anderen Namen

Geheimnis: Das geht auch mit SBI.

[Peter D. (peda)]

900ss schrieb:
> Man könnte dann auch das Register TOGGLE_LED nennen

Das wäre schonmal eine saubere Lösung, die auch ein Leser versteht.

Ich muß zugeben, daß ich auch immer nur die klassische EXOR Methode 
nehme. Die AVRs haben ja schon lange reichlich Flash, so daß die paar 
eingesparten Bytes keine Rolle spielen.

[900ss (900ss)]

Johann L. schrieb:
> Geheimnis: Das geht auch mit SBI.

;)

Das wird jetzt offtopic, ich will das hier nicht ausweiten.

Bin auf die Lösung gespannt :)

[S. L. (sldt)]

an Gerhard Hauptmann:

Nochmals ganz herzlichen Dank für Ihre Unterstützung so weit.
  Aber ich möchte jetzt einen Schlusspunkt setzen (möchte Sie auch nicht 
weiter belästigen), der AVR16EB28 hat alles, was ich brauche, der EA 
kommt in das Raritätenkabinett.

Ich hatte Ihren Rat von 20:34 mit Interrupttabelle und Initialisierung 
befolgt - keine Änderung.
  Ein Vergleich der Speicherabzüge von AVR64EA16 und ATmega4809 zeigt 
keinen Unterschied, (natürlich) bis auf die Adressen.
  Über Date-Code 2326URR und 'Silicon-Revision' B2 möchte ich jetzt 
nicht weiter spekulieren, nur falls Sie das mit Ihrer Version 
vergleichen möchten.

Leicht frustriert verabschiede ich mich, wünsche Ihnen eine angenehme 
Heimkehr und ein schönes Wochenende.

[Georg M. (g_m)]

Funktioniert wenigstens der RTC? Der PIT ist nämlich nicht so 
unverzichtbar wie der RTC. Der PIT ist eigentlich nur ein Appendix am 
RTC.

[Ob S. (Firma: 1984now) (observer)]

S. L. schrieb:

> an 900ss:
> Schon richtig, hat aber erstens mit dem Fall hier nichts zu tun und ist
> zweitens nicht das, was C-hater (alias Observer) schreibt ('... used
> internally during device start-up').

Nicht wirklich ich schreib das, sondern Microchip. Ich hab's nur 
copypasted. Ich hänge einfach mal die Quelle an, damit du dich davon 
überzeugen kannst.

Seite 329, die letzten zwei Zeilen von genanntem Abschnitt 24.5.1.

[S. L. (sldt)]

Dann laden Sie mal das aktuelle herunter:

'© 2021 Microchip Technology Inc. Complete Datasheet DS40002183C-page 1
and its subsidiaries'

[S. L. (sldt)]

Und noch das hier relevante, es geht ja um AVRnEAm.

[Gerhard H. (Gast)]

S. L. schrieb:
> Aber ich möchte jetzt einen Schlusspunkt setzen (möchte Sie auch nicht
> weiter belästigen)

Keine Bange, mich interessiert aber nun trotzdem was da los ist. 
Dankenswerterweise haben Sie den fraglichen Code hinterlassen.
Bei nächster Gelegenheit dann.

[Ob S. (Firma: 1984now) (observer)]

S. L. schrieb:

> Dann laden Sie mal das aktuelle herunter:

Das habe ich natürlich auch. Aber wenn sich bei zwei Datenblättern zum 
gleichen Thema etwas ändert und diese Änderung nicht dokumentiert ist, 
dann sollte man vorsichtig sein. Der Fehler kann auch im neueren DB 
liegen...

Ich habe ja auch nicht behauptet, dass das hier wirklich das Problem 
ist, aber möglich schien es mir schon.

[S. L. (sldt)]

Und ich war Ihrem Hinweis sofort nachgegangen.

[Georg M. (g_m)]

Übrigens, der PIT funktioniert auch ohne Interrupt.
(Ob das jemand gebrauchen kann...)
Aber die LED blinkt:

#include <avr/io.h>

int main(void)
{
  PORTA.DIRSET = PIN3_bm;

  RTC.CLKSEL = RTC_CLKSEL_INT1K_gc;
  while(RTC.PITSTATUS > 0) {}
  RTC.PITCTRLA = RTC_PERIOD_CYC1024_gc | RTC_PITEN_bm;

  while(1)
  {
    if(RTC.PITINTFLAGS)
    {
      RTC.PITINTFLAGS = RTC_PI_bm;
      PORTA.OUTTGL = PIN3_bm;
    }
  }
}

[S. L. (sldt)]

Das ist klar, hatte ich auch ausprobiert, aber mir ging es um den 
sleep-Modus, bzw. um die Rückkehr aus diesem.
  Heißt das, dass Sie mit einem AVR64EAn arbeiten?

[Georg M. (g_m)]

S. L. schrieb:
> ... mir ging es um den
> sleep-Modus, bzw. um die Rückkehr aus diesem.

Sorry, das erfahre ich erst jetzt.


S. L. schrieb:
>   Heißt das, dass Sie mit einem AVR64EAn arbeiten?

Nein, war allgemein gemeint.

[Georg M. (g_m)]

Im "Silicon Errata" wird auch SLPCTRL.CTRLA erwähnt, k.A. ob es relevant 
sein könnte.

[S. L. (sldt)]

?
  Ich dachte, ich hätte das aktuelle?

[Georg M. (g_m)]

Ja, richtig, "Write Operation Lost...".

[S. L. (sldt)]

Okay, das hatte ich übersehen, war vielmehr gar nicht bis zu dieser 
Stelle vorgedrungen auf Grund der Legende unter '1'.
  Ändert aber nichts daran, dass bei meinem Controllerexemplar auf das 
gesetzte RTC_PITINTFLAGS.PI nicht reagiert wird, auch ganz ohne sleep.

[Georg M. (g_m)]

Irgendwie seltsam.

Aber das Leben geht weiter. Und wenn der RTC nicht für höhere Ziele 
geplant ist, dann kann man auf den PIT einfach verzichten.

[Gerhard H. (Gast)]

Georg M. schrieb:
> dann kann man auf den PIT einfach verzichten

Nö, warum. Der gibt einen schönen zusätzlichen regelmäßigen 
Timer-Interrupt ab.
Ich schau mir das heut abend genauer an.

[Ob S. (Firma: 1984now) (observer)]

S. L. schrieb:

> Ändert aber nichts daran, dass bei meinem Controllerexemplar auf das
> gesetzte RTC_PITINTFLAGS.PI nicht reagiert wird, auch ganz ohne sleep.

Eine Sache ist mir noch aufgefallen: MC zerlegt in der Beschreibung das 
Setzen der Periode und des Enable-Bits in zwei Schritte (und impliziert 
damit vermutlich auch eine zwischenzeitliche Abfrage bezüglich des 
Sync-State).

Du hingegen schreibst in einem Rutsch beides und fragst erst hinterher 
nach dem Sync-State.

[S. L. (sldt)]

an Observer:
Kann ich mir eigentlich nicht vorstellen, da a) das Programm auf allen 
meinen anderen Typen läuft und b) der Teufel nicht an dieser Stelle zu 
sitzen scheint: mein EB löst bei gesetztem PIT-Interruptflag einfach den 
Interrupt nicht aus.

Ich werde Ihren Tipp aber heute noch umsetzen, und mich dann melden.

PS:
> Aber das Leben geht weiter.
Richtig. Mittlerweile bin ich beim AVR32DD28 und mit diesem 
hochzufrieden.

PPS:
Der AVR64EA28 kommt in den Giftschrank.

[Ob S. (Firma: 1984now) (observer)]

S. L. schrieb:

> Ich werde Ihren Tipp aber heute noch umsetzen, und mich dann melden.

Würde mich schon interessieren, der Aufwand hält sich ja sehr im Rahmen, 
da du den Chip hast und das Programm auch nur minimal erweitert werden 
muss, um auch noch diese letzte Sache zu testen.

> PPS:
> Der AVR64EA28 kommt in den Giftschrank.

Wenn man jeden MC-Chip mit Siliziumfehlern in den Giftschrank stecken 
will, hat man bald keine mehr...

[S. L. (sldt)]

an Observer:

LED blinkt z.B. auf einem AVR16EB28, blinkt nicht auf meinem AVR64EA28.

PS:
> MC-Chip mit Siliziumfehlern

Bei Gerhard H. scheint es zu funktionieren, nur bei mir nicht.

[Ob S. (Firma: 1984now) (observer)]

S. L. schrieb:

> LED blinkt z.B. auf einem AVR16EB28, blinkt nicht auf meinem AVR64EA28.

Damit ist dann aus meiner Sicht ein nicht dokumentierter Bug im Silizium 
bewiesen.

Meldest du sowas an MC?

Ich habe schon damals bei Atmel eher schlechte Erfahrungen beim 
Bugreport gemacht. Die Scheiß-Inder haben recht regelmäßig nicht mal das 
Problem begriffen, geschweige denn, dass sie sich die Mühe gemacht 
hätten, die Sache mit dem (natürlich von mir gelieferten Code) zu 
testen.

Konnten wohl nur C. Wenn überhaupt wenigstens das...

[S. L. (sldt)]

> ... Bug im Silizium bewiesen.
Erst noch abwarten, was Gerhard H. herausfindet.

> Meldest du sowas an MC?
Nö, egal wie es ausgeht.
  Bis hierher war es wenigstens noch Übung und Erkenntnisgewinn, aber 
damit reicht es dann auch. Melden soll das ein Großkunde, der 
gegebenenfalls auch Druck machen kann.

[Gerhard H. (Gast)]

S. L. schrieb:
> Erst noch abwarten, was Gerhard H. herausfindet.

Der hat herausgefunden daß Dein Code (im Anhang) erwartungsgemäß 
funktioniert und die LED (auf PA6 abgeändert, mein Testboard) fröhlich 
blinkt. Welches Device-Pack ist denn in Deiner Solution eingestellt? Ich 
habe hier die AVR-Ex DFP Version 2.8.189. Von einem Hardware-Fehler in 
Deiner Testschaltung abgesehen kann ich mir eigentlich nur noch eine 
fehlerhafte Definition in einem anderen, von Dir verwendeten Device-Pack 
vorstellen.

Wofür sind eigentlich Deine Controller-Includes? Die werden im Studio 
einfach in der Solution eingestellt und gut ist. Gleichfalls überflüssig 
ist .org 0. Für EA - Interruptvektoren der Hinweis, daß hier JMP statt 
RJMP fällig ist.

Hat aber jetzt alles nix mit Deinem "Problem" zu tun ...
Mit dem aktuellen Studio 7.0.2594 arbeitest Du doch?
Womit programmierst Du?

[Ob S. (Firma: 1984now) (observer)]

Gerhard H. schrieb:

> Der hat herausgefunden daß Dein Code (im Anhang) erwartungsgemäß
> funktioniert und die LED fröhlich blinkt.

Das wird dann wirklich endgültig spannend. Da bleibt ja nur noch 
Vergleich der Silizium-Revision.

Es ist jedenfalls sehr, sehr unwahrscheinlich, dass S.L. ein einzelnes 
Exemplar mit einem derart spezifischen Fehler erwischt hat.

> Welches Device-Pack ist denn
> in Deiner Solution eingestellt?

Das ist wohl ziemlich irrelevant. Die paar verwendeten Bits und 
Registeradressen sind definitiv immer gleich geblieben, seitdem das 
Dingens überhaupt in den Packs aufgetaucht ist.

Sprich: hier kann das Problem unmöglich liegen.

> Wofür sind eigentlich Deine Controller-Includes? Die werden im Studio
> einfach in der Solution eingestellt und gut ist.

Ja, hier könnte es tatsächlich ein Problem geben. Wenn man explizit 
eigene Device-Header included und implizit die nutzt, die man über die 
IDE konfiguriert, dann kann es knallen. Das sollte dann allerdings schon 
beim Assembler-Lauf knallen. Ich traue S.L. absolut zu, diesen Knall 
hören zu können...

> Gleichfalls überflüssig
> ist .org 0.

Überflüssig vielleicht, aber sicher nicht störend oder gar ein Problem.

> Für EA - Interruptvektoren der Hinweis, daß hier JMP statt
> RJMP fällig ist.

Das ist definitiv Unsinn. So lange sich die ISRs im Nahbereich der 
Vektortabelle rumtreiben, kann man sie natürlich per rjump aus der 
Vektortabelle anspringen. Bei der doch sehr überschaubaren Menge an 
Code ist das ganz sicher gegeben...

[S. L. (sldt)]

> Device-Pack
Atmel.AVR-Ex_DFP.2.9.197: AVR64EA28def.inc Created: 2024-02-29 14:26
Sollte keine Rolle spielen, laut Speicherabzug stimmen die 
Flash-Adressen mit dem Datenblatt überein, die Peripherie-Adressen z.B. 
sind dieselben wie beim ATmega4809.

> Hardware-Fehler in Deiner Testschaltung
Ich stecke nur AVR64EA28 und AVR16EB28 um

> Wofür sind eigentlich ...
Ich arbeite mit einem uralten AVR-Studio 4. Wie aus dem Speicherabzug 
von '03.05.2024 12:33' zu ersehen ist, spielt das keine Rolle.

> JMP statt RJMP
Spielt auch keine Rolle.

Welchen Date-Code hat Ihr AVR64EA28? Meiner hat '2326URR', auf der 
Unterseite steht THAILAND und P3 - was auch immer das heißen mag.
Können Sie mir einen Speicherabzug geben?

... wenn es Ihnen die Mühe wert ist, ich selbst bin, wie bereits 
geschrieben, mittlerweile auf einen AVR32DD28 umgestiegen.

PS:
AVRASM: AVR macro assembler 2.2.8 (build 80 Jan 14 2020 18:27:50)

PPS:
korrigiere: 'P5'

[S. L. (sldt)]

avrea28.jpg von 18:42 (18:56):
'EEPROM size      1 KB' - well now, how about that? - im Datenblatt 
steht 512 Bytes, und im AVR64EA28def.inc '#define EEPROM_SIZE 0x0200'. 
Aber das nur am Rande.

[Gerhard H. (Gast)]

Ob S. schrieb:
> Sprich: hier kann das Problem unmöglich liegen.

Da wär ich mir nicht so sicher.
Allerdings ist die verwendete DP Version noch neuer als meine.
Da wird sich doch kein Fehler eingeschlichen haben ...

P.S. hat sich nicht, habe gerade selber geupdatet- funktioniert.

S. L. schrieb:
> Ich arbeite mit einem uralten AVR-Studio 4

Na ja. Programmieren Sie dann etwa mit AVRDUDE?
Das alte Studio unterstützt doch kein modernes Microchip-Tool.
Ich verwende AtmelICE oder nEDBG.

Ob S. schrieb:
> aber sicher nicht störend oder gar ein Problem.

Hat auch niemand behauptet.

S. L. schrieb:
> Welchen Date-Code hat Ihr AVR64EA28? Meiner hat '2326URR'

Meiner 223760D. Ebenso älter.

S. L. schrieb:
> Können Sie mir einen Speicherabzug geben?

Alles was im DEBUG Verzeichnis zu finden ist gerne- siehe Anhang.
Die LED Position hab ich vorm Assemblieren wieder auf 7 geändert.

Ob S. schrieb:
> Das ist definitiv Unsinn. So lange sich die ISRs im Nahbereich der
> Vektortabelle rumtreiben, kann man sie natürlich per rjump aus der
> Vektortabelle anspringen. Bei der doch sehr überschaubaren Menge an
> Code ist das ganz sicher gegeben...

Nun, da es selten bei Minicode bleibt und man für gewöhnlich mehrere 
Interrupts verwendet wird aus dem "definitiven Unsinn" ganz schnell 
bittere Notwendigkeit. Es sei denn, Du willst der Interrupttabelle 
unnützerweise noch zusätzliche Platzhalter einfügen...

So, für mich ist der Fall gegessen.
Aus dem "Giftschrank" kann das Teil definitiv wieder raus :)

[S. L. (sldt)]

Zwar kein Speicherabzug, aber die Intel-Hex-Datei ist genausogut: wenn 
ich Ihr EATEST.hex in den AVR16EB28 flashe, blinkt die LED, bei meinem 
AVR64EA28 blinkt sie nicht.
  Vielleicht sollte ich es mal mit Voodoo versuchen, ein Säckchen mit 
Knochen über dem Teil schwenken, dunkle Sprüche murmeln, ein Tier opfern 
...

PS:
> Aus dem "Giftschrank" kann das Teil definitiv wieder raus
Au contraire - mein Exemplar bleibt definitiv drin.

[Ob S. (Firma: 1984now) (observer)]

Ob S. schrieb:

> Das wird dann wirklich endgültig spannend. Da bleibt ja nur noch
> Vergleich der Silizium-Revision.

@Gerhard H.:
Man kann die HW-Revision auslesen, man braucht dazu nichtmal irgendwas 
zu programmieren, nur den Debugger zu benutzen. Könntest du das 
vielleicht mal tun? Screenshot reicht.

@S.L.:
Du kannst das allerdings leider nicht so einfach tun, da du dich aus 
unerfindlichen Gründen auf das uralte Studio4 beschränkst und deswegen 
vermutlich auch nicht die dazu nötige Hardware hast. Aber auch du 
könntest das auslesen. Musst dazu allerdings etwas programmieren. Kannst 
du, da bin ich sicher.

[Gerhard H. (Gast)]

S. L. schrieb:
> bei meinem
> AVR64EA28 blinkt sie nicht

Cool. PA7 etwa kaputt?

Ob S. schrieb:
> Man kann die HW-Revision auslesen, man braucht dazu nichtmal irgendwas
> zu programmieren, nur den Debugger zu benutzen.

Das tat ich bereits.
Wenn Du mal Deinen geschätzten Blick weiter hoch bemühen würdest...

[S. L. (sldt)]

> PA7 etwa kaputt?
Nee, wie vor einer gefühlten Ewigkeit geschrieben:
> Wenn ich das LED-toggeln in die main_loop setze, glimmt die LED,
> und ich messe an ihr die entsprechende Frequenz.

> HW-Revision auslesen ... allerdings etwas programmieren
Hatte ich vor langer Zeit mal gemacht, wie ging das nochmal ...?

[Gerhard H. (Gast)]

S. L. schrieb:
> Hatte ich vor langer Zeit mal gemacht, wie ging das nochmal ...?

Tools/Device Programming/Device information.
Naja, mit Studio7 halt...

Ich würde fast wetten bei mir funktioniert Ihr Controller :)

[S. L. (sldt)]

> Ich würde fast wetten bei mir funktioniert Ihr Controller
Wohnen Sie in Radel-Distanz von Freiburg i.Brsg.? Kennen doch sicher ein 
nettes Cafe ...

an Observer:
Ist das der 'System Information Block'?

[Gerhard H. (Gast)]

S. L. schrieb:
> Wohnen Sie in Radel-Distanz von Freiburg i.Brsg.?

Leider nein, war aber gerade näher dran (Tübingen) als jetzt zuhause ...

[Ob S. (Firma: 1984now) (observer)]

Gerhard H. schrieb:

> Nun, da es selten bei Minicode bleibt und man für gewöhnlich mehrere
> Interrupts verwendet wird aus dem "definitiven Unsinn" ganz schnell
> bittere Notwendigkeit.

Nö. ISRs sind typisch kurz bis sehr kurz. Und natürlich kann man diese 
kurzen Codefragmente ganz bewußt nahe an der Vektortabelle lokalisieren. 
Mein Gott, das ist ja nichtmal in C irgendwie problematisch (macht der 
Compiler von sich aus schon so...).

> Es sei denn, Du willst der Interrupttabelle
> unnützerweise noch zusätzliche Platzhalter einfügen...

Du kannst definitiv nicht wirklich Assembler.

Was für Platzhalter? Solange du jeden benutzten Vector mit dem passenden 
.org einleitest, brauchst du überhaupt keine "Platzhalter". Die ggf. 
zwei ungenutzen Byte eines Vektors bleiben halt einfach 0xff. Tut keinem 
weh und tut der Funktion keinerlei Abbruch.

Tss...

[Gerhard H. (Gast)]

Ob S. schrieb:
> Nö. ISRs sind typisch kurz bis sehr kurz. Und natürlich kann man diese
> kurzen Codefragmente ganz bewußt nahe an der Vektortabelle lokalisieren.

Erzähl mir doch nicht was ISRs typischerweise sind.
Die sind so lang wie ich sie mache- und mit JMP ortsunabhängig 
angesprungen.

> Was für Platzhalter? Solange du jeden benutzten Vector mit dem passenden
> .org einleitest

Toll. Mindestens genauso überflüssig.
Eine ordentliche, vollständige JMP Tabelle und gut ist.
Mit RJMP fällst Du dann auf die Schnauze.

Tss..

[S. L. (sldt)]

Also wenn es der SIB ist:

AVR64EA28:
41 56 52 20 20 20 20 20 50 3A 33 44 3A 31 2D 33
ein alter AVR128DA28:
20 20 20 20 41 56 52 20 50 3A 32 44 3A 31 2D 33

[Ob S. (Firma: 1984now) (observer)]

Gerhard H. schrieb:

> Mit RJMP fällst Du dann auf die Schnauze.

Ist mir noch nie passiert. Warum auch? Die Logik der Sache sagt: es gibt 
keinen Grund, ISRs irgendwo weitab der Vektortabelle zu lokalisieren. 
Und sie sagt auch: es gibt keinen Grund, nahe Ziele nicht per rjmp 
anzuspringen. Dazu gibt's die Instruktion ja schließlich.

[Ob S. (Firma: 1984now) (observer)]

Ob S. schrieb:
> Gerhard H. schrieb:
>
>> Mit RJMP fällst Du dann auf die Schnauze.
>
> Ist mir noch nie passiert. Warum auch? Die Logik der Sache sagt: es gibt
> keinen Grund, ISRs irgendwo weitab der Vektortabelle zu lokalisieren.
> Und sie sagt auch: es gibt keinen Grund, nahe Ziele nicht per rjmp
> anzuspringen. Dazu gibt's die Instruktion ja schließlich.

Ach so, fast vergessen: wenn es doch mal nötig ist, eine ISR fernab der 
Vektortabelle zu plazieren, dann meckert sehr zuverlässig der Assembler, 
wenn man in der Vektortabelle ein rjmp benutzt hat, der das Ziel nicht 
erreichen kann.

Also ich sehe hier absolut kein Problem.

[S. L. (sldt)]

C-hater, könnten wir bitte zum eigentlichen Problem zurückkehren?
  Nochmal: fragten Sie nach dem 'System Information Block'?

AVR64EA28:
41 56 52 20 20 20 20 20 50 3A 33 44 3A 31 2D 33
A  V  R                 P  :  3  D  :  1  -  3

[Gerhard H. (Gast)]

Ob S. schrieb:
> Die Logik der Sache

Welche Logik?
Eine komplette Interruptvektortabelle dient Ordnung, Übersicht, 
Codewiederverwendbarkeit und Sicherheit: Irrtümlich aktivierte 
Interrupts werden nämlich sicher abgefangen. Das ist den einen JMP Takt 
mehr locker wert, und den Flash-Mehraufwand auch.
Wenn Du Deine Befriedigung statt dessen in der Totaloptimierung findest 
meinetwegen- nur solltest Du deshalb andere Wege nicht so 
abqualifizieren.

S. L. schrieb:
> C-hater, könnten wir bitte zum eigentlichen Problem zurückkehren?

Das würde ich auch vorschlagen.
Schade daß wir nicht die gleiche moderne Tool-Basis verwenden.

[S. L. (sldt)]

an Gerhard Hauptmann:

Observer hat sich wieder in den alten C-hater zurückverwandelt (a la 
'Dr. Jekyll und Mr. Hyde'), und vergiftet wie in alten Zeiten jede 
Diskussion.

Von Ihnen verabschiede ich mich aufs freundlichste, für alle anderen bin 
ich jetzt einfach weg.

[Gerhard H. (Gast)]

S. L. schrieb:
> 'System Information Block'

Im EA Datenblatt Seite 487.

[900ss (900ss)]

Auch wenn S.L. es nicht interessiert...

Evtl. die Startup time mit den Fußes auf maximum setzen? Er weiß, 
manchmal ist es sowas "einfaches". Vielleicht ist der Aufbau mit 
dieserlm Controller etwas sensibler als bei den anderen Controllern.

Nachtrag: oder BOD einschalten?

[Gerhard H. (Gast)]

900ss schrieb:
> Evtl. die Startup time mit den Fußes auf maximum setzen?

Hat keinen Einfluß. Da bin ich alles durchgegangen.

> Vielleicht ist der Aufbau mit
> dieserlm Controller etwas sensibler als bei den anderen Controllern.

In keinster Weise.

> BOD einschalten?

braucht man auch nicht.

[S. L. (sldt)]

Vorab: An den, den es angeht: Sie mögen fachlich noch so kompetent sein, 
lieber bleibe ich für den (spärlichen) Rest meines Lebens unwissend, als 
noch einmal mit so etwas kleinkariertem, engstirnigem, kurz: borniertem 
zu diskutieren, ja nur zu kommunizieren; ich habe es, weiß Gott, in den 
letzten anderthalb Jahrzehnten immer mal wieder versucht. In Ihr 
Stammbuch: "charakterlich ungeeignet zur Teamarbeit".

---------------------------

Ich bin dies vielleicht dem einen oder anderen hier schuldig (sowie DEM 
einen stillen Mitleser) - nie hätte ich gedacht, das so etwas einmal an 
mich kommen könnte (es gibt immer ein erstes Mal), nach einem 
Vierteljahrhundert mit den AVR8: mein AVR64EA28 (und ich habe nur den 
einen) scheint generell keine Interrupts auszulösen. Wer Zeit übrig hat 
und sie vergeuden will, möge alles weitere aus dem beigefügten Programm 
ersehen. Ich bezog den Controller, zusammen mit einigen anderen der 
AVRmxyn-Reihe, am 25. April von einem großen deutschen Versender; den 
Namen nenne ich nicht, weil er höchstwahrscheinlich gar nichts dafür 
kann - wer regelmäßig dort bestellt und mit den AVR8 arbeitet, wird 
anhand des Datums sofort erkennen, um wen es sich handelt, die anderen 
brauchen es nicht zu wissen.

[Volker B. (Firma: L-E-A) (vobs)]

S. L. schrieb:
> mein AVR64EA28 (und ich habe nur den
> einen) scheint generell keine Interrupts auszulösen.

Diese Codezeilen verstehe ich nicht:

    lds     tmpi,TCA0_SINGLE_INTFLAGS
    sts     TCA0_SINGLE_INTFLAGS,tmpi
...
    lds     tmpi,TCB0_INTFLAGS
    sts     TCB0_INTFLAGS,tmpi

Du schreibst die Adresse des Interruptflagregisters in genau dieses.
Sollte dort nicht die Bitmaske des Interruptflags geschrieben werden?

Grüßle,
Volker

P.S.: Ich weis schon, warum ich lieber in C programmiere. :-)

[Gerhard H. (Gast)]

Mich lässt das ratlos zurück. Fakt ist nur, an der Software liegts nicht 
und am EA-Controllertyp an sich auch nicht. Beides funktioniert ganz 
unauffällig und wie erwartet. Meine Fantasie lässt nur noch irgend eine 
Art Programmierfehler zu, obwohl Sie das Programm bestimmt ordentlich 
zurückgelesen und verglichen haben. Irgend einen serienmäßigen 
Hardwarefehler kann doch niemand annehmen wenn Ihr Controller sogar 
neuer als meiner ist. Auffällig ist allerdings das etwas 
unterschiedliche Format des Date-Codes. Die IC Unterseite bin ich Ihnen 
noch schuldig: Thailand 05 (oder O5).
Idealerweise sollten Sie nochmal mit einem zweiten Exemplar aus anderer 
Quelle gegenprüfen. Da mich das ungewöhnliche Thema interessiert gerne 
unentgeldlich von mir.

Volker B. schrieb:
> Du schreibst die Adresse des Interruptflagregisters in genau dieses.

Nein, er schreibt den Inhalt dieses in selbiges zurück. Das quittiert in 
dem speziellen Fall genauso den Interrupt (und definitiv alle 
anstehenden in diesem Register).

[Volker B. (Firma: L-E-A) (vobs)]

Gerhard H. schrieb:

> Volker B. schrieb:
>> Du schreibst die Adresse des Interruptflagregisters in genau dieses.
>
> Nein, er schreibt den Inhalt dieses in selbiges zurück. Das quittiert in
> dem speziellen Fall genauso den Interrupt (und definitiv alle
> anstehenden in diesem Register).

OK, danke! Meine Assemblerkenntnisse sind etwas eingerostet. :-)

Grüßle,
Volker

[S. L. (sldt)]

> serienmäßigen Hardwarefehler
Ich denke eher an einen singulären Produktionsfehler, Staubkorn oder 
ähnliches. Warum das in der Endkontrolle nicht aufgefallen ist ...?

an Volker B.:
'This bit is set when an overflow interrupt occurs ... The bit is 
cleared by writing a ‘1’ to the bit position'

[900ss (900ss)]

Gerhard H. schrieb:
>> BOD einschalten?
>
> braucht man auch nicht.

Das ist sicher etwas zu "allgemein". Aus Langeweile ist die BOD nicht 
eingebaut worden. Dass es in deiner Umgebung so funktioniert, will ich 
glauben. Aber bei S.L. mag es anders sein. Er nutzt ein anderes Netzteil 
als du u.s.w. Auch wenn die anderen Controller bei ihm ohne BOD laufen 
heißt das nicht, dass es der AVR64EA28 auch macht.
Eingeschaltet tut es nicht schaden sondern sorgt für ein geregeltes 
Startup (Reset) wenn die Spannung z.B. zu langsam hochläuft. Gibts 
alles.
Und das ist wirklich recht einfach ausprobiert.

Ich glaube kaum an einen Defekt des Controllers. Es ist ein anderer 
fieser versteckter Fehlerteufel. Und mich würde es auch fuxen :) Ich hab 
mir schon extra einen AVR64EA28 mitbestellt um das nachzuvollziehen. 
Scheint aber sinnlos, da es kein Controller "typisches" Verhalten ist. 
Na ja, hat die Familie Zuwachs bekommen ;)

[Gerhard H. (Gast)]

900ss schrieb:
> Aus Langeweile ist die BOD nicht eingebaut worden

Natürlich nicht.
Wenn S.L. aber nur den Chip in ein und derselben Testschaltung wechselt 
und es mit einem funktioniert und dem anderen nicht dürfte eine 
fehlerhafte Stromversorgung wohl kaum infrage kommen. Die Erfahrung 
würde ich ihm schon zutrauen. Und glaub mir, mein eigener Aufbau ist zu 
diesem Test alles andere als professionell. Daß sich just ein EA so 
zickig im Vergleich zu den vielen anderen verhielte die man so alles 
verwendet- nö.
AVRs sind gutmütige und robuste Arbeitstiere.
Anlaufen tut der EA bei S.L. ja zweifellos.
Daß dann trotzdem das Interruptsystem außer Gefecht bliebe - 
abenteuerlich.

> Ich glaube kaum an einen Defekt des Controllers

Ich auch nicht. Das berüchtigte Staubkorn wär wirklich ein dolles Ding.
Mehr lohnt es sich ohne mehr Information zu Aufbau, Programmierung und 
IC-Herkunft aber hier nicht zu spekulieren.

> Ich hab mir schon extra einen AVR64EA28 mitbestellt um das
> nachzuvollziehen

Prima. Dann wären wir schon zu dritt im Forum mit AVR-EA Erfahrung. Sei 
aber nicht enttäuscht wenn Du nur zum gleichen Ergebnis wie ich kommst 
:)

[900ss (900ss)]

Gerhard H. schrieb:
> Wenn S.L. aber nur den Chip in ein und derselben Testschaltung wechselt
> und es mit einem funktioniert und dem anderen nicht dürfte eine
> fehlerhafte Stromversorgung wohl kaum infrage kommen.

Was ich nicht getestet habe, weiß ich nicht. Meine Erfahrung mit der ich 
gut gefahren bin. Wenn nix mehr hilft sollte man die 
Selbstverständlichkeiten in Frage stellen.

Gerhard H. schrieb:
> Die Erfahrung
> würde ich ihm schon zutrauen.

Ich habe keine Zweifel an der Erfahrung von S.L. was leider nicht auf 
Gegenseitigkeit beruht ;)

Gerhard H. schrieb:
> Sei
> aber nicht enttäuscht wenn Du nur zum gleichen Ergebnis wie ich kommst
> :)

Bin ich jetzt schon :) Ich vermute ganz stark, dass ich das gleiche 
sehe, wie du auch.

Gerhard H. schrieb:
> Daß dann trotzdem das Interruptsystem außer Gefecht bliebe -
> abenteuerlich.

Zugegeben, ja. Aber...

[Gerhard H. (Gast)]

900ss schrieb:
> sollte man die
> Selbstverständlichkeiten in Frage stellen

Vielleicht ist der Abblock-Kondensator grenzwertig.
Am ehesten würde ich nach allem hier auf eine Fälschung tippen.
Vorausgesetzt die Programmierung mit überaltertem Studio +
unbekanntem Programmier-Adapter gelang.
S.L. könnte mal ein gutes Foto seines Exemplars zum Vergleich zeigen.
Meine Quelle war microchipdirect. Die ist über Zweifel erhaben.

[Adam P. (adamap)]

900ss schrieb:
> Ich hab mir schon extra einen AVR64EA28 mitbestellt um das nachzuvollziehen.

Ich glaub ich bestell jetzt auch einen :-)
Das kann doch net sein, dass das net tut - laut Datenblatt und diversen 
C Sourcen sollte das kein Hexenwerk sein.

@900ss
In welchem Gehäuse hast du den bestellt, oder ist es ein fertiges Board?

[900ss (900ss)]

Adam P. schrieb:
> Das kann doch net sein, dass das net tut

Bei Gerhard funktioniert es ja. Es wird wohl ein Problem bei S.L. sein. 
Was auch immer.

Adam P. schrieb:
> In welchem Gehäuse hast du den bestellt, oder ist es ein fertiges Board?

Ich habe einen einzelnen Controller im DIL Gehäuse gekauft.
Kommt aber wahrscheinlich erst zum Wochenende. Ich hatte einen sehr 
lange Liste zu bestellen und leider ist nicht alles lieferbar. :(

[Veit D. (devil-elec)]

Hallo,

ich habe heute festgestellt das mein AVR64EA32 im FQFP 4 Probleme hat.
Weder der RTC- noch der PIT ISR Interrupt funktionieren. Meine Led an 
PA3 blinkt nur wenn ich das Interrupt Flag in der Hauptschleife 
auswerte.
Das 3./4. Problem betrifft die Zuweisungen der Bits ins RTC.CTRLA bzw. 
RTC.PITCTRLA Register. Verodern direkt mit Register funktioniert bei mir 
nicht. Ich muss wie beim Errata des ATmega4809 alle Bits in einer temp 
Variablen verodern und diese "Summe" dann dem Register mit einer 
Zuweisung geben. Ich sehe aktuell keine andere Lösung.

[Gerhard H. (Gast)]

Veit D. schrieb:
> Weder der RTC- noch der PIT ISR Interrupt funktionieren.

Bemerkenswert.
Das spitzt sich zum Krimi zu.
Da kann man nur möglichst viele dazu aufrufen es ebenfalls zu testen.
Vielleicht kristallisiert sich sich ja so der eigentliche Hintergrund 
heraus.

[Georg M. (g_m)]

Veit D. schrieb:
> Weder der RTC- noch der PIT ISR Interrupt funktionieren.

 sei();

[Veit D. (devil-elec)]

Georg M. schrieb:
> Veit D. schrieb:
>> Weder der RTC- noch der PIT ISR Interrupt funktionieren.
>
>

>  sei();
>

Ach du Sch...
Okay mit sei() funktioniert es. Vielen Dank an das wachsame Auge.  ;-)
Das Problem mit den Registerzuweisungen bleibt bestehen. Wie beim 
ATmega4809.

[Veit D. (devil-elec)]

Hallo,

habe mir einmal sein Assembler angeschaut.  Wenn S.L. diese beiden 
Zuweisungen zusammenfasst, sollte es auch bei ihm blinken.

[code]
; 3. Select the period for the interrupt by writing the desired value to 
the Period (PERIOD) bit field in the Periodic Interrupt Timer Control A 
(RTC.PITCTRLA) register.
    rtcstatus
    ldi     tmp0,0b0_1101_00_0          ; /16384
    sts     RTC_PITCTRLA,tmp0

; 4. Enable the PIT by writing a ‘1’ to the Periodic Interrupt Timer 
Enable (PITEN) bit in the RTC.PITCTRLA register.
    rtcstatus
    lds     tmp0,RTC_PITCTRLA
    ori     tmp0,0b0_0000_00_1          ; enable
    sts     RTC_PITCTRLA,tmp0
[code]

[Gerhard H. (Gast)]

Veit D. schrieb:
> Verodern direkt mit Register funktioniert bei mir
> nicht.

Wozu? Mit einem AVR I/O Register kann man nix direkt verodern.

> Wenn S.L. diese beiden
> Zuweisungen zusammenfasst

Welche beiden Zuweisungen?
RTC_PITCTRLA wird genau einmal geladen und gut ist.

> sollte es auch bei ihm blinken

Fakt ist, sein Code (Anhang) blinkt bei ihm nicht und bei mir schon.

Gerhard H. schrieb:
> Das spitzt sich zum Krimi zu.

Veit D. schrieb:
> Okay mit sei() funktioniert es.

Schade.
Jetzt ist die Spannung schon wieder raus :)

[Veit D. (devil-elec)]

Hallo,

ich sehe 2 Registerzuweisungen im Assembler. Oder etwa nicht.
Einmal wird der CycleCount geschrieben und danach kommt das Enable Bit 
dazu.
Sind für mich 2 Schreibzugriffe?

Er müßte gleich

rtcstatus
    ldi     tmp0,0b0_1101_00_1          ; /16384 + enable
    sts     RTC_PITCTRLA,tmp0

zusammen zuweisen.

[Gerhard H. (Gast)]

Veit D. schrieb:
> zusammen zuweisen

Na das tut er doch. Siehe sein Code.
RTC_PITINTCTRL und RTC_PITCTRLA sind verschiedene Register...

[Veit D. (devil-elec)]

Hallo,

hattest du meine Dateien gelesen?

Dieses verodern funktioniert, am Ende eine Registerzuweisung der 
"Summe".

uint8_t temp = 0;   
temp |= RTC_PRESCALER_DIV1024_gc;     // Prescaler 1024
temp |= RTC_RUNSTDBY_bm;
temp |= RTC_RTCEN_bm;                 // enabled  
RTC.CTRLA = temp;                     // set Config

Das hier funktioniert nicht - bei diesem Controller !

RTC.CTRLA |= RTC_PRESCALER_DIV1024_gc;  // Prescaler 1024
RTC.CTRLA |= RTC_RUNSTDBY_bm;
RTC.CTRLA |= RTC_RTCEN_bm;                 // enabled

[Gerhard H. (Gast)]

Veit D. schrieb:
> Das hier funktioniert nicht

Könnte das ein Problem des Compilers sein? Sorry, ich mach nur Asm. Da 
gibts kein solches Problem.

[Veit D. (devil-elec)]

Gerhard H. schrieb:
> Veit D. schrieb:
>> zusammen zuweisen
>
> Na das tut er doch. Siehe sein Code.
> RTC_PITINTCTRL und RTC_PITCTRLA sind verschiedene Register...

Das von 21:00 Uhr habe ich aus seinem letzten Code zum Thema 06.05.2024 
16:49.
2x RTC_PITCTRLA so wie ich es zitiert habe.

[Veit D. (devil-elec)]

Gerhard H. schrieb:
> Veit D. schrieb:
>> Das hier funktioniert nicht
>
> Könnte das ein Problem des Compilers sein? Sorry, ich mach nur Asm. Da
> gibts kein solches Problem.

Da bin ich mir ganz sicher, dass der Compiler das richtig macht. Sonst 
hätte ich überall Problem mit verodern. Zudem ich das kannte aus dem 
Errata vom ATmega4809 und habs auch hier ausprobiert.

S.L. soll das einfach ausprobieren und Statusmeldung abgeben.  :-)

[Gerhard H. (Gast)]

Veit D. schrieb:
> Das von 21:00 Uhr habe ich aus seinem letzten Code

OK, den hab ich mir gar nicht angeschaut aber das war auch nicht nötig 
da sein Problem ja bereits in seinem kürzesten Code (mein Anhang) 
besteht... D.h. eine bestimmte OR Formulierung kann nicht ursächliches 
Problem sein. Man muß es jetzt nicht komplizierter machen als nötig.

> S.L. soll das einfach ausprobieren und Statusmeldung abgeben.  :-)

Soll er. Aber ich glaube er ist über alle Berge :)

[S. L. (sldt)]

an Veit Devil:
> Er müßte gleich ... 0b0_1101_00_1 ... zusammen zuweisen.
> Statusmeldung abgeben

So hatte ich es ursprünglich (und mache es immer so), dieses 
Auseinanderziehen erfolgte auf Anraten C-haters - brachte aber keinerlei 
Änderung.
  Wie schon geschrieben, löst mein (einziger) AVR64EA28 keinen PIT-, 
TCA- oder TCB-Interrupt aus, also vermutlich überhaupt keinen. Und bevor 
sich da nicht von anderer Seite grundlegend neue Erkenntnisse ergeben, 
investiere ich nicht noch mehr Zeit.

> Aber ich glaube er ist über alle Berge :)
In der Tat: nachher geht's über die Wilhelmshöhe!

[S. L. (sldt)]

> Das hier funktioniert nicht - bei diesem Controller !
> ... RTC.CTRLA |= ...

Das kann an den fehlenden zwischengeschobenen Status-Abfragen liegen, 
siehe im Datenblatt '24.10 Synchronization': "it will take some RTC 
and/or peripheral clock cycles before an updated register value is 
available". Siehe auch mein (von C-hater gewünschtes) Programm von 
06.05.2024 16:49:
Beitrag "Re: AVR64EA28: PIT-Interrupt"

PS:
Erläuterung:
Für das 'RTC.CTRLA |=' muss es ja zuerst gelesen werden, zu diesem 
Zeitpunkt ist es aber noch gar nicht aktualisiert worden mit dem im 
vorherigen Befehl geschriebenen Wert.

PPS:
Und weil heute Feiertag ist, noch ein nettes Cartoon dazu.

[Georg M. (g_m)]

Veit D. schrieb:
> Dieses verodern funktioniert, am Ende eine Registerzuweisung der
> "Summe".
>

> uint8_t temp = 0;
> temp |= RTC_PRESCALER_DIV1024_gc;     // Prescaler 1024
> temp |= RTC_RUNSTDBY_bm;
> temp |= RTC_RTCEN_bm;                 // enabled
> RTC.CTRLA = temp;                     // set Config
>

>

Das ist nichts anderes als

  RTC.CTRLA = RTC_RUNSTDBY_bm | RTC_PRESCALER_DIV1024_gc | RTC_RTCEN_bm;

oder kurz gesagt

  RTC.CTRLA = 0xD1;

[Veit D. (devil-elec)]

Hallo,

natürlich ist das nichts anderes. Das soll es ja auch bezwecken.

[900ss (900ss)]

S. L. schrieb:
> PPS:
> Und weil heute Feiertag ist, noch ein nettes Cartoon dazu.

Der ist ziemlich gut :-))
Wünsche einen schönen Feiertag.

[Veit D. (devil-elec)]

S. L. schrieb:
>> Das hier funktioniert nicht - bei diesem Controller !
>> ... RTC.CTRLA |= ...
>
> Das kann an den fehlenden zwischengeschobenen Status-Abfragen liegen,
> siehe im Datenblatt '24.10 Synchronization': "it will take some RTC
> and/or peripheral clock cycles before an updated register value is
> available". Siehe auch mein (von C-hater gewünschtes) Programm von
> 06.05.2024 16:49:
> Beitrag "Re: AVR64EA28: PIT-Interrupt"
>
> PS:
> Erläuterung:
> Für das 'RTC.CTRLA |=' muss es ja zuerst gelesen werden, zu diesem
> Zeitpunkt ist es aber noch gar nicht aktualisiert worden mit dem im
> vorherigen Befehl geschriebenen Wert.

Kann ich bestätigen, funktioniert.

RTC.CTRLA |= RTC_PRESCALER_DIV1024_gc; 
while (RTC.STATUS > 0) { ; } 
RTC.CTRLA |= RTC_RUNSTDBY_bm;
while (RTC.STATUS > 0) { ; } 
RTC.CTRLA |= RTC_RTCEN_bm;

[Ob S. (Firma: 1984now) (observer)]

Gerhard H. schrieb:

> Wozu? Mit einem AVR I/O Register kann man nix direkt verodern.

Das ist nicht ganz richtig. Zumindest Die IO-Register mit den Adressen 
0..0x1f im IO-Space kann man zumindest mit einzelnen immediate Bits 
verodern. Siehe Asm-Instruktion "sbi".

Spielt aber beim vorliegenden Problem keine Geige, da die hier 
relevanten Register halt nicht in diesem Bereich liegen.

> Fakt ist, sein Code (Anhang) blinkt bei ihm nicht und bei mir schon.

Genau. Das ist der springende Punkt. Inzwischen (ich war 'ne Weile weg) 
hat S.L. ja auch noch herausgefunden, dass auch die Interrupts von TCA 
und TCB bei seinem Exemplar nicht funktionieren.

Also entweder hat er da schlicht ein defektes Exemplar erworben oder es 
ist an irgendwas "teilgestorben" oder es war ein Fake oder es gab eine 
sehr frühe Silizium-Revision mit noch schwereren Bugs als bei MC sowieso 
üblich.

Fake würde ich mal ausschließen, das lohnt nicht. Die EA haben irgendwie 
kein besonderes Feature, was sie von DA, DB oder DD nennenswert abheben 
würde. Zumindest kann ich keins erkennen, mag aber sein, dass ich 
irgendwas überlesen habe. Warum sollten ausgerechnet dafür Fakes 
produziert werden? Das lohnt doch sicher nicht.

Diese Revisionsgeschichte könnte man nur abklären, wenn entweder S.L. 
einen aktuellen Debug-Adapter kaufen würde und Studio7 oder MPLABX 
installieren würde oder halt dadurch, dass er selber das UPDI-Protokoll 
implementiert, um an den System Information Block heranzukommen.
Ersteres kostet leider etliches Geld, letzteres etliche Zeit. Ich habe 
volles Verständnis dafür, dass ihm der Einsatz eines EA das nicht Wert 
ist. So besonders ist der halt nicht, dass man ihn unbedingt verwenden 
wollen würde oder gar müsste.

[Gerhard H. (Gast)]

Ob S. schrieb:
> Das ist nicht ganz richtig. Zumindest Die IO-Register mit den Adressen
> 0..0x1f im IO-Space kann man zumindest mit einzelnen immediate Bits
> verodern.

OR iginelle Interpretation. Zumindest nicht ganz falsch :)

> oder es gab eine
> sehr frühe Silizium-Revision

Dazu passt der neuere Date-Code nicht.

> Die EA haben irgendwie
> kein besonderes Feature

Im ADC Teil gibts durchaus nette Neuigkeiten.
Speziell dafür Fakes lohnen natürlich nicht.

> mit noch schwereren Bugs als bei MC sowieso
> üblich

Die EA zeigen sich in den Errata eigentlich bereits recht zivilisiert.

> einen aktuellen Debug-Adapter kaufen würde und Studio7

kann ich auch nur empfehlen. Z.B. nEDBG auf einem entsprechenden 
Curiosity Nano Modul. Naheliegenderweise gleich
https://www.microchip.com/en-us/development-tool/ev66e56a

Kostet nicht die Welt. Der Kauf zur Debug-Verwendung unter Linux würde 
dann aber meines Wissens die Installation von MPLAB-X erfordern (rein 
programmiert ist das Teil auch via virtuellem USB-Laufwerk, da wird 
einfach die .hex reingezogen).

Mitsamt aktueller IDE wäre es dann ein Leichtes, an die interessanten 
Hardware-Daten heranzukommen. Ob die dann aber irgendeinen Aufschluss 
für diesen Fall liefern ist eine andere Frage.

Auf jeden Fall würd ich mir das Exemplar gut aufheben.
Sowas hat immer einen ganz besonderen Wert.
Schade daß es weiter kein Foto und nähere Infos zum Programmiertool 
gibt. Ungelöste Phänomene wie dieses dürften weiter Interesse 
garantieren.

[Ob S. (Firma: 1984now) (observer)]

Gerhard H. schrieb:

> Schade daß es weiter kein Foto und nähere Infos zum Programmiertool
> gibt.

Er hat ja gesagt, dass er das Studio4 verwendet. Aus dem Studio4 selber 
kommt nur UPDI via STK500v2-Wrapper in Frage. Wenn er zusätzlich zum 
Studio4 auch noch avrdude benutzt, werden die Möglichkeiten auch nicht 
sehr viel größer, da könnte man höchsten den Umweg über STK500v2 
einsparen.

Die eigentliche Programmierhardware dürfte in jedem Fall ein (minimal 
umgebauter) handelsüblicher USB-Seriell-Wandler mit CMOS-Pegeln sein.

[S. L. (sldt)]

an Gerhard Hauptmann:
> nähere Infos zum Programmiertool
Zwar verstehe ich nicht ganz, welche Rolle das spielt, wenn das aus dem 
Programmspeicher zurückgelesene Programm (bis auf die Sprungadressen) 
mit dem anderer Controllertypen übereinstimmt
(Beitrag "Re: AVR64EA28: PIT-Interrupt"), aber bitte: 
'Programmiertool' ist ein Selbstbau-Programmiergerät, basierend auf dem 
AVR128DA28, welches über ein PC-Hyperterminal Befehle und eben die 
Intel-Hex-Dateien empfängt; und mit dem ich z.B. auch den 'System 
Information Block' auslese
(Beitrag "Re: AVR64EA28: PIT-Interrupt");
den Vergleich mit den Werten, die Ihre IDE liefert
(Beitrag "Re: AVR64EA28: PIT-Interrupt")
überlasse ich Ihnen.

Übrigens musste ich deshalb auch nicht nachfragen, ob microchip.direct 
unprogrammierbare AVR16EB28 verkauft, weil ich für eben diese meine 
Firmware die SIGROW-Adresse auch bei 0x1080 (für die AVRmEBn, statt bei 
0x1100 wie für alle anderen) suchen lassen musste 
(Beitrag "Re: Verkauft microchipdirect unprogrammierbare AVR16EB28?").


PS:
Wenn Sie weiterhin mit C-hater diskutieren möchten, so ist das Ihr 
Vergnügen, meines nicht.

[Ob S. (Firma: 1984now) (observer)]

S. L. schrieb:

> 'Programmiertool' ist ein Selbstbau-Programmiergerät, basierend auf dem
> AVR128DA28

Wo genau hast du das das erste Mal erwähnt? Wenn mich nicht alles 
täuscht: Genau erst hier!

Und übrigens: die SIGROW ist NICHT identisch mit dem ausschließlich 
über UPDI auslesbaren Device Information Block.

Aber wenn du schon ein eigenes Programmiergerät am Start hast, kannnst 
du dem das sicher auch noch beibringen.

[Veit D. (devil-elec)]

Hallo,

eine grundsätzliche Frage an S.L.
Funktioniert nur dieses Programm auf deinem AVRxEA nicht oder kannst du 
flashen was du willst und es funktioniert überhaupt nichts? Weil das 
klingt fast danach. Schon einmal Python sprich pymcuprog probiert?

Ich kann bis jetzt flashen mit Atmel ICE und ich kann flashen mit 
pymcuprog & USB-Serial Wandler. Egal ob Kommandozeile oder aus Microchip 
Studio heraus.

Einen Eigenbau Programmer ala jtag2updi hatte ich mir auch mittels 
ATmega328PB gebaut. Klingt fast so als wenn du das mit AVRxDA gebaut 
hast. Bekomme ich aber mit avrdude zusammen mit dem AVR64EA32 noch nicht 
zum laufen. Connect mit ID auslesen funktioniert. Mehr auch nicht. Er 
schreibt das Programm und meckert dann wegen fehlender Target Power was 
es nicht prüfen kann. Der jtag2updi Programmer hat keinen VTG Pin wie 
ein Atmel ICE.
Nach dem Versuch muss alles Stromlos gemacht werden, weil sonst der 
Fehler mit falschen MCU Status erscheint. Mit Option -B 500 klappt es 
auch nicht.

avrdude -c jtag2updi -P com5 -p avr64ea32 -v -U flash:w:avr64ea32rtc.hex:i

Fehler

avrdude: Version 7.3
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is C:\avrToolchain\avrdude\avrdude.conf

         Using port            : com5
         Using programmer      : jtag2updi
         Programmer baud rate  : 115200
         Setting bit clk period: 500.0 us
         AVR Part              : AVR64EA32
         Programming modes     : UPDI, SPM
         Programmer Type       : JTAGMKII_UPDI
         Description           : JTAGv2 to UPDI bridge
         Main MCU HW version   : 1
         Main MCU FW version   : 6.00
         Sec. MCU HW version   : 1
         Sec. MCU FW version   : 6.00
         Serial number         : 00:00:00:00:00:00
avrdude: silicon revision: 2.1
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961f (probably avr64ea32)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip

avrdude: processing -U flash:w:avr64ea32rtc.hex:i
avrdude: reading input file avr64ea32rtc.hex for flash
         with 294 bytes in 1 section within [0, 0x125]
         using 3 pages and 90 pad bytes
avrdude: writing 294 bytes flash ...
Writing | #################################----------------- | 66% 0.23 s
avrdude jtagmkII_paged_write() error: bad response to write memory command: RSP_NO_TARGET_POWER
avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER
 ***failed;

Kann jemand dazu vielleicht Hinweise geben was falsch läuft?

[S. L. (sldt)]

nochmal an Gerhard Hauptmann:

"Und fragen Sie 'Ich bitte', warum ich das denn tu - 's ist mal bei mir 
so Sitte ..."
  Nachdem ich recht schnell meine STK200-Phase hinter mir gelassen 
hatte, programmierte ich die AVR8 mit einem Selbstbau-8085-System, 
danach folgte ein Programmiergerät mit einem ATmega644 bzw. ATmega1284P.
  Das heutige erlaubt mir gleichzeitigen Zugriff auf 3 zu 
programmierende Controller (von unterschiedlichem Typ), ermöglicht 
(rudimentäres) Debugging, stellt ein in weitem Bereich wählbares 
Rechtecksignal zur Verfügung sowie ein im Bereich etwas eingeschränktes 
Sinussignal, und misst Frequenzen und Perioden. Vier Spannungen und vier 
Strombegrenzungswerte. Anschluss über RS232 oder USB. Auf einem 
Lochrasterplatinchen 105*105, seit Mai 2020, genau vier Jahre.


an Veit Devil:
Die wenigen Dinge, die ich bislang auf dem AVR64EA28 probierte, 
funktionierten, solange sie eben keinen Interrupt beinhalten.

[900ss (900ss)]

Veit D. schrieb:
> Kann jemand dazu vielleicht Hinweise geben was falsch läuft?

Gibt ein Kapitel dazu in der jtag2upfi Beschreibung:
https://github.com/ElTangas/jtag2updi?tab=readme-ov-file#timeouts

[Veit D. (devil-elec)]

Hallo,

Danke, bin zwar der Meinung die aktuelle Version verwendet zu haben, 
kann es aber wiederholen und notfalls mit den Optionen spielt. Stimmt 
mich jedenfalls positiv. Danke nochmal.

@ S.L.
Okay verstehe. sei() haste ja nicht wie ich vergessen. ;-)
Wirklich seltsames Problem mit deinem Controller.

[S. L. (sldt)]

> sei() haste ja nicht ... vergessen.

Sonst wäre ja auch das (identische) Programm nicht auf den anderen 
Controller-Typen gelaufen.

[Gerhard H. (Gast)]

S. L. schrieb:
> programmierte ich die AVR8 mit einem Selbstbau-8085-System, danach
> folgte ein Programmiergerät mit einem ATmega644 bzw. ATmega1284P.
> Das heutige erlaubt mir gleichzeitigen Zugriff auf 3 zu programmierende
> Controller

Danke S.L. das klingt ja alles sehr ambitioniert, gemessen an meinem 
bescheidenen, fast nur offiziellen Atmel/Microchip- Toolset unter 
Windows. Welche Implikationen Ihr Equipment für diesen Fall hier haben 
könnte vermag ich nicht draus abzuleiten. Mein Interesse galt immer nur 
eigenen Projekten, nie dem Werkzeug zum Programmieren und Debuggen 
derselben. Damit bin ich allerdings stets hervorragend gefahren. Außer 
der Unbenutzbarkeit von ein paar China JTAG-USB Adaptern unter Studio7, 
welche mich in Einzelfällen noch zur Studio 4.19 Benutzung zwingen, gabs 
da nie Probleme.

Es sollte jedenfalls niemandem in den Sinn kommen, daß Sie Ihren EA-Test 
nicht mit der nötigen Fachkenntnis in Angriff genommen haben.

Würden Sie bitte vielleicht nun noch ein Foto Ihres widerspenstigen 
Kandidaten zum Vergleich für die Allgemeinheit zur Verfügung stellen?
Daß es sich um eine Fälschung handelt dürfte ja weiter im (immer 
kleineren) Kreis der Möglichkeiten anzusiedeln sein...

[S. L. (sldt)]

> Foto
Und auch hier muss ich Sie enttäuschen: ich gehöre zu den letzten 
Mohikanern, die ohne SmartPhone existieren (können).
  (und bin derzeit dabei, die beiden meterhohen Diakastensäulen zu 
sichten & zu entsorgen)

Aber ich kann bei meinem Controller keinen Unterschied zu dem Ihrigen 
erkennen, lediglich ist bei mir (auf der Unterseite) das Herstellerland 
in Großbuchstaben geschrieben, im Gegensatz zu Ihrer Angabe.

PS:
Und um der nächsten Frage gleich zuvorzukommen: ich werde ganz sicher 
nicht irgendjemanden bitten, mir sein SmartPhone zu leihen.

[Gerhard H. (Gast)]

S. L. schrieb:
> Herstellerland in Großbuchstaben geschrieben

Darauf hatte ich gar nicht geachtet,
ja es sind Großbuchstaben.

[S. L. (sldt)]

Okay, sieht bei mir genauso aus, auch die Orientierung der Schrift, nur 
ist unten eben 'P5' (statt des 'O5') eingeprägt.

[Gerhard H. (Gast)]

S. L. schrieb:
> Okay, sieht bei mir genauso aus, auch die Orientierung der Schrift, nur
> ist unten eben 'P5' (statt des 'O5') eingeprägt.

Alles keine äußeren Indizien für dunkle Machenschaften.
Es bleibt spannend. Wenn Ihr Ergebnis hier niemand reproduzieren kann 
umso mehr.

[S. L. (sldt)]

Bei der nächsten Bestellung (was aber noch länger dauern wird) werde ich 
die 2.77 für einen zweiten investieren, und auch gleich noch 2.55 für 
einen AVR32EA28 - wenn diese dann bei mir auch keinen Interrupt 
auslösen, liegt das Problem beim alten Landolt, dann können Sie alle 
drei haben, kostenlos.

[Gerhard H. (Gast)]

S. L. schrieb:
> Bei der nächsten Bestellung (was aber noch länger dauern wird) werde ich
> die 2.77 für einen zweiten investieren, und auch gleich noch 2.55 für
> einen AVR32EA28 - wenn diese dann bei mir auch keinen Interrupt
> auslösen, liegt das Problem beim alten Landolt, dann können Sie alle
> drei haben, kostenlos.

Ein schönes Angebot, welches ich aber sehr gerne an Bedürftigere als 
mich weiter gäbe. Ich hoffe viel eher Sie sind so ehrlich, das 
Bekanntwerden der Ursache und selbige hier auf den Tisch des Hauses zu 
packen :)

[900ss (900ss)]

Mein AVR64EA28 lag heute mit im Paket. Hab es gerade probiert. Die 
Variante von hier:

S. L. schrieb:
> Okay, nächster Versuch

funktioniert bei mir auch. Ich habe dann noch etwas rumgespielt, ich 
habe nichts entdeckt, was nicht meinen Erwartungen entspricht.
Auch mit sleep in der main läuft es wenn man den sleep nach Reset 
enabled. Er schläft auch, ich habe in der main an einem 2. Pin 
gewackelt. Die Periode ändert sich mit sleep dann so wie auch der 
IRQ-Pin wackelt.

Alles hübsch. Na ja, war schon zu erwarten.

So jetzt hab ich ein weiteres Mitglied in der AVR-Kiste. Mal sehen, wann 
ich den irgendwo hilfreich einsetzen kann :)

Nachtrag: Da ich Linux nutze: Ich habe AVRASM2 unter Wine genutzt zum 
übersetzen und AVRDUDE zum flashen per ATMEL-ICE.

[Gerhard H. (Gast)]

900ss schrieb:
> Auch mit sleep in der main läuft es wenn man den sleep nach Reset
> enabled.

Das werde ich in meinem Projekt gleich noch nachholen: Wenigstens ein 
produktives Ergebnis dieses Threads. Ich dachte immer mit der 
Sleep-Anweisung wäre es getan, nur der Sleep-Typ wäre ggf. noch zu 
konfigurieren. Warum es aber extra einzuschalten ist?

[900ss (900ss)]

Gerhard H. schrieb:
> nur der Sleep-Typ wäre ggf. noch zu konfigurieren

Das meinte ich mit "einschalten".

Also quasi das hier:

ldi     tmp0,0b00000_01_1                           ; standby, enable
sts     SLPCTRL_CTRLA,tmp0

[Gerhard H. (Gast)]

900ss schrieb:
> Gerhard H. schrieb:
>> nur der Sleep-Typ wäre ggf. noch zu konfigurieren
>
> Das meinte ich mit "einschalten".
> Also quasi das hier:
>
> ldi     tmp0,0b00000_01_1                           ; standby, enable
>
> sts     SLPCTRL_CTRLA,tmp0

Dabei wird nur die Assembler-Anweisung Sleep explizit aktiviert (Bit0) 
und konfiguriert (Bit1/2). Vorher ist sie wirkungslos. Dein Code allein 
schaltet noch keinen Schlafmodus ein.

[S. L. (sldt)]

an 900ss:
Auch wenn ich mittlerweile völlig überzeugt bin, dass es sich um ein 
singuläres Problem handelt, und nur für's Protokoll: was steht auf der 
Ober- und was auf der Unterseite Ihres AVR64EA28?

Und danke für die Mühe, die Sie sich bislang machten.

[900ss (900ss)]

Gerhard H. schrieb:
> Dein Code allein
> schaltet noch keinen Schlafmodus ein.

Ok, für Sie nochmal ausführlicher:
Folgende beiden Zeilen enablen den Sleep-Controller für den 
Standby-Sleep-Mode.

ldi     tmp0,0b00000_01_1                           ; standby, enable
sts     SLPCTRL_CTRLA,tmp0

Ist das nicht auch "Einschalten" des Sleep-Controllers? Und darum ging 
es mir weil Sie explizit fragten:

Gerhard H. schrieb:
> Warum es aber extra einzuschalten ist?

Ich habe nirgends geschrieben, dass der Controller damit in den 
Sleep-Mode wechselt. Ich schrieb sogar:

900ss schrieb:
> Auch mit sleep in der main läuft es wenn man den sleep nach Reset
> enabled.

Hier ist also explizit erwähnt, dass in der main-Loop ein sleep-Befehl 
existiert.

Ich bin mir sicher, dass Ihnen das auch vorher glasklar war.

[900ss (900ss)]

S. L. schrieb:
> was steht auf der
> Ober- und was auf der Unterseite Ihres AVR64EA28?

Hallo, habe jetzt zwei Fotos gemacht. Dann können Sie mit Ihrem 
Controller vergleichen.

S. L. schrieb:
> Und danke für die Mühe, die Sie sich bislang machten.

Gerne, hat mich halt auch gejuckt. :) Und ich konnte mich mal wieder 
etwas mit AVR-Assembler beschäftigen und hab auch noch was gelernt ;)

[Gerhard H. (Gast)]

900ss schrieb:
> Ok, für Sie nochmal ausführlicher

Für Dich ganz knapp: Kein Grund zur Aufregung.
Hab die Sachlage nur auf den Punkt bringen wollen.
Wir können zum eigentlichen Phänomen zurückkehren:

900ss schrieb:
> Hallo, habe jetzt zwei Fotos gemacht. Dann können Sie mit Ihrem
> Controller vergleichen.

Derselbe Date-Code.

S. L. schrieb:
> Date-Code des verwendeten AVR64EA28: 2326URR

[900ss (900ss)]

Gerhard H. schrieb:
> Hab die Sachlage nur auf den Punkt bringen wollen.

Wer's glaubt...

[Gerhard H. (Gast)]

900ss schrieb:
> Wer's glaubt...

Glauben ist nicht Wissen :)

Aber zum Phänomen zurück:
Der Vergleich der Beschriftung und mutmaßlich des von S.L. bereits 
beobachteten Aussehens spricht wohl gegen eine Fälschung- auch wenn just 
das entscheidende Puzzle-Teil-Foto des fraglichen Controllers unmöglich 
scheint.

Ob wir den Grund dieser Interrupt-Dysfunktionalität jemals erfahren?

[S. L. (sldt)]

Um die (mittlerweile ausufernde) Angelegenheit abzuschließen:
  Ich danke für die Angebote, aber dieses Controllerexemplar gebe ich 
vorläufig nicht aus der Hand. Wie bereits geschrieben, werde ich bei der 
nächsten Gelegenheit zwei EA mitbestellen, danach hier Bericht 
erstatten.

Dass Zweifel aufkommen an meiner ungewöhnlichen IDE, das kann ich 
nachvollziehen, aber die Zweifler mögen mir bitte konkret sagen, was ich 
noch unternehmen bzw. woran es liegen könnte.
  Im Anhang befindet sich nochmals eine Testversion für dieses 
Interrupt-Problem: eine LED an PA6 flimmert, gerade noch erkennbar, mit 
25 Hz bei einem AVR16EB28 sowie mit 30 Hz bei einem AVR128DA28, beim 
AVR64EA28 bleibt sie dunkel. Wenn ich mir die Programmspeicherabzüge 
(flash-dumps) ansehe, so sind sie gleich, zwischen dem EB und dem EA 
sogar identisch - ich kann das für den EA assemblierte Intel-Hex-File 
auf den EB flashen, und das Programm läuft dort.

Ich danke allen, die hier ihre Zeit und Energie (und in einem Fall sogar 
Geld) investiert haben, und wünsche ein schönes Wochenende.

[Gerhard H. (Gast)]

S. L. schrieb:
> konkret sagen, was ich
> noch unternehmen bzw. woran es liegen könnte

Aus dem was Ihre veröffentlichte Diagnose hier an Luft übrig lässt 
eigentlich nur: Aktuelle Software, aktuelle Hardware nehmen so wie 
jeder, der hier zu einem anderen Ergebnis kommt. Jener wird Ihnen dann 
leider gleichfalls kaum sagen können, was mit Ihrem (eigenen) Equipment 
älteren Datums schief läuft.
Daß ein Chip den von Ihnen beschriebenen Schaden hat ist in zweierlei 
Hinsicht unwahrscheinlich: Erstens traue ich Ihnen genügend Erfahrung zu 
diesen sachgerecht behandelt zu haben. Zweitens wäre das Durchrutschen 
eines solchen Fehlers bei der Microchip Endkontrolle ja äußerst 
beunruhigend: Dann würde man nie genau wissen ob der Controller den man 
da aus seriöser Quelle kauft vertrauenswürdig wäre. Ich glaube das deckt 
sich mit keinerlei Erfahrung. Meiner jedenfalls nicht.
Nun bliebe leider nur noch (das würden Sie sicher empört zurückweisen 
und ich hielte es bei Ihrem Engagement auch für absolut unglaubwürdig), 
daß uns hier jemand an der Nase herumführt...

> Wie bereits geschrieben, werde ich bei der
> nächsten Gelegenheit zwei EA mitbestellen, danach hier Bericht
> erstatten.

In der Erwartung auf neue Erkenntnisse - schönes Wochenende auch Ihnen!

[900ss (900ss)]

S. L. schrieb:
> beim AVR64EA28 bleibt sie dunkel

Posten Sie doch bitte einmal den passenden Hexfile zu dem EA. Ich werde 
den hier mal flashen. Mal schauen was passiert. Ich glaube nicht dass es 
am Hexfile liegt, aber.....

Noch mehr der EA hier auf dem Tisch ;)

[S. L. (sldt)]

Bitte ...

[900ss (900ss)]

S. L. schrieb:
> beim
> AVR64EA28 bleibt sie dunkel

Ich habe den File geflasht und mit dem Oszilloskop gemessen an PA6. Ich 
messe ein Rechtecksignal mit 40ms Periodendauer. Sind also ca. 25Hz ;)

[S. L. (sldt)]

> 25Hz

Wie beim EB: 20 MHz /6 /65536 /2 = 25.43 Hz.

[900ss (900ss)]

S. L. schrieb:
>> 25Hz
>
> Wie beim EB: 20 MHz /6 /65536 /2 = 25.43 Hz.

Mein HP Frequenzzähler sagt 25.33Hz. Mein EA läuft zu langsam ;)

Ja das ist alles merkwürdig.
Man muss alles in Frage stellen. Den EA natürlich, den Aufbau. Ist er 
identisch mit den anderen Controllern? Gleiches Netzteil? Und natürlich 
auch Ihren selbstgebauten Programmer. Auch wenn dieser bei den anderen 
Controllern funktioniert.
Der Programmer scheint ok zu sein. Aber....

Wenn Sie aber eh neue EA-Controller kaufen, würde ich solange warten. 
Das schließt diesen dann eben aus oder auch nicht.

[S. L. (sldt)]

> ... Aufbau. Ist er identisch ...
Ich stecke lediglich die Controller auf dem Steckbrett um.

PS:

an Gerhard H.:
> daß uns hier jemand an der Nase herumführt

Das meinen Sie jetzt nicht wirklich, oder? Glauben Sie im Ernst, ich 
(oder irgendjemand) könnte tatsächlich über einen solchen Thread mit 150 
Beiträgen etwas vorlügen, ohne sich irgendwo zu verraten?

[900ss (900ss)]

S. L. schrieb:
> Ich stecke lediglich die Controller auf dem Steckbrett um.

Das ist echt verhext. Ich hab das nicht geprüft, die sind also 
Pin-kompatibel?

Und dann sei mir eine Anmerkung erlaubt: Sie haben beide VDD und 
GND-Anschlüsse des Controllers angeschlossen und auch einen 
Abblock-Kondensator angeschlossen?

Bitte nicht falsch verstehen. Es könnte sein dass einige Controller 
toleranter reagieren auf solche "Fehlerchen". Der EA aber doch nicht 
will. Ich glaub es auch nicht, aber....
Was man nicht geprüft hat, weiß man nicht. Das ist meine Erfahrung.

[900ss (900ss)]

900ss schrieb:
> die sind also Pin-kompatibel?

Gerade selber mal für den AVR16EA28 geprüft. Ja sind zu 100% 
pinkompatibel.

[S. L. (sldt)]

> ... Anschlüsse des Controllers ... angeschlossen
So ist es, incl. zweier 100 nF Kondensatoren.

> Ja sind zu 100% pinkompatibel.
Wie auch AVR128DA28, AVR128DB28, AVR32DD28; nur dass die beiden 
letztgenannten statt PD0 VDDIO2 haben.

PS:
> Anschlüsse
Wäre auch ein seltsamer Fehler, denn der EA läuft ja im Prinzip, die LED 
an A7 glimmt, mit ca. 550 kHz.

[900ss (900ss)]

S. L. schrieb:
> So ist es, incl. zweier 100 nF Kondensatoren.

Da war ich geiziger, hab nur einen ;) Habe aber eben gelesen, dass es 
zwei sein sollen.

Das Steckbrett... ich baue da auch hin und wieder was mit. Aber wenn die 
Schaltung nicht funktioniert, dann fliegt das als erstes in die Ecke und 
ich baue es auf Lochraster. Habe ich hier für den EA jetzt auch gemacht. 
Ein IC-Sockel, 1 Kondesnsator und eine Pfostenleiste und da alles 
notwendige angeschlossen.

[900ss (900ss)]

S. L. schrieb:
> Wäre auch ein seltsamer Fehler

Das stimmt, aber das ganze Problem ist seltsam. Und ich persönlich fange 
dann an, solche Sachen in Frage zu stellen.

[S. L. (sldt)]

> Steckbrett ... fliegt ... als erstes in die Ecke
Da sind die Erfahrungen offenbar unterschiedlich: C-hater verstieg sich 
einmal sogar zu der Behauptung, er könne seine nur wenige Male benutzen, 
'Einmal-Wegwerf-Steckbretter' sozusagen; ich hingegen hatte meine ersten 
vom Recyclinghof, und die hielten sehr lange, bis irgendwann manche 
Vielbeiner (Controller etc.) manchmal heraussprangen, dann kaufte ich 
neue - aber Kontaktprobleme hatte ich nie.

[Gerhard H. (Gast)]

S. L. schrieb:
> Das meinen Sie jetzt nicht wirklich, oder?

Nein, das meine ich jetzt nicht wirklich. Genau wie ich geschrieben 
habe.

> Ich stecke lediglich die Controller auf dem Steckbrett um.

Puh. Sowas hatte ich noch nie im Einsatz. Immer alles festverlötet. 
Allenfalls mit Präzisions-IC Sockel.

Haben Sie sich da vielleicht mal ver-steckt?

[S. L. (sldt)]

> Haben Sie sich da vielleicht mal ver-steckt?
Mal versteckt? Das könnte ja nur beim allerersten Programmierversuch 
gewesen sein, damals noch beim PIT-Interrupt aus dem sleep heraus - 
das schließe ich aus; außerdem steht die Strombegrenzung auf 22 mA.

> Puh. Sowas hatte ich noch nie im Einsatz. Immer alles festverlötet.
Puh! Entwicklung fest verlötet - da käme ich auf keinen grünen Zweig.

[Gerhard H. (Gast)]

S. L. schrieb:
> das schließe ich aus

Kann es sein daß Sie inzwischen alles ausgeschlossen haben, es aber 
trotzdem nicht funktioniert?

Nun ich vermute ein wenig enttäuscht, wir werden den Grund hier nicht 
mehr erfahren - der irgendwo in einem äußerlich undurchsichtigen 
Potpourri von veralteter IDE, eigenen Programmern und Steckbrettern vom 
Recyclinghof verborgen  sein muß.

Dabei hätten Effekte wie selektive Interrupt-Unfähigkeit das Zeug zu 
ganz großen Erkenntnissen :)

[Georg M. (g_m)]

Funktioniert bei einem Mikrocontroller der Interrupt nicht, so liegt ein 
Sachmangel im Sinne von § 433 BGB vor.
In diesem Fall ist der Käufer berechtigt, einen Teil des Kaufpreises 
zurückzuverlangen.

§ 434 BGB Sachmangel
§ 437 BGB Rechte des Käufers bei Mängeln
§ 441 BGB Minderung

[Gerhard H. (Gast)]

Georg M. schrieb:
> Funktioniert bei einem Mikrocontroller der Interrupt nicht, so liegt ein
> Sachmangel im Sinne von § 433 BGB vor

Deine Rechts-Belehrung, die unmöglich auf einen in (unsachgemäßem) 
Gebrauch befindlichen Mikrocontroller anwendbar ist rundet diesen 
abstrusen Fall gekonnt ab. Dazu müsstest Du doch einen Serien-Fehler 
nachweisen können- genau danach schaut es nur leider nicht aus.

[Volker B. (Firma: L-E-A) (vobs)]

S. L. schrieb:
> Zwar kein Speicherabzug, aber die Intel-Hex-Datei ist genausogut: wenn
> ich Ihr EATEST.hex in den AVR16EB28 flashe, blinkt die LED, bei meinem
> AVR64EA28 blinkt sie nicht.

Ich bin etwas erstaunt. Lt. Datenblatt sind die IRQ-Vector Adressen für 
RTC_PIT der beiden MCUs unterschiedlich:

AVR64EA28/32/48:    Vector #5, Addr.: 0x0A
AVR16EB14/20/28/32: Vector #4, Addr.: 0x08

Was für mich bedeutet, dass der identische Binärcode für den 
RTC-PIT-Interrupt nicht auf beiden MCUs lauffähig sein kann!

EATEST.lss:

                                 .org    RTC_PIT_vect
00000a ef0f                          ldi     tmp0,$FF
00000b 9300 0153                     sts     RTC_PITINTFLAGS,tmp0
00000d 9a17                          sbi     IN_LED,LED
00000e 9518                          reti

Bist Du Dir sicher, dass Deine IDE den RTC_PIT-Interrupt auf den 
korrekten Vector mappt?

Grüßle,
Volker

[S. L. (sldt)]

> Bist Du Dir sicher, dass Deine IDE den RTC_PIT-Interrupt
> auf den korrekten Vector mappt?

Ja; wie aus den flash-dumps, die in einigen der Programme unten 
angehängt sind, zu ersehen ist.

Zu dem merkwürdigen Verhalten bei 'EATEST.hex -> AVR16EB28': warum die 
LED trotzdem auf dem EB einwandfrei blinkt - gute Frage, der EB springt 
ja mitten in den Befehl 'sts RTC_PITINTFLAGS,tmp0' hinein.

Beim zuletzt untersuchten TCB0 und seinem Interruptvektor sind die 
Adressen übrigens gleich: 0x001A, sowohl bei EA als auch bei EB.

PS:
> Bist Du Dir sicher ...
Das hat ja erstmal nichts mit meiner IDE zu tun: das EATEST.hex von 
Gerhard H. lässt auf einem EB die LED an PA7 blinken (warum auch immer).

[Gerhard H. (Gast)]

Volker B. schrieb:
> Was für mich bedeutet, dass der identische Binärcode für den
> RTC-PIT-Interrupt nicht auf beiden MCUs lauffähig sein kann!

S. L. schrieb:
> lässt auf einem EB die LED an PA7 blinken

Das hab ich selber flugs mal überprüft.
Die PA7-LED blinkt mit selbigem EA Code auch auf dem EB.
Trotz verschiedenem PIT-Vektor.

[Gerhard H. (Gast)]

S. L. schrieb:
> der EB springt
> ja mitten in den Befehl 'sts RTC_PITINTFLAGS,tmp0' hinein

Nein da täuscht Du Dich.
Der Einsprung-Vektor wird hier ja nicht durch Software sondern durch die 
Hardware bestimmt: Der EB-PIT Einsprung erfolgt 1 Vektor-Position vor 
der EA-PIT Position und gelangt so dennoch an den vollständigen 
ISR-Code. Insofern ist alles OK mit der Lauffähigkeit auf beiden 
Controllern.

[S. L. (sldt)]

Korrekt.
  Der EB springt auf 0x0008 und führt dort, vor der eigentlichen ISR, 
zweimal den Befehl FFFF aus, der erfahrungsgemäß wie ein nop (0000) 
arbeitet.

[Knut B. (Firma: TravelRec.) (travelrec)]

Deswegen arbeite ich mit für jeden Controller spezifischer und 
kompletter Vektor-Tabelle. Immer.

[Gerhard H. (Gast)]

Knut B. schrieb:
> Deswegen arbeite ich mit für jeden Controller spezifischer und
> kompletter Vektor-Tabelle. Immer.

Meine Rede.

Gerhard H. schrieb:
> Eine komplette Interruptvektortabelle dient Ordnung, Übersicht,
> Codewiederverwendbarkeit und Sicherheit: Irrtümlich aktivierte
> Interrupts werden nämlich sicher abgefangen.

Insbesondere verhält sich Interrupt-Code  dann controller-eindeutig. Die 
LED wäre auf dem "falschen" Controller schlicht stumm geblieben. Für den 
Platz den man damit zu verschenken glaubt spare ich mir lieber den Text 
bemühten Vereinfachens über die ganze Umdefiniererei von Registern. 
Warum ein tmp0 erfinden wenn man gleich direkt das Register, z B. r16 
hinschreiben und daraus sofort ersehen kann was damit geht? Warum ein 
IN_LED kreieren wenn mit VPORTA_IN,x im Code viel klarer ist wo jetzt 
genau die Musik spielt? Naja, jeder wie er mag.

[Veit D. (devil-elec)]

Hallo,

@ Knut
Warum extra Tabelle schreiben? Steht alles im Headerfile drin.

@ Gerhard H.
IN_LED vs. VPORTA_IN
Das macht schon Sinn. Muss man den Pin ändern, ändert man das Programm 
nur an einer Stelle und muss nicht das gesamte Programm ändern. Es wird 
überall das gleiche Register verwendet. Mal abgesehen von "Rename" 
Möglichkeiten der IDE. Hat man irgendwo einen Tippfehler hilft auch 
keine Rename Möglichkeit. Da wäre man wieder beim Vorteil von "IN_LED" 
und klare sprechende Namen.

[Gerhard H. (Gast)]

Veit D. schrieb:
> Steht alles im Headerfile drin.

Das kann man sich für solche Zwecke natürlich einrichten und 
inkludieren. Ggf. mitsamt diverser Initialisierungen.
Stichwort Code-Wiederverwendbarkeit.

> Muss man den Pin ändern, ändert man das Programm nur an einer Stelle und
> muss nicht das gesamte Programm ändern.

Zu ändern ist doch höchst selten was wenn die Hardware (normalerweise) 
vorab fertig ist.

> Hat man irgendwo einen Tippfehler

Mit Ruhe und Bedacht vom Kleinen zum Großen entwickelnd und dabei stets 
neu assemblierend sind Tippfehler schnell aufgedeckt und beseitigt.

> klare sprechende Namen

Ich lasse lieber einen kurzen Kommentar daneben sprechen.

OK- die sprachlichen Möglichkeiten sind vielfältig- von bedingter 
Assemblierung, sprechenden Namen bis extensivem Makro- Einsatz. Ich 
bevorzuge eher minimalste, direkte, unverdeckte, nicht weiter 
erklärungsbedürftige Ausdrucksformen. Wer sich bei Asm dagegen mit 
möglichst viel "Komfort" einer Hochsprache annähern möchte sollte besser 
gleich das Original wählen.

[Peter D. (peda)]

S. L. schrieb:
> Das kann an den fehlenden zwischengeschobenen Status-Abfragen liegen,
> siehe im Datenblatt '24.10 Synchronization': "it will take some RTC
> and/or peripheral clock cycles before an updated register value is
> available".

Das erinnert mich an den asynchronen Timer T1 des ATtiny861.
Sehr erstaunt war ich, daß nach Löschen des Interrupts und Freigabe 
sofort der Interrupthandler angesprungen wurde. Ich mußte noch 2 NOPs 
dazwischen einfügen, bis alle Bits aktualisiert waren. Grund sind die 
Synchronisationsregister, da T1 auch mit der PLL 64MHz laufen kann 
(siehe Bild). Diese Register sind auch dann wirksam, wenn T1 mit F_CPU 
getaktet wird. Die PLL hatte ich ja nicht benutzt.
Bei den AVRs mit T2 als RTC gibt es ähnliche Effekte. Nur ist dann der 
RTC-Takt wesentlich langsamer als der CPU-Takt.

[S. L. (sldt)]

Zwar habe ich Zweifel, dass sich noch jemand interessiert, zumal auch 
der Hauptinteressent offenbar "über alle Berge" ist, aber ich hatte nun 
mal versprochen, mich wieder zu melden, und Ordnung muss sein, also:

Ich habe nun einen weiteren AVR64EA28 sowie einen AVR32EA28 vorliegen, 
und auch der zweite 64er funktioniert nicht, der 32er jedoch 
einwandfrei. Da mir von anderer Seite versichert wurde, dass die 64er in 
Ordnung sind, liegt es wohl an meiner ganz speziellen IDE (warum auch 
immer), aber solange es keine Probleme mit den AVR32EA28 gibt, kann ich 
damit leben.

[Mi N. (msx)]

S. L. schrieb:
> liegt es wohl an meiner ganz speziellen IDE

Es gab doch weiter oben eine .hex-Datei, die laufen sollte und nichts 
mit Deiner IDE zu tun hat. Läuft die auch nicht?

S. L. schrieb:
> Zwar habe ich Zweifel, dass sich noch jemand interessiert

Es ist und bleibt interessant, wenn man diese µCs mal brauchen sollte.

[S. L. (sldt)]

Ich habe alles Mögliche versucht (ist ja auch über die 170 Beiträge 
hinweg nachzulesen), .hex-Dateien hin&her geschoben zwischen AVR64EA28 
und AVR32EA28 sowie auch AVR16EB28, habe Speicherabzüge verglichen und 
was nicht alles, ohne einen Schritt weiterzukommen - "austherapiert", 
würde ein Mediziner sagen.
  Es muss wohl oder übel irgendwo bei mir liegen, aber ich komme nun mal 
nicht dahinter, wo genau.

[Veit D. (devil-elec)]

Hallo,

diese beiden Programme lassen jeweils die Led an PA3 blinken.

[Georg M. (g_m)]

Veit D. schrieb:
> diese beiden Programme lassen jeweils die Led an PA3 blinken.

Dieses auch:

#include <avr/io.h>
#include <avr/interrupt.h>

ISR(RTC_PIT_vect)
{
  PORTA.OUTTGL = PIN3_bm;
  RTC.PITINTFLAGS = RTC_PI_bm;
}

int main(void)
{
  PORTA.DIRSET = PIN3_bm;

  RTC.CLKSEL = RTC_CLKSEL_INT1K_gc;
  while(RTC.PITSTATUS > 0) {}
  RTC.PITINTCTRL = RTC_PI_bm;
  RTC.PITCTRLA = RTC_PERIOD_CYC1024_gc | RTC_PITEN_bm;

  sei();

  while(1)
  {

  }
}

[S. L. (sldt)]

Mais oui, Veit Devil: ich habe die b-Version gewählt (aber auch nur 
Ihnen zuliebe, mein Metier ist Assembler), und die blinkt auf meinem 
32er, aber nicht auf dem 64er.

Aber lassen Sie uns nicht alles seit dem 02. Mai wiederholen - Sie 
finden im Verlauf genügend andere und einfachere Beispiele. Ohne 
wirklich neue Erkenntnisse ist für mich an dieser Stelle Schluss.

[Veit D. (devil-elec)]

Hallo,

bei mir blinkt es auf einem AVR64EA32.
Bei dir auf einem AVR32EA28, aber nicht auf einem AVR64EA28.
Das mutet seltsam an.  :-)

Deine Toolchain ist aber soweit okay?
Device Packs sind aktuell?

[S. L. (sldt)]

Um genau zu sein: blinkt auf meinem einzigen AVR32EA28, aber nicht auf 
den beiden AVR64EA28.
  Alles Weitere aber können Sie (viel) weiter oben nachlesen.