Assembler AVR Studio 6.1 - Register initialisiert falsch

[Uwe H.]

Hallo zusammen,

ich hab mal angefangen, mich mit Assembler zu beschaeftigen und schreibe grad mein erstes Programm. Um den Spass schnell zu verlieren und Gruende zum Fluchen zu finden, hab ich mir direkt ein kompliziertes Projekt vorgenommen Und hier auch schon das Problem:

ldi r16, 1<<PCIE ;Pin Change Interrupts on/Int0|Int1 off
out GIMSK, r16

Um ein sauberes Programm zu schreiben, initialisiere ich alle Register, die einen Interrupt aktivieren koennen, nochmal manuell neu. Dieser Block initialisiert das Register fuer externe Interrupts und soll INT0/INT1 abschalten und Port Change Interrupts zulassen. Dazu soll Bit.5 auf eins gesetzt werden. Wenn ich die Codezeile nun im Simulator ausfuehre, steht im Register anschliessend 0x08. Das ist theoretisch nicht moeglich, da nur Bit 7-5 manipulierbar sind, der Rest ist ohne Funktion. Die gleiche Ladeanweisung anders formuliert (ldi r16, 0b00100000) brachte ebenfalls dasselbe Ergebnis. Was soll der Mist? *lol*

Gruesse, Uwe


P.S.: Diese Frage hab ich auch bei mikrocontroller.net gepostet

 

[LotadaC]

Welcher Controller ist inkludiert (also welche Definitionsdatei)?
Was ist dort der Compilervariable PCIE zugewiesen?
Und was GIMSK?

 

[Uwe H.]

Targetplattform ist ein Attiny2313. In der Headerdatei hab ich den equ dafuer nicht finden koennen. Aber auch wenn ich

ldi r16, 0b00100000
out GIMSK, r16

simuliere, schreibt er mir 0x08 ins Register

 

[Uwe H.]

Jetzt hab ich mal Bit.4 gesetzt, was eigentlich nicht besetzt sein sollte und er schreibt mir 0x20 ins Register und Bit.5 ist markiert. R16 wurde mit 0x10 geladen und zeigt diese auch an... Jetzt versteh ich garnichts mehr. Ist nun das Datenblatt falsch oder spinnt der Simulator?

 

[LotadaC]

Wenn die nirgends definiert sind, muß der Assembler meckern. Daß der direkte Binärwert dasselbe falsche Ergebnis liefert, ist ... verwirrend.
Was ist, wenn Du die entsprechende Dezimalzahl verwendest (32)?
Hast Du mal andere I/O-Register versucht (der Tiny hat ja nur Register bis 0x3F)?
Hast Du mal das Register mit der Adresse angesprochen (0x3B)?
(Oder mittels STS - aber hier mit 0x5B).

Hast Du mal'ne ältere Version des Studios verwendet? Ich könnte lediglich mit 4.18(irgendwas) oder 5.irgendwas gegentesten - hatte aber noch nie solche Probleme (Lediglich mal das "1<<" in den Klammern vergessen, und mich über das komische Verhalten der echten Hardware gewundert. Das Oszillogramm zeigte dann, daß genau auf die falsche Flanke eines Interruptes getriggert wurde, also war klar, wo der Fehler im Code zu suchen war...)

Nachtrag: Der Tiny2313A hätte 3 PCIE-Bits (5, 3 und 4) - allerdings würden dann in der Definitionsdatei auch PCIE0, PCIE1 und PCIE2 definiert werden. Und das wären immer noch keine Erklärungen für die direkt vorgegebenen Zahlen.

Was hast Du als Device für den Simulator ausgewählt, und was konkret im Sourcecode inkludiert?
Was wird dort als unterstütztes Device angegeben?
Und was sind die, dort zu findenden Werte für die verwendeten Variablen/Konstanten?

Daß mit LDI R16, konkrete Zahl irgendwas anderes in R16 landet, kann ich mir schlichtweg nicht vorstellen.

 

[Uwe H.]

Nein, nein, R16 laedt korrekt. Wenn ich 1<<PCIE schreibe, erhalte ich in R16 den Wert 32, so wie es sein soll. Also muss PCIE irgendwo definiert sein. Nur in GIMSK tritt dann der Fehler auf. Laut Datenblatt zum Attiny2313 besteht GIMSK aus drei Bits, naemlich:

Bit.7 fuer INT1
Bit.6 fuer INT0
Bit.5 fuer PCIE

Ich hab alle Ladeversionen probiert, wie z.B.

ldi r16, 0b00100000 oder ldi r16, 32

und es macht keinen Unterschied. R16 laedt jedesmal korrekt. Aber im Simulator markiert er mir das Bit nach dem out nicht. Gestern hab ich ldi r16, 255 geladen und alle markiert, dann schrittweise Bit fuer Bit zurueckgesetzt. Und es hat sich rausgestellt, dass der PCIE im Simulator auf Bit.4 reagiert, was laut Datenblatt nicht sein duerfte.

Alle anderen Register initialisieren sauber, nur bei PCIE tritt bisher das Problem auf. Ich habe bisher nur die Initialisierungsroutine der Hardware und die Interrupt-Tabelle mit RETI geschrieben, keine Variabeln oder sonst irgendwas, was stoeren koennte.

Korrektur: Ich hab grad die Headerdatei nochmal durchforstet, PCIE ist definiert als 5

 

[LotadaC]

So, ich hab mir jetzt mal mein AVRStudio 5.1.205 (SP3) angesehen...
Was haben die denn da mit der Device-Wahl angestellt? Die Definitionsdatei wird nicht mehr per .include eingebunden, sondern in irgendwelchen Dependencies vorgegeben. Will man also flott den Controller wechseln, muß man das dann auch da machen

So...

1. mit meinem Studio ist dieser Effekt (beim Tiny 2313) reproduzierbar
2. ich wollte das mal mit dem Tiny2313A probieren - in der (automatisch eingebundenen) Definitionsdatei bin ich dann auf folgendes gestoßen:
   

   ; ***** EXTERNAL_INTERRUPT ***********
   ; GIMSK - General Interrupt Mask Register
   .equ PCIE = 5 ;
   .equ INT0 = 6 ; External Interrupt Request 0 Enable
   .equ INT1 = 7 ; External Interrupt Request 1 Enable

   Das paßt definitiv nicht!!! - Das Register ist in der Hardware-Ansicht und im Simulator entsprechend auch falsch.
3. versuche ich nun, das im Tiny2313A (falsch) nachzuvollziehen, hats auch hier denselben Effekt (out gimsk, Register (=0x20) führt zu Gimsk=0x08)
4. out 0x3B, Register (=0x20) hat denselben Effekt
5. versuchsweise mal (in den dependencies) den Tiny13 gewählt (der hat ja auch PCIE als Bit5 in Gimsk (0x3B)) - und da stimmts!
6. AVRStudio 4.18.692 hat übrigens denselben Effekt!!

 

[TommyB]

Wäre nicht der erste Fehler in den Includes...
Mal von diversen Fehlern in den Kommentaren abgesehen fehlt beim ATtiny13 z.B. das komplette PRR (was der Lütte aber hat).
Nur dass sowas nicht behoben wird ist irgendwie ungünstig...

Den Tiny hab ich jetzt leider nicht hier, sonst hätt ich mal schaun könn was wirklich im Chip vorsich geht. Hätt ja auch sein könn dass einfach nur der debugger debuggt werden muss

 

[LotadaC]

Das ist definitiv ein Fehler im Simulator - woher jetzt auch immer konkret erzeugt...

Fehlerhafte Definitionsdateien könnte man auch selbst korrigieren, aber der Simulator kennt dann Dein PRR trotzdem nicht.
Hmm... in den Definitionsdateien steht ja am Anfang immer der Kommentar, daß die Dinger automatisch aus irgend'ner XML erzeugt wurden. Vielleicht bedient sich der Simulator bei der Erzeugung (und Simulation) der virtuellen Hardware auch dieser (fehlerhaften) XMLs?

Nachtrag: gefunden->

1. C:\Programme\Atmel\AVR Studio 5.1\devices
2. C:\Programme\Atmel\AVR Tools\Partdescriptionfiles
3. C:\Programme\MCS Electronics\BASCOM-AVR\PinOut

wobei die alle unterschiedlich groß sind...

 

[TommyB]

Könnte natürlich auch sein dass die .xml nicht passt. Aber scheinbar ist das Ein- oder Andere auch kompiliert:

C:\>dir *tiny13*.* /s
 Datenträger in Laufwerk C: ist System
 Volumeseriennummer: 68DF-DA3A

 Verzeichnis von C:\Program Files (x86)\Atmel\AVR Tools\AvrSimulatormk2

09.08.2011  20:16           172.544 libATtiny13A.dll
               1 Datei(en),        172.544 Bytes

 Verzeichnis von C:\Program Files (x86)\Atmel\AVR Tools\Partdescriptionfiles

25.08.2011  20:20           147.805 ATtiny13.xml
25.08.2011  20:20           148.247 ATtiny13A.xml
               2 Datei(en),        296.052 Bytes

     Anzahl der angezeigten Dateien:
               3 Datei(en),        468.596 Bytes
               0 Verzeichnis(se),  3.916.869.632 Bytes frei

Irgendwie wirkt das AVR Studio 4 schon etwas unaufgeräumt. Die Versionen danach ... Fragt lieber nicht.
Die Include ist auf jeden Fall für den Assembler, die xml für die GUI und Simulator? Könnte ja sein. Seitdem ich den Drachen hab nutz ich den Simulator nicht mehr. Höchstens noch um Warteschleifen einzumessen. Aber xml Dateien kann man ja auch selber bearbeiten. Nur bei kompilierten Dingen wirds schwer bis unmöglich

 

[Uwe H.]

Jungs, setzt mal Bit.4 (ohne Belegung), dann klappt es *lol* Der Wert sollte dann ja eigentlich 0x10 sein, ist aber 0x20 und das Flag im Simulator aktiviert.

 

[LotadaC]

Das ging jetzt leider etwas durcheinander:
Diese XML-Dateien werden einerseits zur Generierung der Definitionsdateien verwendet - das steht ja auch dort je im Kopf. Andererseits nehme ich an, daß sie (zumindest in einigen Versionen) auch für den Simulator mitverwendet werden - und auch bei den Vorgaben der Fusebits (siehe Clock-einstellungen usw).

Einige dieser XML-Dateien enthalten Fehler (TommyB -> PRR fehlt beim Tiny13, PCIEs beim Tiny2313A stimmen nicht, es findet sich hier fälschlicherweise das GIMSK vom Tiny ohne A...). Folglich sind dann auch die daraus generierten Definitionsdateien fehlerhaft.

Das betrifft dann nicht nur den Simulator, sondern auch die echte Programmierung mehr oder weniger (Beim PRR kann man halt nur den Namen nicht verwenden, aber eben so auch nichts (unschuldigerweise) falsch machen. Beim Tiny2313A könnte man wegen der falschen Datei halt mit PCIE (das in Wirklichkeit dann halt PCIE0 setzt, nur einen Teil der PCINTs scharfmachen (nach den Flags, und den Interruptvektoren hab ich jetzt noch gar nicht gesucht).
Diese Effekte lassen sich aber alle durch Verwendung der korrekten Register-/Bitadressen (bzw das selbst definieren) umgehen/korrigieren. Strenggenommen kann man ja in ASM auch ohne jegliche Definitionsdatei programmieren - muß man sich halt selbst um alle Adressen (des konkreten Controllers) kümmern.

Das hatte aber nichts mit Deinem Effekt im Simulator zu tun. Ich denke, daß der Fehler da auch nicht wirklich im Simulator selbst liegt, sondern in irgendeinem "Datenbankeintrag" (oder wie auch immer), daß dem Simulator sagt, welche Reaktion zu erfolgen hat, wenn das Bit mit 1 beschrieben wird (dabei werden ja die Bits nicht generell 1 gesetzt, sondern es wird irgendwie darauf reagiert. Bei vielen besteht die Reaktion zwar im eins setzen, aber bei einigen geschieht gar nichts, bei anderen hat das ganz andere Auswirkungen. Stichworte Interruptflags, Bits in Pin-Registern...)

Wird eine 1 ins PCIE geschrieben, sollte der Effekt im Simulator erzielt werden (Reaktion), daß einerseits der Interrupt scharf wird, andererseits sollte ein Bit in einem Register gesetzt werden. Solche Reaktionen müssen für den Simulator in irgendeiner ... Tabelle/Datenbank/... für jeden unterstützten Controller abgelegt sein, und irgendwo da ist was beim Tiny2313, beim Tiny2313A, und auch beim Tiny4313 verdreht (also in der "Datenbank" des Simulators).

 

[Uwe H.]

Ok, das heisst jetzt im Klartext, dass die Chance besteht, dass sich das Problem nicht nur im Simulator zeigt sondern auch im echten Programm spaeter? Das waere ne mittlere bis schwere Katastrophe... und ne echte Peinlichkeit fuer Atmel. Ich nutze ja Atmel Studio, weil es direkt von Atmel und auf die AVRs zurechtgeschnitten ist. Der PCINT ist in meinem geplanten Programm das wichtigste Element, wenn es da nachher Probleme gibt mit den Flaggen oder der Interruptsteuerung dann halleluja. Bleibt eigentlich nur eine Moeglichkeit: Attinys mit LEDs bestuecken und ein Testprogramm schreiben, was die geplante Interrupt Service Routine simuliert und die LEDs flackern laesst. Im Endeffekt verstehe ich trotzdem nicht, wie das sein kann. Das sieht fuer mich so aus, als ob die Bits irgendwie vertauscht sind. Auf Bit.5 laedt er 0x08, auf Bit.4 dann 0x20. Bit.7 und .6 funktionieren normal. Ich sollte mal den Rest der Bits testen, die 0x10 fehlt noch. Wie sieht denn der Befehl aus, wenn ich ihn direkt adressiere? Anstatt GIMSK dann die Hex-Adresse?

 

[TommyB]

Also ich hab mir, weil ich eh grad nicht schlafen kann , das ganze mal angeschaut.

Testprogramm wie hier schon beschrieben:

.INCLUDE <tn2313def.inc>

ldi r16, 1<<PCIE
out GIMSK, r16
in r17, GIMSK

break

r16 wird mit 0x20 geladen: richtig.
GIMSK wird mit 0x20 beschrieben: richtig.
r17 wird mit 0x20 aus GIMSK beschrieben: richtig.
Auch im I/O view wird alles richtig angezeigt.
Da war ich erstmal verwirrt weil ich den Fehler nicht reproduzieren konnte.

Aber:
Das AVR Studio hat ja 2 Simulatoren, den 1 und den 2 (zumindest die 4.19 die ich nutze). In dem 1 ist alles ok, also mal den 2. getestet.
r16 wird mit 0x20 geladen: richtig.
GIMSK wird mit 0x08 beschrieben: falsch!
Aber: r17 wird mit 0x20 aus GIMSK beschrieben: richtig. (Naja, zumindest der gewünschte Wert, aber eigentlich müsste es ja 0x08 sein, sprich der falsche Wert aus GIMSK)
Im I/O view wird PCIE als nicht gesetzt angezeigt: müsste somit falsch sein.

Fazit (aus meiner Sicht): Der Simulator 2 zeigt einfach nur Mist an.

Ich habe die Includes der 2 Simulatoren verglichen, die relevanten Werte sind alle identisch. Auch in beiden Simulatoren werden die richtigen Speicheradressen angezeigt.

Ich kenn das Studio 6 jetzt nicht, wenn du die Möglichkeit hast den AVR Simulator (ohne die 2 dahinter) auszuwählen denn nimm mal den. Da läufts fehlerfrei drin. Es ist definitiv der Simulator 2 der den Fehler produziert. Auf die erstellte Hex File dürfte sich das nicht auswirken, sprich deine Hardware sollte das machen was sie soll, mit genau dem Code den du zuerst gepostet hast. Vorsichtshalber würde ich es trotzdem noch mal überprüfen. Einfach einen PCINT aktivieren und in der ISR einen Pin toggeln wo eine LED dran hängt. Dann kannst du dir 100% sicher sein. (SEI nicht vergessen )

 

[Uwe H.]

Danke fuer die Hinweise, werd das heute mal testen. Gestern Nacht hab ich den Bug noch an Atmel gepostet, vielleicht haben die bereits ein Update oder irgendwas

 

[Uwe H.]

Die sind aber schnell bei den Atmel-Wikingern in Norwegen


uwe.janowski@greencore-systems.com 2013-11-25 21:04:25 CET

Dear sir and madam,

there is a bug in the simulator for AVR-Assembler. I've tried to simulate the
commands:

ldi r16, (1<<PCIE)
out GIMSK, r16

PCIE is the 5. Bit in GIMSK, the result should be 0x20 in the register. But the
result is 0x08. If you now set Bit.4 in GIMSK, which has no function, GIMSK
shows 0x20 (should be 0x10) and PCIE is activated in simulation.

Target device is Attiny2313, I'm using Atmel Studio 6.1 Service Pack 2

I have posted this bug to some friends, they have tested it too with the same
result.




[reply] [-] Comment 1 Morten Engelhardt Olsen 2013-11-26 07:37:04 CET

This looks like a simulator issue. Bug AVRSIM-294 reported to the simulator
team.

[reply] [-] Comment 2 Morten Engelhardt Olsen 2013-11-26 09:05:27 CET

This was a confusing one, but here is the long an detailed explanation:

tiny2313 is a reduced tiny4313. tiny4313 has 3 PCIE-bits located at GIMSK[5:3].

One would normally think that the three bits were placed as follows:
bit5 = pcie2, bit4 = pcie1, bit3 = pcie0

Which is why we mapped pcie[2:0] to GIMSK[5:3].

It turns out that the bits are placed as follows:
bit5 = pcie0, bit4 = pcie2, bit3 = pcie1
This means that since tiny2313 only has pcie0 this has ended up at bit3 of
GIMSK in the simulator model, rather than bit5.

Keep in mind that this only affects how the bit is presented in the IO-view in
Atmel Studio. It will look a bit odd, but the device will behave as it is
supposed to.

 

[LotadaC]

Also quasi meine Erklärung. Im Simulations-Modell die Bits verdreht (weil sie in echt eben so eigenartig angeordnet sind)
Dazu paßt auch das korrekte rücklesen von Thomas.
Hmm... der letzte Satz liest sich so, als wenn der Simulator dann aber trotzdem auf nen simulierten IRQ reagiert - haste das mal getestet?

Hmm irgendwer scheint bei der Einbindung der ATtiny2313/2313A/4313 in das Studio im allgemeinen, und in den Simulator im speziellen gepennt zu haben...

 

[Uwe H.]

Wahrscheinlich Aber naja, wir kennen das Debuggen doch alle von unseren eigenen Programmen. Deshalb hab ich Verstaendnis fuer die Wikinger und finds toll, dass auf meine Mail ueberhaupt so schnell reagiert wurde. Atmel Studio ist kostenlos und dafuer ist es wirklich nicht uebel. Ich hab mal ne Zeit in Ada geschrieben, da kostet eine kommerzielle Compilerlizenz fuer eine einzige AVR-Plattform jaehrlich um die 30.000,- (kein Witz, hab das Angebot von Adacore noch in meiner Mailbox). Dafuer hat man garantiert keine Bugs

Getestet hab ich den Interrupt noch nicht im Simulator, muss erstmal kucken wie das geht :-( Ich arbeite zum ersten Mal mit Atmel Studio 6.1 als IDE, bisher hatte ich es nur zum Brennen benutzt. Mein Programmiergeraet mag Bascom nicht so sehr und ich find die Bedienung zum Einstellen der Fusebits und zum Brennen/Lesen der verschiedenen Speicher im Studio echt klasse.

 

[LotadaC]

Hi Uwe,

wie hast Du eigentlich Kontakt bekommen? Ich finde da irgendwie keine Möglichkeit, 'ne simple Nachricht zu hinterlassen ohne mich nochmals irgendwo registrieren lassen zu müssen (ich meine, ich hab doch bereits 'n Account bei Atmel (um das überhaupt runterladen zu können) - Warum jetzt noch einen weiteren für den technical Support? Und dann vielleicht noch einen für das "ASF Bugzilla" (?), welches sich öffnet, wenn man im Studio unter Hilfe "Report a Bug" auswählt?)

Die Ursache des Simulator-Bugs wurde ja inzwischen gefunden, ob das noch behoben wird, ist 'ne andere Frage...

Ich würde denen aber gern noch mitteilen, daß beim 2313A und beim 4313 Die Regfiles fehlerhaft sind (unabhängig vom Simulator-Bug existieren einige Bits nicht bzw sind falsch benannt).

Die Adressen für den IRQ-Einsprung scheinen zu stimmen (auch wenn hier abweichend zum Datenblatt die Port-Buchstaben verwendet werden (PCINT7..PCINT0 werden im PCMSK0 maskiert, der IRQ mit PCIE0 befähigt, der IRQ selbst mit PCIF0 ausgelöst... die Adresse wird im Regfile dann als PCIBaddr abgelegt. Ok, es sind Beinchen, die dem B-Port angehören... (*)
Im GIMSK wird die PCINTs betreffend nur PCIE als Bit5 definiert, richtig wären PCIE0 als Bit5, PCIE2 als Bit4 und PCIE1 als Bit3.
Im GIFR (welches im Simulator aus Kompatibilitätsgründen EIFR genannt wird) ist es genauso: statt PCIF0, PCIF2 und PCIF1 auf den Bits 5,4,3 findet sich im Regfile nur PCIF auf Bit5.

(*)so ist das ... inkonsequent...
wenn die fehlenden Bits im GIMSK und GIFR irgendwann "nachgereicht" werden, heißen die dann auch PCIFA, PCIFB und PCIFD bzw PCIEA, PCIEB und PCIED??

Anfrage an Cassio&co: wie siehts hier eigentlich unter Bascom aus? Deren Regfiles werden ja auch irgendwie automatisch erzeugt. Sicher aus derselben Quelle. Wurde das da korrigiert?