Debuggen von AT91SAM7x

[Lucas G. (fizz_buzz)]

Ich würde gerne meine Mikrocontroller debuggen. Dazu hat der AT91SAM7x 
ja eine Debug Unit mit einem Input (DRXD) und einem Output (DTXD). Ich 
habe die Debug Unit jetzt soweit konfiguriert und kann auch auf dem 
Oszilloskop ein Signal auf DTXD sehen.
Aber wie kann ich dieses Signal benutzen. Es handelt sich ja um ein 
UART. Ist dies irgendwie kompatible mit RS232 und kann ich mir da jetzt 
einen Stecker drauflöten? Bräuchte ich dafür nicht noch weiter 
Leitungen? Kann ich mir einen RS232 auf USB adapter besorgen und die 
Debug-Ausgabe dann einfach mir mit Putty anschauen?

Edit: Also, anscheinend tut es das. Ich habe DRXD und DTXD einfach mit 
einem rs232 stecker verbunden und mit putty mir das angeschaut. Leider 
scheint da immer noch etwas verdreht zu sein. Ich habe bei putty 
eingestellt:

no parity
no flow control
Data Bits: 7
Stop Bits: 1

und das ganze auf dem chip so eingestellt:

 /* Reset and disable receiver */
    AT91C_BASE_DBGU->DBGU_CR = AT91C_US_RSTRX | AT91C_US_RSTTX;

    /* Disable interrupts */
    AT91C_BASE_DBGU->DBGU_IDR = 0xFFFFFFFF;

    /* Configure PIOs for DBGU */
    AT91C_BASE_PIOA->PIO_ASR = AT91C_PA27_DRXD | AT91C_PA28_DTXD;
    AT91C_BASE_PIOA->PIO_BSR = 0;
    AT91C_BASE_PIOA->PIO_PDR = AT91C_PA27_DRXD | AT91C_PA28_DTXD;

    /* === Configure serial link === */
    /* Define the baud rate divisor register [BRGR = MCK / (9600 * 16)] */
    AT91C_BASE_DBGU->DBGU_BRGR = 312;  //muesste 9600 entsprechen
    /* Define the USART mode */
    AT91C_BASE_DBGU->DBGU_MR = AT91C_US_PAR_NONE | AT91C_US_CHMODE_NORMAL;

    /* Disable the RX and TX PDC transfer requests */
    AT91C_BASE_DBGU->DBGU_PTCR = AT91C_PDC_RXTDIS;
    AT91C_BASE_DBGU->DBGU_PTCR = AT91C_PDC_TXTDIS;

    /* Enable transmitter */
    AT91C_BASE_DBGU->DBGU_CR = AT91C_US_TXEN;

Dann rufe ich eine funktion zum debuggen mit dem folgenden inhalt auf:

void dbgu_print_ascii(const char *buffer)
{
    while (*buffer != '\0') {
        while (!(AT91C_BASE_DBGU->DBGU_CSR & AT91C_US_TXRDY));
        AT91C_BASE_DBGU->DBGU_THR = (*buffer++ & 0x1FF);
    }
}

Leider kommt dabei nur Buchstabengewirr raus. Hat da jemand eine Idee?

[Jim M. (turboj)]

Baudrate mit Oszi geprüft? Wieso 7 Datenbits, üblich sind 8, Du 
maskierst die Daten sogar auf 9 Bits - aber char hat bei ARM nur 8 Bits 
Daten.

[Steffen R. (steffen_rose)]

Aus dem Manual:

"The Debug Unit operates as a UART, (asynchronous mode only) and 
supports only 8-bit character handling (with parity). It has no clock 
pin."

[Lucas G. (fizz_buzz)]

Danke Jim und Steffen,

Die Baudrate scheint zu stimmen, bin mir aber nicht 100% sicher, da ich 
ja keinen clock pin habe (wie kann ich das sonst messen?). Ich habe auf 
8bit gewechselt. Merkwürdiger weise, scheinen all bits um eins nach 
rechts geshiftet und geflippt zu sein.

> The Debug Unit operates as a UART, (asynchronous mode only)

Heißt das, dass ich das prinzipiell an einen RS232 Stecker anschließen 
und dann mit meinem PC verbinden kann oder ist das so nicht gedacgt? Und 
wenn ich in putty alle Werte richtig setze tut es das?

> supports only 8-bit character handling (with parity)

Heißt das 7bit + 1 bit parity oder 8bit + 1bit parity.

Eigentlich habe ich alle Varianten schon ausprobiert, aber ich komme da 
einfach nicht auf einen grünen Zweig. Tut mir Leid für die Amateur 
fragen.

[Tim (Gast)]

Beitrag "Unterschied zwischen UART und RS232"
Pegel beachten!

[Lucas G. (fizz_buzz)]

Hallo Tim,

vielen Dank. Das könnte natürlich so einiges erklären :) Also nochmal 
für Dumme. Wenn ich einen Pegelwandler baue, der aus 0V -> +12V macht 
und aus 5V -> -12V, müsste es das dann tun?

Edit: Gerade gemessen, also mein UART hat einen Ausgang von 3.3V und 
nicht 5V.

[Lucas G. (fizz_buzz)]

Tim schrieb:
> Beitrag "Unterschied zwischen UART und RS232"
> Pegel beachten!

Also, nur falls hier nochmal jemand auf den Thread stößt. Tim hatte mein 
Problem richtig erkannt.

Meine Lösung:
Habe mir den MAX232 chip (Datenblatt: 
http://www.ti.com/lit/ds/symlink/max232.pdf), eine RS232 Stecker besorgt 
und 5x 470nF besorgt(im Datenblatt sind 1uF angegeben, scheint aber auch 
zu passen). Dann habe ich alles verlötet wie im Datenblatt beschrieben.

Tut es sau gut!

[Maxx (Gast)]

Lucas G. schrieb:
> Ich würde gerne meine Mikrocontroller debuggen. Dazu hat der AT91SAM7x
> ja eine Debug Unit mit einem Input (DRXD) und einem Output (DTXD).

Zum Debuggen hat der Atmel JTAG.

Die DBGU ist kein vollwertiger Debug-Zugang. Darüber kann man zwar 
wunderbar U-Boot und ähnliche Terminals legen bzw einen Ablauf loggen, 
aber für mehr eher weniger geeignet.

Atmel bietet für seine Controller abgespeckte Segger J-Link an 
(funktionieren nur auf Atmels) die sind empfehlenswert.

[Lucas G. (fizz_buzz)]

Maxx schrieb:
> Atmel bietet für seine Controller abgespeckte Segger J-Link an
> (funktionieren nur auf Atmels) die sind empfehlenswert.

Würdest du mir empfehlen den hier zu kaufen: 
http://de.rs-online.com/web/p/entwicklungskits-prozessor-mikrocontroller/6962377/ 
?

[Maxx (Gast)]

Ich hab den für 99€ in Erinnerung, aber ja das ist er.
Mit dem arbeite ich mit SAM7, SAM3, SAM4 seit Jahren. Schade ist 
lediglich, dass die orginal Segger-Tools (i.e. J-Flash ARM) noch eine 
zusätzlcihe Lizenz Option wollen.

Das braucht man dann aber eher beim Flashen von Kleinserien, der Rest 
geht unter den üblichen IDEs von Haus aus. (Keil, IAR, Atmel Studio)

[Lucas G. (fizz_buzz)]

Danke für den Tip. Kommt auf meine Weihnachtswunschliste.

[Davis (Gast)]

Die beste Empfehlung zum Debuggen von AT91SAM7-Controller ist der 
Umstieg (wenn möglich) auf STM32F1 bis STM32F4 und die Verwendung des 
ST-LINK (ca. 20 Euro) o. ä.

[Lucas G. (fizz_buzz)]

Davis schrieb:
> Umstieg (wenn möglich) auf STM32F1 bis STM32F4

Warum meinst du sollte ich umsteigen? Der Preis des Debuggers?

[Guest (Gast)]

Wenn es none commercial ist kannst du auch einen SEGGER J-Link Edu 
kaufen für um die 50 Euro. Da sind dann auch alle Lizenzen drin:
http://segger.com/j-link-edu.html