C debugWire ATTINY2313

[Janiiix3]

Hallo Freunde,

habt ihr schon Erfahrungen mit der aktuellsten AVR Studio 6 Version gemacht, was das Debuggen mit debugWire angeht ? Klappt das bei euch ?
Ich habe aktuell das Problem, dass ich es mit der Version nicht hin bekomme! Was aber mit der 4 er Version noch klappt ?!

 

[Senpai]

Also ich habe mit der aktuellen 6er Version schon erfolgreich Debugwire genutzt
Wie genau sieht denn dein Problem aus?

 

[Janiiix3]

Also ich habe mit der aktuellen 6er Version schon erfolgreich Debugwire genutzt
Wie genau sieht denn dein Problem aus?

Ich muss dazu sagen ich arbeite mit einer Betriebsspannung von 1,8 VDC! Bei der 4 er Version klappt es super (manchmal meckert er rum, dass die Betriebsspannung nur 1,778 VDC beträgt! Nach nem zweiten Versuch klappt es dann)
Bei der 6 er Version klappt es erst gar nicht... Sind die Spannungstoleranzen vill. höher gesetzt worden?

(error Message im Anhang)

 

[Janiiix3]

Ich hab´s jetzt hin bekommen
Es lag daran das ich immer mit dem "ATTINY2313" programmiert habe... (das geht auch)...
Nur habe ich einen "ATTINY2313A"... Da sind wohl die Speicheradressen & co. anderst...
Jetzt funktioniert es

 

[Senpai]

Dann ist ja gut
Ist es denn im Studio 6 jetzt Stabiler geworden mit der betriebsspannung oder musst du dennoch öfter neu versuchen?

 

[LotadaC]

Es lag daran das ich immer mit dem "ATTINY2313" programmiert habe... (das geht auch)...
Nur habe ich einen "ATTINY2313A"... Da sind wohl die Speicheradressen & co. anderst...

Ok,
Der 2313A entspricht ja eher dem 4313, abgesehen von den Speichergrößen, trotzdem haben 2313 und 2313A dieselbe Signatur.

Die Unterschiede (zwischen 2313 und 2313A) der elektrischen Daten werden Dich weniger interessieren (im wesentlichen 'ne geringere Stromaufnahme).
Veränderungen gibt es aber in einigen I/O-Registern:

• die A-Version kann an jedem Pin einen PC-IRQ koppeln, also werden 2 Mask-Register benötigt. Dazu wurde auch das erste konsequenterweise umbenannt. Ob sich dabei auch die Adresse des ersten geändert hat, habe ich jetzt nicht nachgesehen)
• im Zusammenhang damit gibt es logischerweise auch einen weiteren Interrupt-Vektor (auch hier wurde der erste entsprechend umbenannt)
• Die A-Version kann den UART auch als SPI-Master verwenden, also ein weiterer UART-Mode der selektierbar sein muß. Folglich gibt es Änderungen im Register mit den UMSEL-Bits

Als groben Überblick kannst Du hier nachlesen, ansonsten halt in den beiden Datenblättern...

Warum es mit dem neuen Studio nicht geht, ist mir trotzdem nicht klar. Aufgrund der identischen Signatur erkennt es eh keinen Unterschied.
Die veränderten Register-/Bitnamen sind ja in den Definitionsdateien den Adressen zugewiesen - insofern kannst Du also nur woanders im I/O landen.
Das sollte aber eigentlich zu keiner Fehlermeldung führen - selbst wenn Du ein reserviertes Bit triffst. Das Schreiben wird dann einfach ignoriert, das Lesen liefert immer 'ne 0. Unerklärliches Verhalten des Controllers, ok.

ACHTUNG: es gibt in den Definitionsdateien dieser Controller und im Modell für den Simulator einige Bugs!!!

 

[TommyB]

Das unerklärliche Verhalten ging noch weiter.
Ich hatte das mal mit einem einfachen ASM Programm getestet bei ihm (via TeamViewer). In 6 ging ja garnichts, daher in 4.

.INCLUDE "2313def.inc"  ; Controller definieren

RCALL Init
RCALL Main

Init:

	LDI		R16	, (1<<DDB1)
	OUT		DDRB	, R16

	LDI		R16	, (1<<PORTB1)
	OUT		PORTB	, R16


RET				; Fertig

Main:

RJMP Main

Gestartet und dann im Einzelschritt durch getickert.
1. Schritt) RCALL Init
2. Schritt) RCALL Main (ist einfach weiter gegangen und nicht in Init gesprungen)
3. Schritt) LDI in der Init
...
Der ist wirklich so von oben nach unten durch gelaufen wie im Quelltext, Sprünge ignoriert. Dazu hat das LDI und OUT garnichts verändert.
Zumindest die Main Loop loopte wenn ich mich recht erinner. Ich war etwas verwirrt
Aber nun geht es ja und man ist um eine Erfahrung reicher: So ein verdammtes A kann wichtig sein

 

[LotadaC]

normalerweise muß die Definitionsdatei gar nicht inkludiert werden, da das durch die Device-Auswahl bereits automatisch geschieht.
Bei den älteren Studios kannst Du aber einfach eine andere inkludieren, inwiefern dann welche verwendet wird, und ob das zu irgendwelchen Fehlern führt (wenn die Dateien sich wiedersprechen), oder in welcher Reihenfolge die geladen, und somit eventuell irgendwelche Namen überschrieben werden, weiß ich nicht.

Wenn Du im neueren Studio 'ne Definitionsdatei inkludierst, die vom gewählten Device abweicht, gibts 'ne Fehlermeldung - allerdings bereits beim Compilieren. Sind die identisch, gehts, willst Du allerdings auf ein anderes Device wechseln, mußt Du das an beiden Stellen machen (Device-Wahl und Quelltext).
Fazit: Da die Datei automatisch inkludiert wird nicht (mehr) im Code inkludieren.
(obwohl ich es eigentlich hasse, nicht alles im Quellcode sehen zu können (zumindest den Verweis/das Include) - gerade bei Assembler. Eigentlich sollte es andersrum sein: anhand der inkludierten Definitionsdatei sollte das Studio das Device festlegen).

 

[TommyB]

Muss ich dir leider widersprechen. Beim Studio 5 und 6 mag dem so sein, nicht aber beim 4er.
Wenn ich das include auskommentiere:

P:\Programmierung\AVR Studio\test2313.asm(17): error: Undefined symbol: DDB1
P:\Programmierung\AVR Studio\test2313.asm(18): error: Undefined symbol: DDRB
P:\Programmierung\AVR Studio\test2313.asm(20): error: Undefined symbol: PORTB1
P:\Programmierung\AVR Studio\test2313.asm(21): error: Undefined symbol: PORTB

 

[LotadaC]

Stimmt. mit dem 4.18 nachvollziehbar. Die Device-Wahl scheint hier lediglich das Modell für den Simulator festzulegen. Wenn dort jetzt ein anderer Controller als bei im Code gewählt/inkludiert ist, verhält sich lediglich der Simulator "komisch"

Also der Absatz mit den älteren Studios ist falsch. Mit dem 4.19 (war doch das letzte 4er, oder) kann ich nicht testen, ab dem 5er wurde automatisch inkludiert (und bei Abweichungen gemeckert)...