AVR64EA28: PIT-Interrupt

S. L. schrieb:

Irgendetwas scheint bei diesem Controller anders zu sein

Verglichen womit?

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

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

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

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.

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.

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)

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.

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.

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. ;)

an 900ss:

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

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.

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.

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'.

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.

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

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.

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 ;)

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.

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 :)

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').

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.

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...

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'.

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.

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.

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.

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.

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 :)

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.

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

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.

Dann laden Sie mal das aktuelle herunter:

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

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

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.

Und ich war Ihrem Hinweis sofort nachgegangen.

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

1

#include <avr/io.h>

2

3

int main(void)

4

{

5

  PORTA.DIRSET = PIN3_bm;

6

7

  RTC.CLKSEL = RTC_CLKSEL_INT1K_gc;

8

  while(RTC.PITSTATUS > 0) {}

9

  RTC.PITCTRLA = RTC_PERIOD_CYC1024_gc | RTC_PITEN_bm;

10

11

  while(1)

12

  {

13

    if(RTC.PITINTFLAGS)

14

    {

15

      RTC.PITINTFLAGS = RTC_PI_bm;

16

      PORTA.OUTTGL = PIN3_bm;

17

    }

18

  }

19

}

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?

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.

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

? Ich dachte, ich hätte das aktuelle?

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

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/.

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.

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.

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.

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...

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.

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...

... 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. 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...

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'

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.

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. 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.

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 ...?

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. 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...

Also wenn es der SIB ist:

1

AVR64EA28:

2

41 56 52 20 20 20 20 20 50 3A 33 44 3A 31 2D 33

3

ein alter AVR128DA28:

4

20 20 20 20 41 56 52 20 50 3A 32 44 3A 31 2D 33

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. 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.

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

1

AVR64EA28:

2

41 56 52 20 20 20 20 20 50 3A 33 44 3A 31 2D 33

3

A  V  R                 P  :  3  D  :  1  -  3

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.

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?

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.

S. L. schrieb:

mein AVR64EA28 (und ich habe nur den einen) scheint generell keine Interrupts auszulösen.

Diese Codezeilen verstehe ich nicht:

1

    lds     tmpi,TCA0_SINGLE_INTFLAGS

2

    sts     TCA0_SINGLE_INTFLAGS,tmpi

3

...

4

    lds     tmpi,TCB0_INTFLAGS

5

    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. 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

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'

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. 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...

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?

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. :(

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.

Veit D. schrieb:

Weder der RTC- noch der PIT ISR Interrupt funktionieren.

1

 sei();

Georg M. schrieb:

Veit D. schrieb:

Weder der RTC- noch der PIT ISR Interrupt funktionieren.

1

>  sei();

2

>

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

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]

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

1

rtcstatus

2

    ldi     tmp0,0b0_1101_00_1          ; /16384 + enable

3

    sts     RTC_PITCTRLA,tmp0

zusammen zuweisen.

Hallo,

hattest du meine Dateien gelesen?

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

1

uint8_t temp = 0;   

2

temp |= RTC_PRESCALER_DIV1024_gc;     // Prescaler 1024

3

temp |= RTC_RUNSTDBY_bm;

4

temp |= RTC_RTCEN_bm;                 // enabled  

5

RTC.CTRLA = temp;                     // set Config

Das hier funktioniert nicht - bei diesem Controller !

1

RTC.CTRLA |= RTC_PRESCALER_DIV1024_gc;  // Prescaler 1024

2

RTC.CTRLA |= RTC_RUNSTDBY_bm;

3

RTC.CTRLA |= RTC_RTCEN_bm;                 // enabled

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.

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. :-)

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!

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.

Veit D. schrieb:

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

1

> uint8_t temp = 0;

2

> temp |= RTC_PRESCALER_DIV1024_gc;     // Prescaler 1024

3

> temp |= RTC_RUNSTDBY_bm;

4

> temp |= RTC_RTCEN_bm;                 // enabled

5

> RTC.CTRLA = temp;                     // set Config

6

>

Das ist nichts anderes als

1

  RTC.CTRLA = RTC_RUNSTDBY_bm | RTC_PRESCALER_DIV1024_gc | RTC_RTCEN_bm;

oder kurz gesagt

1

  RTC.CTRLA = 0xD1;

Hallo,

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

S. L. schrieb:

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

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

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.

1

RTC.CTRLA |= RTC_PRESCALER_DIV1024_gc; 

2

while (RTC.STATUS > 0) { ; } 

3

RTC.CTRLA |= RTC_RUNSTDBY_bm;

4

while (RTC.STATUS > 0) { ; } 

5

RTC.CTRLA |= RTC_RTCEN_bm;

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. 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.

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.

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.

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.

1

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

Fehler

1

avrdude: Version 7.3

2

         Copyright the AVRDUDE authors;

3

         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

4

5

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

6

7

         Using port            : com5

8

         Using programmer      : jtag2updi

9

         Programmer baud rate  : 115200

10

         Setting bit clk period: 500.0 us

11

         AVR Part              : AVR64EA32

12

         Programming modes     : UPDI, SPM

13

         Programmer Type       : JTAGMKII_UPDI

14

         Description           : JTAGv2 to UPDI bridge

15

         Main MCU HW version   : 1

16

         Main MCU FW version   : 6.00

17

         Sec. MCU HW version   : 1

18

         Sec. MCU FW version   : 6.00

19

         Serial number         : 00:00:00:00:00:00

20

avrdude: silicon revision: 2.1

21

avrdude: AVR device initialized and ready to accept instructions

22

avrdude: device signature = 0x1e961f (probably avr64ea32)

23

avrdude: Note: flash memory has been specified, an erase cycle will be performed.

24

         To disable this feature, specify the -D option.

25

avrdude: erasing chip

26

27

avrdude: processing -U flash:w:avr64ea32rtc.hex:i

28

avrdude: reading input file avr64ea32rtc.hex for flash

29

         with 294 bytes in 1 section within [0, 0x125]

30

         using 3 pages and 90 pad bytes

31

avrdude: writing 294 bytes flash ...

32

Writing | #################################----------------- | 66% 0.23 s

33

avrdude jtagmkII_paged_write() error: bad response to write memory command: RSP_NO_TARGET_POWER

34

avrdude jtagmkII_write_byte() error: bad response to write memory command: RSP_NO_TARGET_POWER

35

 ***failed;

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

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.

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

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.

sei() haste ja nicht ... vergessen.

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

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.

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

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.

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. schrieb:

nur der Sleep-Typ wäre ggf. noch zu konfigurieren

Das meinte ich mit "einschalten".

Also quasi das hier:

1

ldi     tmp0,0b00000_01_1                           ; standby, enable

2

sts     SLPCTRL_CTRLA,tmp0

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.

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.

1

ldi     tmp0,0b00000_01_1                           ; standby, enable

2

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.

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. schrieb:

Hab die Sachlage nur auf den Punkt bringen wollen.

Wer's glaubt...

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.

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 ;)

Bitte ...

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 ;)

25Hz

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

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.

... 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?

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 schrieb:

die sind also Pin-kompatibel?

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

... 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.

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.

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.

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.

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.

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

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:

1

                                 .org    RTC_PIT_vect

2

00000a ef0f                          ldi     tmp0,$FF

3

00000b 9300 0153                     sts     RTC_PITINTFLAGS,tmp0

4

00000d 9a17                          sbi     IN_LED,LED

5

00000e 9518                          reti

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

Grüßle, Volker

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).

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.

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

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.

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.