STM32F03 > USART1 > keine Lebenszeichen

[Jan H. (janiiix3)]

Nabend,

aktuell versuche ich eine Debug Möglichkeit über die USART1 von meinem 
STM32F030xx8 zu schaffen.

Leider bis jetzt ohne Erfolg. Mein UART <-> TTL Adapter funktioniert 
(habe ich getestet).

Wenn man die Taktquellen vom M0 nicht weiter berührt (sprich default), 
taktet er doch intern mit 8MHz oder?.

Habe ich was bei der Initalisierung vergessen?!.

Als Terminal benutze ich aktuell "TeraTerm".

  GPIOInitPort( GPIOA ); // Clock enabled
  GPIOInitPort( GPIOC );
  GPIOInitPort( GPIOB );

  GPIOSetOutputType( GPIOA, PIN_9, OUTPUT_PUSH_PULL );
  GPIOSelectPinMode( GPIOA, PIN_9, ALTFUNC ); // USART1_TX

  GPIOSetOutputType( GPIOA, PIN_10, INPUT );
  GPIOSelectPinMode( GPIOA, PIN_10, ALTFUNC ); // USART1_RX

  GPIOSelectAltFunc( GPIOA, PIN_9, GPIO_ALT_FUNC_1 );
  GPIOSelectAltFunc( GPIOA, PIN_10, GPIO_ALT_FUNC_1 );

 // Hier wird aktuell nur USARTx->BRR = 0x341UL @8MHz (9600) geschrieben
        USARTInit( USART1, USART_BAUDRATE_9600 );

// RCC->APB2ENR |= RCC_APB2ENR_USART1EN;
        USARTClkOn( USART1 );

// pUsart->CR1 |= ( USART_CR1_UE | USART_CR1_RE | USART_CR1_TE );
        USARTEnable( USART1 );

[M. Н. (Gast)]

Jan H. schrieb:
> USARTClkOn( USART1 );

Clock einschalten, bevor

Jan H. schrieb:
> USARTInit( USART1, USART_BAUDRATE_9600 );

Ohne Clock wird die Registerbank nicht getaktet.

Jan H. schrieb:
> GPIOSetOutputType( GPIOA, PIN_10, INPUT );

Kannst du dir sparen, wird durch die ALTFUC Einstellung eh 
zurückgesetzt.

[Jan H. (janiiix3)]

M. H. schrieb:
> Jan H. schrieb:
>> USARTClkOn( USART1 );
>
> Clock einschalten, bevor
>
> Jan H. schrieb:
>> USARTInit( USART1, USART_BAUDRATE_9600 );
>
> Ohne Clock wird die Registerbank nicht getaktet.
>
> Jan H. schrieb:
>> GPIOSetOutputType( GPIOA, PIN_10, INPUT );
>
> Kannst du dir sparen, wird durch die ALTFUC Einstellung eh
> zurückgesetzt.

Das mit dem Takt macht Sinn, funktioniert aber immer noch nicht.
Und die config für den Input habe ich raus genommen.

[Stefan F. (Gast)]

Jan H. schrieb:
> Wenn man die Taktquellen vom M0 nicht weiter berührt (sprich default),
> taktet er doch intern mit 8MHz oder?.

Die L0 Serie taktet per default mit 2 MHz. Wie es bei der F0 Serie ist, 
weiß ich nicht. Steht das nicht in deinem Referenzhandbuch?

> Leider bis jetzt ohne Erfolg.
> funktioniert aber immer noch nicht.

Woran machst du das fest? Ich sehe keinen Code, wo du etwas sendest. DU 
musst schon mehr zeigen - viel mehr. Auch den Schaltplan und welches 
Board du verwendest.

Ich würde erstmal LED an die beiden Pins anschließen und blinken lassen. 
Danach kannst du sie mal seriell benutzen, aber mit niedriger Baudrate 
denn dann kannst du die LED blinken sehen.

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Jan H. schrieb:
>> Wenn man die Taktquellen vom M0 nicht weiter berührt (sprich default),
>> taktet er doch intern mit 8MHz oder?.
>
> Die L0 Serie taktet per default mit 2 MHz. Wie es bei der F0 Serie ist,
> weiß ich nicht. Steht das nicht in deinem Referenzhandbuch?
>
Also laut Datenblatt lese ich 8Mhz raus.

>> Leider bis jetzt ohne Erfolg.
>
> Woran machst du das fest? Ich sehe keinen Code, wo du etwas sendest. DU
> musst schon mehr zeigen - viel mehr. Auch den Schaltplan und welches
> Board du verwendest.

Ich verwende das STM32F030-Discovery.

Gesendet wird hiermit:

void         USARTSendData( USART_TypeDef *pUsart , uint8_t uiTx )
{
    while(!(pUsart->CR1 & USART_ISR_TXE));
    pUsart->TDR = uiTx;
}

Wenn ich hier den ganzen Code rein haue wird es zu unübersichtlich..

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Ich würde erstmal LED an die beiden Pins anschließen und blinken lassen.
> Danach kannst du sie mal seriell benutzen, aber mit niedriger Baudrate
> denn dann kannst du die LED blinken sehen.

Das Oszi. zeigt mir keinerlei Bewegung an.

[Stefan F. (Gast)]

Jan H. schrieb:
> Also laut Datenblatt lese ich 8Mhz raus.

Ich auch

Jan H. schrieb:
> Wenn ich hier den ganzen Code rein haue wird es zu unübersichtlich..

Du kannst die Dateien anhängen, gerne auch als ZIP.

Solange du weder den relevanten Code noch die Schaltung zeigst, können 
wir nur dumm herum raten. Das führt zu unnötigem Frust.

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Jan H. schrieb:
>
>> Also laut Datenblatt lese ich 8Mhz raus.
>
> Ich auch
> Jan H. schrieb:
>
>> Wenn ich hier den ganzen Code rein haue wird es zu unübersichtlich..
>
> Du kannst die Dateien anhängen, gerne auch als ZIP.
> Solange du weder den relevanten Code noch die Schaltung zeigst, können
> wir nur dumm herum raten. Das führt zu unnötigem Frust.

Ja das stimmt.
Leider habe ich aktuell nicht die Möglichkeit eine ZIP zu erstellen.

https://www.dropbox.com/sh/bmcwesnp0qkhwu6/AABg2HfZRNAyKzky1DSJCTrZa?dl=0

[Stefan F. (Gast)]

Jan H. schrieb:
> Leider habe ich aktuell nicht die Möglichkeit eine ZIP zu erstellen.

????????

Wenn dir gar nichts besseres einfällt, dann klicke mal in deiner Dropbox 
auf "Herunterladen" und staune, was dann passiert.

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Jan H. schrieb:
>
>> Leider habe ich aktuell nicht die Möglichkeit eine ZIP zu erstellen.
>
> ????????
> Wenn dir gar nichts besseres einfällt, dann klicke mal in deiner Dropbox
> auf "Herunterladen" und staune, was dann passiert.

Das gab es mal.. Jetzt muss man auf Premium Upgraden.. Diese Option mit 
dem Download habe ich in der App nicht mehr.

[Stefan F. (Gast)]

void USARTSendData( USART_TypeDef *pUsart , uint8_t uiTx )
{
    while(!(pUsart->CR1 & USART_ISR_TXE));
    pUsart->TDR = uiTx;
}

Hier fragst du das Register USART->CR1 ab, benutzt aber eine Bitmaske 
die zum USART->ISR Register gehört. Die Maske hat den Wert 0x80, damit 
fragst du also effektiv das Bit "TXEIE: interrupt enable" ab.

Du willst da doch abfragen, ob der Sende-Puffer frei ist. Dazu musst du 
schreiben:

while(!(pUsart->ISR & USART_ISR_TXE));

[Stefan F. (Gast)]

Jan H. schrieb:
> Das gab es mal.. Jetzt muss man auf Premium Upgraden.. Diese Option mit
> dem Download habe ich in der App nicht mehr.

Warum sehe ich das dann? Ich habe überhaupt keinen Dropbox Account und 
auch keine App.

Und warum kannst du kein ZIP erstellen? Das kann doch jedes 
Linux/Windows im ganz normalen Dateimanager.

[Stefan F. (Gast)]

Wenn du das Programm Zeile für Zeile im Debugger ausführen würdest, dann 
würdest du auch sehen, dass es in der while Schleife festhängt.

Oder einfach starten und dann auf pause klicken. Auch dann wird es auch 
in der while Schleife stehen.

Bevor du dich noch weiter mit Register befasst scheint es besser zu 
sein, du übst erst einmal, deine Arbeitsmittel zu benutzen.

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Jan H. schrieb:
>
>> Das gab es mal.. Jetzt muss man auf Premium Upgraden.. Diese Option mit
>> dem Download habe ich in der App nicht mehr.
>
> Warum sehe ich das dann? Ich habe überhaupt keinen Dropbox Account und
> auch keine App.
> Und warum kannst du kein ZIP erstellen? Das kann doch jedes
> Linux/Windows im ganz normalen Dateimanager.

Ja ich bin aktuell unterwegs und habe nur dad Handy. Über den Browser 
geht es nach wie vor. Habe ich auch gerade gemerkt.
Es funktioniere auch mal über die App, diese Funktion ist aber Anscheind 
jetzt kostenpflichtig geworden.

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Oder einfach starten und dann auf pause klicken. Auch dann wird es auch
> in der while Schleife stehen.

Muss ich mal schauen.
Was heißt denn stehen? Ruft er die sende Routine gar nicht auf?
Schaue ich mir morgen mal mit dem Debugger an.

[Stefan F. (Gast)]

Jan H. schrieb:
> Ja ich bin aktuell unterwegs und habe nur dad Handy.

Ach so. Interessante arbeitsweise. Ich war davon ausgegangen, dass du 
vorm Rechner sitzt. Naja, meine Kinder machen auch viel mehr mobil, als 
ich.

Jan H. schrieb:
> Was heißt denn stehen? Ruft er die sende Routine gar nicht auf?

Er führt die while Schleife immer wieder endlos oft aus

> while(!(pUsart->CR1 & USART_ISR_TXE));

weil das (falsche) Bit niemals auf 1 geht. Die Zeile darunter, wird 
daher niemals ausgeführt:

> pUsart->TDR = uiTx;

Und dann ist auch klar, warum sich an der txD Leitung nichts tut.

> Muss ich mal schauen.

Mache das. Der Debugger ist sehr nützlich. Ein paar Hinweise dazu:
http://stefanfrings.de/stm32/cube_ide.html
http://stefanfrings.de/mikrocontroller_buch2/Einblick%20in%20die%20moderne%20Elektronik.pdf#page=27

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Jan H. schrieb:
>
>> Ja ich bin aktuell unterwegs und habe nur dad Handy.
>
> Ach so. Interessante arbeitsweise. Ich war davon ausgegangen, dass du
> vorm Rechner sitzt. Naja, meine Kinder machen auch viel mehr mobil, als
> ich.
> Jan H. schrieb:
>
>> Was heißt denn stehen? Ruft er die sende Routine gar nicht auf?
>
> Er führt die while Schleife immer wieder endlos oft aus
>> while(!(pUsart->CR1 & USART_ISR_TXE));
>
> weil das (falsche) Bit niemals auf 1 geht. Die Zeile darunter, wird
> daher niemals ausgeführt:
>> pUsart->TDR = uiTx;
>
> Und dann ist auch klar, warum sich an der txD Leitung nichts tut.
>> Muss ich mal schauen.
>
> Mache das. Der Debugger ist sehr nützlich. Ein paar Hinweise dazu:
> http://stefanfrings.de/stm32/cube_ide.html
> 
http://stefanfrings.de/mikrocontroller_buch2/Einblick%20in%20die%20moderne%20Elektronik.pdf#page=27

Ich habe die Abfrage des Registers geändert, wie von Dir weiter oben 
angemerkt.

Laut Debugger beschreibt er das Daten Register auch mit dem richtigen 
Wert.
Habe vorsichtshalber mal ein paar mehr Zeichen gesendet.

Es passiert leider nach wie vor nichts am TxD.
Als wenn er keinen Takt hätte...
Aber wenn die Peripherie keinen Takt hat, können die Register ja auch 
nicht beschrieben werden bzw. arbeiten nicht richtig..

[Stefan F. (Gast)]

Jan H. schrieb:
> Aber wenn die Peripherie keinen Takt hat, können die Register ja auch
> nicht beschrieben werden bzw. arbeiten nicht richtig..

Das denke ich auch. Vor allem könntest du dann maximal 2 bytes ausgeben, 
danach ist Schluss, weil das Sende-Register niemals leer wird.

Gehe nochmal einen Schritt zurück und lasse eine LED an dem Pin blinken. 
Kontrolliere damit auch das Oszilloskop, damit die sicher bist, dass die 
Verkabelung OK ist.

[Jan H. (janiiix3)]

Muss man denn den entsprechenden GPIOs die diese alternative Funktion 
unterstützen noch weiter konfigurieren, sprich z.B den Ausgangs Type?

[Stefan F. (Gast)]

Jan H. schrieb:
> Muss man denn den entsprechenden GPIOs die diese alternative Funktion
> unterstützen noch weiter konfigurieren, sprich z.B den Ausgangs Type?

Das hats du doch schon gemacht, laut Eröffnungsbeitrag.

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Jan H. schrieb:
>> Muss man denn den entsprechenden GPIOs die diese alternative Funktion
>> unterstützen noch weiter konfigurieren, sprich z.B den Ausgangs Type?
>
> Das hats du doch schon gemacht, laut Eröffnungsbeitrag.

Ja das weiß ich selber. Die Frage war ja auch ob man das machen MUSS.

[Stefan F. (Gast)]

Jan H. schrieb:
> Ja das weiß ich selber. Die Frage war ja auch ob man das machen MUSS.

Dir schon jemand eiter oben geschrieben, dass en unnötig ist.

Wenn du dennoch unsicher bist, probiere es aus oder gehe ein Tutorial 
zum Thema durch. Zum Beispiel das vom professor Latorre: 
http://www.pomad.fr/node/13

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Jan H. schrieb:
>> Ja das weiß ich selber. Die Frage war ja auch ob man das machen MUSS.
>
> Dir schon jemand eiter oben geschrieben, dass en unnötig ist.
>
> Wenn du dennoch unsicher bist, probiere es aus oder gehe ein Tutorial
> zum Thema durch. Zum Beispiel das vom professor Latorre:
> http://www.pomad.fr/node/13

Ja okay.
Also den Tx Pin kann ich toggeln. Nur funktioniert nach wie vor der 
USART nicht warum auch immer..

[Jan H. (janiiix3)]

Fehler gefunden und behoben.
Danke!

[Stefan F. (Gast)]

Jan H. schrieb:
> Fehler gefunden und behoben.
> Danke!

Stopp, nicht so schnell! Nachdem wir dir geholfen haben solltest du uns 
wenigstens berichten, was der Knackpunkt war.

[Jan H. (janiiix3)]

Stefan ⛄ F. schrieb:
> Jan H. schrieb:
>> Fehler gefunden und behoben.
>> Danke!
>
> Stopp, nicht so schnell! Nachdem wir dir geholfen haben solltest du uns
> wenigstens berichten, was der Knackpunkt war.

Na gut..
Also ich habe in meiner GPIOxx Lib einen kleinen Fehler in einer if 
Abfrage gehabt.

GPIO_RETURN_CODE_t   GPIOSelectAltFunc( GPIO_TypeDef *pPort , GPIO_PIN_NUMBER_t ePin, GPIO_ALT_FUNC_t eAltFunc )
{
  uint8_t uiPin;

  if ( GPIOVerifyPort( pPort ) != PORT_OK )
  {
    return PORT_UNKNOWN;
  }

  if ( GPIOVerifyPin( ePin ) != PIN_OK )
  {
    return PIN_UNKNOWN;
  }

  if ( eAltFunc >= __GPIO_ALT_FUNC_MAX__ )
  {
    return ALT_FUNC_UNKNOWN;
  }

  
  if ( ( GPIO_ALT_FUNC_t ) ePin <= GPIO_ALT_FUNC_7 )
  {
    pPort->AFR[0] &= ~( 0x0F << ( ePin * 4 ) );
    pPort->AFR[0] |= ( eAltFunc << ( ePin * 4 ) );
  }
  else if ( (GPIO_ALT_FUNC_t) ePin > GPIO_ALT_FUNC_7 )
  {
    uiPin = ePin - GPIO_ALT_FUNC_8;
    pPort->AFR[1] &= ~( 0x0F << ( uiPin  * 4 ) );
    pPort->AFR[1] |= ( eAltFunc << ( uiPin  * 4 ) );
  }

  return ALT_FUNC_OK;
}

Nachdem ich mir die Register mit dem Debugger mal genauer angeschaut 
habe, ist mir aufgefallen das er die alternativen Funktionen nicht 
wirklich an die richtige Stelle im Register schreibt da hier eine kleine 
Berechnung falsch war..

  if ( eAltFunc <= GPIO_ALT_FUNC_7 ) // eAltFunc ist hier falsch
  {
    pPort->AFR[0] &= ~( 0x0F << ( ePin * 4 ) );
    pPort->AFR[0] |= ( eAltFunc << ( ePin * 4 ) );
  }
  else if ( eAltFunc > GPIO_ALT_FUNC_7 ) // und hier auch..
  {
    uiPin = ePin - GPIO_ALT_FUNC_8;
    pPort->AFR[1] &= ~( 0x0F << ( uiPin  * 4 ) );
    pPort->AFR[1] |= ( eAltFunc << ( uiPin  * 4 ) );
  }