Debugging und printf()

SIxO Sourcecode, Programmieren und Entwicklungswerkzeuge allgemein
Antworten
Andre
Beiträge: 11
Registriert: 09 Jan 2005 - 23:53

Debugging und printf()

Beitrag von Andre » 20 Aug 2005 - 14:52

Hallo.
Kann mir jemand kurz erklären, wie ich das Debugging aktiviere? Wenn ich mit DEBUG übersetzte, gibt der Sixo nichts mehr von sich. Weder LEDs noch Display tun was (abgesehen von einem kurzen Zucken des Kontrasts) und man kommt auch nicht in den Hardwaretest.

Ist das Programmierkabel geeignet, um den Sixo mit dem Rechner zum Übertragen der Debugausgaben zu verbinden?
Ich arbeite mit einem USB-Seriell-Adapter. Ich hoffe, daß es nicht daran liegt. Programmieren geht jedenfalls einwandfrei.
Gruß Andre

Ralf
Beiträge: 564
Registriert: 20 Feb 2004 - 11:27
Wohnort: Hannover

Beitrag von Ralf » 22 Aug 2005 - 14:29

Hi Andre,

ich nehme an, du hast das (provisorische) SIxO-Programmier-Manual schon gesehen?

Ansonsten:
Im TM30-Tool-Manager den 'Project Editor' öffnen, dort den linken unteren 'Quadranten' etwas größer ziehen, dann kannst du alle Compiler-Settings mit Erklärung sehen.

Debuggen mit KD30:
Zum Debuggen mit dem Monitorprogramm + KD30-Debugger muss im Projekteditor das C-Flag und das A-Flag 'MINIEMU' gesetzt sein. Außerdem muss natürlich zuerst auch das Monitorprogramm geflashed werden. Zum Debuggen kann das Programmierkabel wie beim Flashen genutzt werden (oberer 3-Pfosetnverbinder). Eine 'MINEMU'-Version ist ohne KD30 nicht nutzbar!

DebugOuts via printf():
Zum Mitlesen von DebugOuts (Textausgaben via 'printf(), 57.6/8/N/1) muss im Projekteditor das C-Flag und das A-Flag 'DEBUG' gesetzt sein. Ist 'MINIEMU' nicht gesetzt, so werden die printf()s nach Uart1 (also oberer 3-Pfosten-Stecker) ausgegeben.

MINEMU und DEBUG
Ist gleichzeitig 'DEBUG' und auch 'MINIEMU' gesetzt, so werden die printf()s nach Uart0 (unterer 3-Pfosten-Stecker) umgeleitet. Wenn man DEBUG und MINIEMU benutzen möchte, braucht man also zwei identische Programmier-Kabel, oberer Anschluss für Debugger, unterer für printf().

Bye, Ralf
Zuletzt geändert von Ralf am 11 Mai 2007 - 07:25, insgesamt 2-mal geändert.

Andre
Beiträge: 11
Registriert: 09 Jan 2005 - 23:53

Geht immer noch nicht

Beitrag von Andre » 22 Jan 2006 - 21:10

Danke für die Antwort. Ich komme aber nicht weiter. Das übersetzen mit DEBUG klappt, aber der SiXO hängt sich mit der Software auf, noch bevor irgend etwas passiert.

Ich konnte folgendes herausfinden:
Die Software hängt sich auf, sobald das erste Mal DebugOut(...) aufgerufen wird. Das passiert in main.c über DebugInit(...) ziemlich zu Anfang.
Ich habe probeweise in der debug.c in DebugOut() die tatsächliche Ausgabe über printf() auskommentiert. Dann läuft die Software - ohne Debugausgaben natürlich,

Ich habe dann in debug.h das Ziel auf das Display umgestellt.
#define DEF_DBGDIR DBG_DSPL
Die Software hängt sich ebenfalls auf. Auch hier läuft die Software, wenn ich in DebugOut() die Ausgabe (DisplPrintAString(...)) auskommentiere.

Was könnte mein Fehler sein?

Gruß Andre

Ralf
Beiträge: 564
Registriert: 20 Feb 2004 - 11:27
Wohnort: Hannover

Beitrag von Ralf » 30 Jan 2006 - 23:31

Hmm, scheint mir ein Konfigurationsproblem zu sein. :?:

Nur zum Klarstellen:
- Du benutzt eine Original-Software-Release, völlig unverändert?
- Du benutzt die Renesas-Toolchain?
- Du benutzt den KD30 Debugger (Monitor geflashed)?
- Das Debuggen mit dem KD30 ohne DEBUG funktioniert einwandfrei?
(Compiler+Assemblerflags aktiviert: C-Flags: MINIEMU, A-Flags: MINIEMU=1)

Wenn der KD30 Debugger ok ist und nur DebugOuts das Problem sind:
- Du hast nur DEBUG sowohl sowohl für den Assembler als auch für den Compiler enabled? (C-Flags: DEBUG, A-Flags: DEBUG=1)
- Stürzt die SW auch ab, wenn du nur DEBUG, aber nicht MINIEMU nutzt?

Mögliche Fehlerursachen:
- wenn möglich einkreisen, wo genau die SW abstürzt (in printf() ???)
- kann sein, dass die SW nicht abstürzt, sondern ewig versucht, bei der seriellen Ausgabe via putchar() (printf() ist auf putchar gemapped!) auf da erfolgreichen Versenden eines Zeichens zu warten, was nicht gelingt, wenn der da irgendwelche Macken an der Verkabelung zum PC vorhanden sind.

Hintergrundwissen:
KD30/Monitor und printf() wollen beide über Uarts kommunizieren. Weil der Uart1 der Standard-Uart zum Flashen ist, habe ich die SW so eingerichtet:
a) ist weder MINIEMU noch DEBUG definiert, sind beide Uarts frei für eigenen Bedarf
b) ist nur MINIEMU aktiv, so wird Uart1 genutzt (das Monitorprogramm ist so kompliliert)
c) ist nur DEBUG aktiv (also Release-Version mit printf() aber ohne KD30-Debugger) so kommen die printf() bei Uart1 an.
d) ist MINIEMU _und_ DEBUG aktiv, so weicht printf() auf Uart0 (!) aus.
Das geschieht alles automatisch über die TM30-C/A-Flags.

Die Ausgabe via Display ist übrigens nicht zuende entwickelt. Ich wollte irgendwann mal (wenn das per Dialog einstellbar ist), das Debuggen feiner justieren und auch während der Fahrt mal sehen können. Dazu sollten printf()s gefiltert (Details, Level) in einem rollbaren Screen landen. Das steht aber in der Prioliste z.Zt. eher unter 'nice2have'. :?

Ralf

Andre
Beiträge: 11
Registriert: 09 Jan 2005 - 23:53

Kaum macht man es richtig...

Beitrag von Andre » 31 Jan 2006 - 22:53

Danke für die ausführliche Antwort.

> Du benutzt eine Original-Software-Release, völlig unverändert?
Dann bräuchte ich ja nicht compilieren. :)

[...]

> Du hast nur DEBUG sowohl sowohl für den Assembler als auch für den Compiler enabled? (C-Flags: DEBUG, A-Flags: DEBUG=1)

Das wars. Das Assemblerflag fehlte. Jetzt geht es.
Danke.

Gruß Andre

Antworten