Data-Breakpoints mit ATmega16

[St K. (motu)]

Hallo,

ich versuche mich gerade ein wenig mit dem AVR-Dragon und einem 
ATmega16. Jetzt habe ich versucht im AVR Studio 4 SP3 einen 
Data-Breakpoint im SRAM zu setzten, aber AVR Studio meldet immer nur:
"Unable to set data breakpoint. No available breakpoint resources."

Ich habe sonst keine Breakpoints gesetzt.
Was mir auch ein wenig komisch vorkommt ist, dass ich nur einen 
Hardware-Breakpoint setzten kann, wenn ich in den Optionen des Dragon 
unter Debug das Häckchen bei "Disable use of BREAK instruction for 
breakpoitns" gesetzt habe. Aber laut Datenblatt müsste ich doch 
eigentlich 3 setzten können.

Ich habe auch schon mehrere ATmega16 ausprobiert, immer das gleiche 
Ergebnis.

Könnte mir da bitte jemand helfen, oder hat wenigstens jemand einen Tip 
wo man dazu mal brauchbare Infos finden kann?

Gruß
Motu

[Jörg W. (dl8dtl) (Moderator)]

Ich weiß nicht, wie AVR Studio das handhabt, aber ich weiß, wie es in
AVaRICE + AVR-GDB implementiert ist.

Auf was für Daten willst du denn einen breakpoint setzen?  Das ICE
kann nur breakpoints auf Bereiche setzen, die sich als Basisadresse
+ Maske darstellen lassen.  Für Ein-Byte-Variablen ist das natürlich
immer möglich, für größere jedoch nur, wenn sie passend im Speicher
angeordnet sind.  Da der AVR jedoch an sich keine Anforderungen ans
memory alignment hat, schmeißt der Linker die Variablen natürlich
so hin, wie sie gerade passen.  Bei einer 16-bit-Variablen hast du
also nur noch eine 50%ige Wahrscheinlichkeit, dass es klappt, bei
größeren Variablen wird es noch schlechter.

Im AVR-GDB wiederum könnte man den watchpoint (so heißt der data
breakpoint dort) auch auf nur ein Byte einer Zwei-Byte-Variablen
setzen (das genügt ja meistens), aber ich fürchte, die beschränkten
Möglichkeiten des AVR Studio wiederum werden dir eine derartige
Freiheit nicht bieten.

Mit deinen anderen AVR-Studio-Fragen bin ich überfragt, weil ich das
nicht benutze.

[spess53 (Gast)]

Hi

>"Unable to set data breakpoint. No available breakpoint resources."

Heisst ganz einfach, das Data Breakpoints nicht unterstützt werden. Das 
ist nur den teureren ICEs (>JTAG ICE MKII) vorbehalten. Steht auch, wenn 
ich micht recht erinnere, in der AVR-Studio Hilfe zu AVR Dragon.

MfG Spess

[St K. (motu)]

Naja, das ist es ja gerade, beim Dragon steht genau da selbe drinne, wie 
z.B. in der Hilfe zum AVR One!, nämlich nur das die HW-Breakpoints vom 
OCD des jeweiligen Mikrocontrollers abhängig sind. Es wird in diesem 
Zusammenhang nur folgendes erwähnt:
"Hardware breakpoints can be combined to form data breakpoints".
(Steht direkt in der Hilfe zum Dragon unter On-Chip Debugging--> AVR OCD 
Implementations...)

Aber die Fehlermeldung wird wohl leider wirklich darauf hindeuten, dass 
es mit dem Dragon nicht geht :(

Aber trozdem Danke für die Hilfe.

[Jörg W. (dl8dtl) (Moderator)]

St Ko schrieb:
> Aber die Fehlermeldung wird wohl leider wirklich darauf hindeuten, dass
> es mit dem Dragon nicht geht :(

Nein, das hat mit dem Dragon nichts zu tun.  Die Möglichkeit von
data breakpoints hängt einzig von der im Controller vorhandenen
Debug-Hardware ab, und JTAG auf dem MegaAVR kann sowas.
(debugWIRE kann es nicht.  PDI auf Xmega kann es auch, aber AVR
Studio 5.x unterstützt es gleich mal gar nicht erst, nichtmal auf
dem MegaAVR.)

Warum gehst du nicht auf das ein, was ich dir geschrieben habe, und
ergibst dich stattdessen in das scheinbar unvermeidliche Schicksal?

[Jörg W. (dl8dtl) (Moderator)]

Beweis:

$ cat test.c
unsigned char testchar;

int
main(void)
{
  testchar = 42;
  return testchar;
}
$ avr-gcc -O0 -mmcu=atmega2560 -g -o test.elf test.c
$ avr-objdump -O ihex test.elf test.hex
$ avrdude -qq -c dragon_jtag -P usb -p atmega2560 -U test.hex
$ avarice -g -j usb :1212 &
AVaRICE version 2.12svn20111212, Dec 15 2011 14:43:18

Defaulting JTAG bitrate to 250 kHz.

JTAG config starting.
Found a device: AVRDRAGON
Serial number:  00:a2:00:00:33:94
Reported JTAG device ID: 0x9801
Configured for device ID: 0x9801 atmega2560
JTAG config complete.
Preparing the target device for On Chip Debugging.
Waiting for connection on port 1212.

$ avr-gdb test.elf
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=avr"...
(gdb) target remote :1212
Remote debugging using :1212
0x00000000 in __vectors ()
(gdb) watch testchar
Hardware watchpoint 1: testchar
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x000000fe in .do_clear_bss_start ()
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at test.c:7
7         return testchar;
(gdb) det
Ending remote debugging.
(gdb) quit

Du siehst, der data breakpoint (watchpoint beim GDB) schlägt genau
zweimal zu: einmal während der Initialisierung, ein zweites Mal, wenn
die 42 zugewiesen wird.  Dabei steht der PC jedoch bereits auf der
Anweisung danach, da ein data breakpoint "post mortem" zuschlägt,
während ein instruction breakpoint triggert, bevor der Befehl
ausgeführt wird.

[St K. (motu)]

Naja, das Problem ist halt, das ich auf AVR Studio 4 und AVR Dragon 
beschränkt bin, soll heißen ich kann leider keine andere 
Entwicklugnsumgebung hier am entsrehcenden Arbeitsplatz nutzen (Gründe 
dafür lass eich mal außen vor ;) ).

Das man Variablen gößer als 1Byte speziell behandeln muss wegen den von 
dir genannten Gründe war mir schon bewusst. Deshalb wollte ich 
eignetlich auch nur eine ein Byte große Var nutzen (ich denke doch mal 
mit int8_t sollte das gegeben sein).

Wie gesagt versteh ich halt auch die Fehlermeldung nicht so ganz, da es 
ja laut Datenblatt möglich sein sollte, genauso wie 3 statt nur einem 
HW-BReakpoitn möglich sein sollten.

[Jörg W. (dl8dtl) (Moderator)]

St Ko schrieb:
> Deshalb wollte ich
> eignetlich auch nur eine ein Byte große Var nutzen (ich denke doch mal
> mit int8_t sollte das gegeben sein).

Ja.

> Naja, das Problem ist halt, das ich auf AVR Studio 4 und AVR Dragon
> beschränkt bin, soll heißen ich kann leider keine andere
> Entwicklugnsumgebung hier am entsrehcenden Arbeitsplatz nutzen

Dann kannst du dich bei demjenigen beklagen, der das festgelegt hat.
Du kannst auch versuchen, bie Atmel einen Support-Request aufzumachen,
aber falls es sich um einen Bug handelt, wird wohl an AVR Studio 4.x
kaum noch einer was dran machen wollen dort.

[St K. (motu)]

Naja, wenns nicht geht ist auch nicht so schlimm jetzt, wäre halt nur 
schön gewesen, aber vielen dank für die Hilfe :)

[Oliver (Gast)]

St Ko schrieb:
> ich kann leider keine andere
> Entwicklugnsumgebung hier am entsrehcenden Arbeitsplatz nutzen (Gründe
> dafür lass eich mal außen vor ;) ).

Wenn mir der data-breakpoint mehrere Stunden Arbeit ersparen würde, dann 
hätte ich auch am Arbeitsplatz ruck-zuck Eclipse nebst gdb installiert, 
und am laufen. Wer kann und will dich dran hindern?

Oliver

[St K. (motu)]

Mhhh, es ist mir fast zu peinlich, aber ich habe scheinbar die Ursache 
meiner Probleme gefunden.
Beim VErsuch statt es ATmega16 ein 32er zu nehmen ist mir aufgefallen 
das ich Pin30, also AVCC, anstatt PIN31 auf GND gelegt habe.
Nun kann ich 3 HW-Breakpoints und Databreakpoints nutzen, sehr 
merkwürdig :D