mikrocontroller.net

Forum: Compiler & IDEs Seltsames problem beim Debuggen


Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hoffe Ihr könnt mir weiterhelfen, da ich ein recht mehrkwürdiges 
Problem beim Debuggen habe.

Ich bin erst kürzlich in die Mikrocontroller-Programmierung eingestiegen 
und habe ein Evalations-Board mit einem AT91SAM7X256 und einen JTAG 
J-Link für ARM. Als IDE verwende ich Eclipse unter Windows XP mit 
ZylinCDT und dem yagarto Toolchain, sowie den J-Link GDB-Server

Ich habe alles nach folgender Anleitung eingerichtet:
http://www.yagarto.de/howto/yagarto2/index.html


Ich habe ein einfaches Projekt geschrieben, mit einer Ausgabe über 
Seriell und einem blinkenden LED.

Das kuriose ist, dass ich es schon auf dem Board via JTAG debuggen 
konnte aber neuerdings geht es nicht mehr. Dabei bin ich mir nicht 
bewußt etwas verstellt zu haben. Auch ein Löschen von Eclipse und eine 
erneute Einrichtung schaffte keine Abhilfe.

Wenn ich das Projekt das erste mal aus Eclipse heraus debugge kommt 
folgende Meldung:
source D:\EclipseWorkspace\SAM7X256Test\prj\sam7x256_ram_jlink.gdb
0x00000000 in ?? ()


Breakpoint 1, main () at src/main.c:234
234      PIO_Configure(pPins, PIO_LISTSIZE(pPins));
info proc
Current language:  auto
The current source language is "auto; currently c".
Undefined info command: "proc".  Try "help info".
info program
Debugging a target over a serial line.
Program stopped at 0x200828.
It stopped at breakpoint 1.
Type "info stack" or "info registers" for more information.

Wäre über jede Hilfe dankbar.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich das bewerten kann ist deine Debug-Configuration in Eclipse 
verbogen.
Hast du unter GDB- commandline eine Datei angegeben die ein Kommando 
'info proc' enthält? Oder unter dem Tab. Commands solch ein Kommando 
eingegeben?
Da grabe mal.

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter Command File habe ich wie im HowTo beschriben die Datei
sam7x256_ram_jlink.gdb angegeben.

Inhalt ist:
#
# This config file was tested with J-Link GDB Server v4.04
#

# Listening for commands on this PC's tcp port 2331
target remote localhost:2331

# Set gdb server to little endian
monitor endian little

# Set JTAG speed to 30 kHz
monitor speed 30

# Reset the chip to get to a known state.
monitor reset 8
monitor sleep 10

#
# Disable the watchdog and setup the PLL
#

# WDT_MR, disable watchdog 
monitor writeu32 0xFFFFFD44 = 0x00008000

# CKGR_MOR
monitor writeu32 0xFFFFFC20 = 0x00000601
monitor sleep 10

# CKGR_PLLR
monitor writeu32 0xFFFFFC2C = 0x00480a0e
monitor sleep 10

# PMC_MCKR
monitor writeu32 0xFFFFFC30 = 0x00000007
monitor sleep 10

# PMC_IER
monitor writeu32 0xFFFFFF60 = 0x00480100
monitor sleep 100

# Set JTAG speed in khz
monitor speed 12000

load
break main
continue

Wenn ich im Debugger einzeln durchsteppe. Bekomme ich bei der 
Konfiguration der Debugschnittstelle die meldung, dass er eine 
lib1funcs.asm nicht finden könne.

Autor: 900ss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du mußt das Ganze etwas präziser beschreiben.
Wann machst du genau was und was sind die Ausgaben Konsolenfenster in 
Eclipse dazu.
Wenn er Datei Namens lib1funcs.asm nicht findet ist die Lage doch 
eindeutig. Er versucht nach einem Step oder Breakpoint den Source dieser 
Stelle anzuzeigen. Dazu benötigt er die Datei, die er aber nicht findet. 
Warum steht auf einem anderen Blatt.

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sagt der GDB.
Breakpoint 1, main () at src/main.c:76
76              DBGU_Configure(DBGU_STANDARD, 115200, MCK);
Current language:  auto
The current source language is "auto; currently c".

Ich habe mir jetzt mal ein ganz simples Programm gebastelt, was einfach 
nur eine Ausgabe auf der Debug-Schnittstelle machen soll.
#include "typedefs.h"
#include "dbgu.h"
#include "board.h"
#include <stdio.h>


int main (void)
{
  DBGU_Configure(DBGU_STANDARD, 115200, MCK);
  printf("test");

  return(0);
}


Es kommt nur obige meldung vom GDB und nix auf der Debugschnitstelle 
raus.

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also diese Meldung kommt beim DBGU_Configure
Can't find a source file at "../../../gcc-4.4.2/libgcc/../gcc/config/arm/lib1funcs.asm" 
Locate the file or edit the source lookup path to include its location.

Diese Meldung kommt beim printf
Can't find a source file at "../../../../../newlib-1.18.0/newlib/libc/stdio/printf.c" 
Locate the file or edit the source lookup path to include its location.

Beide Dateien sind nicht auf meinem Rechner. Auch eine Neuinstallation 
des Yagarto-Toolchains brachte keine Abhilfe.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist ja, ob du die Applikation oder deine Systembibliotheken
debuggen willst.

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Applikation natürlich.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian L. schrieb:
> Die Applikation natürlich.

Was interessiert dich dann, ob der Debugger den Source Code für printf 
findet oder nicht?

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich interessiert, dass auf der Debug-Schnittstelle das printf 
rauskommt. Tut es aber nicht. Ich versuche gerade den grund dafür zu 
finden.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann willst du aber doch die Bibliothek debuggen.  Damit wiederum
musst du aber (damit das Sinn hat) auch den Sourcecode der
Bibliothek in Reichweite haben.  Was erwartest du, wie der Debugger
dich durch die einzelnen Stufen von printf() hindurch geleiten
könnte (bis zur Ausgabe des Zeichens "ganz unten"), wenn er den
entsprechenden Sourcecode nicht finden kann?

Nein, der Sourcecode ist kein Bestandteil der Debug-Informationen
in der Objektdatei.  Dort stehen lediglich Zeiger (Dateiname und
Zeilennummer) auf die Quelle.

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich bin noch nicht so lange dabei und Einsteiger in der Materie.
Was müsste ich denn tun, um das Projekt aus Eclipse raus auf dem AT91 zu 
testen?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, wenn dein printf() nicht geht, hast du zwei Varianten:

. Du installierst in der Tat den Sourcecode für die Bibliothek und
  hangelst dich mit dem Debugger durch.  Der Sourcecode muss natürlich
  zum Objektcode passen, am sinnvollsten, indem man die Bibliothek
  gleich selbst compiliert.

. Du liest die Dokumentation und versuchst herauszufinden, was du
  falsch gemacht hast. ;-)  Irgendwo muss ja dokumentiert sein, wie
  das backend für stdio beschaffen sein muss, damit die Ausgaben
  auch am gewünschten Gerät ankommen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> . Du liest die Dokumentation und versuchst herauszufinden, was du
>   falsch gemacht hast. ;-)  Irgendwo muss ja dokumentiert sein, wie
>   das backend für stdio beschaffen sein muss, damit die Ausgaben
>   auch am gewünschten Gerät ankommen.

Wahrscheinlich würde es auch vernünftig, erst mal herauszufinden, wie 
dieser printf Unterbau beschaffen sein muss und diesen erst mal in den 
vorhandenen Sourcen zu identifizeren und sich anzusehen, was da 
eigentlich abgeht.
#include "typedefs.h"
#include "dbgu.h"
#include "board.h"
#include <stdio.h>


int main (void)
{
  DBGU_Configure(DBGU_STANDARD, 115200, MCK);
  printf("test");

  return(0);
}

ich tippe mal auf "board.h"
Eventuell wäre es auch schlau, zuerst die System Header zu inkludieren 
und erst dann die spezifischen. So nach dem Muster: gib den spezifischen 
Teilen die Chance, die allgemein gültigen aus den Systemheadern zu 
überschreiben. (Das kann, muss aber nicht Abhilfe sein)
#include <stdio.h>
#include "typedefs.h"
#include "dbgu.h"
#include "board.h"

...

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das taschen der Includes hat leider keine Abhilfe geschafft.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hast du denn als Backend für das printf implementiert?

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter YAGARTO wird die newlib verwendet. Die erfordert auch eine 
syscalls.c für die low-level Funktionen. printf() nutzt diese dann z.B. 
um eine Ausgabe zu machen.
In deinem YAGARTO-Verzeichnis in der Datei yagarto_newlib.txt solltest 
du einen Hinweis darauf finden. Dort wird dann auf die syscalls.c 
verwiesen mittels diesem Link:
http://www.yagarto.de/download/yagarto/syscalls.c

Dort gibt es z.B. einen Routine write_r(...) die eine Ausgabe auf den 
uart schicken sollte (ist dort mit '#if 0' ausgeklammert.

Diese Datei (syscalls.c) müßtest du eigentlich irgendwie dazulinken, 
weil sonst dein Linker über fehlende Symbole meckert. Und die Datei 
müßtest du so ändern dass die Stubs in dieser Datei eine sinnvolle 
Funktion ergeben.
Auf der YAGARTO-Seite ist sehr schön beschrieben, was man alles machen 
muß.

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es sich um ein Beispiel aus der AT91-Library handelt: Atmel nutzt, 
zumindest in der evtl. nicht ganz aktuellen Version, die ich mir zuletzt 
angeschaut habe, eigene Implementierungen von printf. Der Quellcode dazu 
findet sich in den Beispielenprojeketen (utils/stdio.c o.ä.). Diese 
nutzt putc, dass ebenfalls in projektspezifischem Code implementiert 
ist, und das leitet die Zeichen an den DBGU-"UART". Langer Rede: wurden 
die Atmel-Beispiel-Makefiles unverändert genutzt oder selbst etwas 
zusammengebastelt? Es sieht so aus, als würden newlib-stdio und AT91LIB 
stdio irgendwie gemixt, wenn ja, kann das die Ursache für die Probleme 
sein. Die Linker-Optionen und -Reihenfolge müssen sorgfältig gesetzt 
werden.

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Martin Thomas

Das Mischen ist in der Tat wohl das Problem, wie ich festgestellt habe.
Das erste Beispielprogramm was ich hatte war das von der Yagarto-Seite. 
Darauf aufbauend wollte ich nun ein Atmel-Beispiel implementieren.

Im util-Ordner von Atmel gibt es allerdings keine stdio.c. Allerdings 
eine trace.c in der folgendes vermerkt ist.
//------------------------------------------------------------------------------
/// \exclude
/// Implementation of fputc using the DBGU as the standard output. Required
/// for printf().
/// \param c  Character to write.
/// \param pStream  Output stream.
/// \param The character written if successful, or -1 if the output stream is
/// not stdout or stderr.
//------------------------------------------------------------------------------

Ich habe jetzt statt DBGU_CONFIGURE TRACE_CONFIGURE aus der trace.h 
verwendet und kann nun zumindest mit DBGU_PutChar was auf der 
Debug-Schnittstelle ausgeben.
Printf will aber immer noch nicht.

Vielleicht bin ich blind aber ich finde keine Infos zu der syscalls.c 
auf der yagarto-Seite. Die Datei selbst habe ich aber schon im Projekt.

Autor: 900ss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian L. schrieb:
> Vielleicht bin ich blind aber ich finde keine Infos zu der syscalls.c
> auf der yagarto-Seite.

Hmmm.... ich find das auch grad nicht wieder. :-/
Sonst lies dir auch die Datei "yagarto_newlib.txt" in deiner 
YAGARTO-Installation.

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich formuliere die Frage mal um. Wie bekomme ich printf zum Debuggen 
über die Debugschnittstelle ans laufen? Ich habe nun mal im Detail 
geguckt und die Atmel-Beispiele sind ja alle für IAR und dort sind die 
Bibliotheken doch recht anders als die von yagarto.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es Beispiele von YAGARTO gibt, versuche die. Ansonsten hat Martin 
Thomas auf seiner Webseite sehr viele funktionierende Beispiele auch für 
ARM. Den Link hab ich gerade nicht.

Autor: 900ss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So den Link hab ich auch:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...

Das sind jede Menge Beispiele. Weches davon jetzt gerade die syscalls.c
mit nutzt, das muß er selber hier mal mitteilen. Das brauchst du für die 
printf() Funktion. Jedenfalls weiß ich keinen anderen weg.
Ich hoffe er liest noch mit :-)

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit erinnert, ist das "gamma"-Beispiel mit syscalls und newlib-stdios 
(i)printf. Grade nicht sicher, ob write an die DGBU oder einen 
"normalen" UART gebunden ist. Wenn nicht ersichtlich, nochmal fragen, 
ich schaue dann in den Code.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...

Die Atmel AT91LIB-Methode printf komplett selbst zu implementieren 
findet man in deren Quellcode. Zumindest in der Version der des 
AT91-Software-Packages für AT91SAM7S-EK und AT91SAM7X-EK, in die ich 
zuletzt reingeschaut habe, werden sehr wohl GNU-Tools unterstützt (nicht 
nur IAR EWARM). (Nochmal) Wenn richtig erinnert, habe ich den 
betreffenden Atmel-Code auch in meinem AT91-SD-Card-Bespiel verwendet. 
Habe auch da jetzt nicht reingeschaut, kann ich aber bei Bedarf machen.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke ich schaue mal rein.

Autor: Christian L. (chl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal versucht mit Hilde Deines Gamma-Beispieles ein 
minimalistisches Programm zu schreiben, welches nur etwas auf der 
Debug-Schnittstelle ausgibt.
#include <stdint.h>
#include <stdio.h>

#include "board.h"
#include "dbgu.h"


int main(void) {
  // Set-up DBGU Usart ("UART2")

  AT91F_DBGU_Init();
  iprintf("1234567890");
  AT91F_DBGU_Printk("\r\n\r\ntest\r\n");
}

mit iprintf kommt auf der Schnittstelle gar nichts an und mit 
AT91_DBGU_Printk nur Müll.

dbgu.c und h sowie die syscalls.c sind aus dem Gamma-Projekt.

Es gab einen Error bezüglich isatty. Dieser war nach folgender Änderung 
der syscalls.c verschwunden.
int _isatty(int file); /* avoid warning */

int _isatty(int file)
{
  return 1;
}
Wobei ich nicht weiß, ob man da ohne weiteres einen Unterstrich 
vorschreiben kann.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wobei ich nicht weiß, ob man da ohne weiteres einen Unterstrich
> vorschreiben kann.

Kann man, aber man sollte wissen, warum man ihn davor schreibt :)

Bei _funktionen ist die Übereinkunft, dass die zum System 
(Systemlibrary) gehören also dass es keine übliche Anwenderfunktion ist. 
Das Einhalten der Übereinkunft erleichtert den Eingeweihten die 
Codelesbarkeit und das Codeverständnis.

wenn im System allerdings die Funktion fehlt, andere Teile des Systems 
sie aber referenzieren, dann kann der Anwender als Bugfix oder 
Workaround die Funktion nachträglich implementieren. Das scheint hier zu 
passieren.

Eine ähnliche Übereinkunft gibt es bei Makros mit  oder _. Makros mit 
diesen Namen "gehören" dem Compiler.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.