USART mit STM32 Discovery

[Stefan S. (v0od0o)]

Hallo zusammen,
ich mache gerade meine ersten Schritte mit einem STM32 Discovery Board 
nach der Methode Learning by Copying. Aktuell bin ich mit dem Versuch 
beschäftigt, über USART ein paar Bytes vom uC an den PC zu schicken. Als 
Entwicklungsumgebung nutze ich Atollic, und da mein Notebook keinen 
seriellen Port hat, verwende ich so einen fertigen RS232-To-USB-Adapter. 
Zugriff auf die serielle Schnittstelle erfolgt dann einfach und 
unkompliziert über MATLAB.

Das Problem ist nur: es funktioniert nicht. Zwar empfängt MATLAB nur 
dann etwas, wenn ich etwas sende - was schon einmal zeigt, dass es nicht 
gar nicht tut, allerdings kommt hinten nicht das raus, was ich vorne 
reingeschickt habe.

Wenn ich also z.B. fünf Nullbytes schicke und danach acht mal FF, dann 
kommt folgendes am anderen Ende an:

00000000
11111111
11111111
11111110
11111110
00000010
00001000
00010000
01000000
10000000
00000000
00000000
00000000
00000001
00000000

Wenn ich dann die gleiche Sequenz wieder durchlaufen lasse (stets vom 
Debugger aufgehalten, damit ich nachschauen kann, was es denn geworden 
ist), dann erhalte ich reproduzierbar dieses:

11111110
11111110
11111110
11111110
00000010
00001000
00010000
01000000
10000000
00000000
00000000
00000000
00000001
00000000

Auf einer anderen Seite habe ich schon gelesen, dass es da irgendein 
Problem mit einer bereits kompilierten Lib gibt, die möglicherweise 
dafür sorgt, dass der STM mit einer falschen Baudrate sendet. In den 
mittigen Bytes sieht es ja auch so aus, als müsste pro Byte etwa ein Bit 
mehr gelesen werden. Allerdings verändert ein Erhöhen der 
MATLAB-Baudrate auf 10800 das Ergebnis nicht. (Vielleicht tut MATLAB 
auch nur so, als könnte es jede beliebige Baudrate einstellen und rundet 
in Wirklichkeit auf den nächsten üblichen Wert).

In jedem Fall ist mir unerklärlich, warum die Empfangsdaten im Prinzip 
beinahe dem Inversen der Sendedaten entsprechen. Ich meine, selbst wenn 
die Pegel leicht unterschiedlich sein sollten, weil sich der uC eher zu 
3V hingezogen fühlt und der USB-Adapter eher zu 5V  -  da drehen sich 
doch nicht die Logikwerte, oder!?

Mit anderen Worten: Hülfe!

Hier noch mein aufgrund des C&P-Bastelstadiums etwas ungeordneter 
STM32-Code:

#include "stm32f10x.h"
u16 ADC_Data;


void Usart1Init(void);
void Usart1Put(uint8_t ch);

void ADConverter_Init( void )
    {
    ADC_InitTypeDef  ADC_InitStructure;
    GPIO_InitTypeDef GPIO_InitStructure;

    // Enable PORT clock
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);

    /* Configure pin as analog input ---------------*/
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN;
    GPIO_Init(GPIOC, &GPIO_InitStructure);

    /* Enable ADC1 clock */
    RCC_APB2PeriphClockCmd( RCC_APB2Periph_ADC1, ENABLE );

    /* ADC1 Configuration ------------------------------------------------------*/
    ADC_InitStructure.ADC_Mode                = ADC_Mode_Independent;
    ADC_InitStructure.ADC_ScanConvMode        = DISABLE;
    ADC_InitStructure.ADC_ContinuousConvMode  = DISABLE;
    ADC_InitStructure.ADC_ExternalTrigConv    = ADC_ExternalTrigConv_None;
    ADC_InitStructure.ADC_DataAlign           = ADC_DataAlign_Right;
    ADC_InitStructure.ADC_NbrOfChannel        = 1;
    ADC_Init( ADC1, &ADC_InitStructure );

    /* ADC1 Regular Channel 14 */
    ADC_RegularChannelConfig( ADC1, ADC_Channel_14,  1, ADC_SampleTime_239Cycles5);

    /* Enable ADC1 external trigger conversion */
    ADC_ExternalTrigConvCmd( ADC1, ENABLE );

    /* Enable ADC1  */
    ADC_Cmd(ADC1, ENABLE);

    /* Enable ADC1 reset calibaration register */
    ADC_ResetCalibration(ADC1);

    /* Check the end of ADC1 reset calibration register */
    while(ADC_GetResetCalibrationStatus(ADC1));

    /* Start ADC1 calibaration */
    ADC_StartCalibration(ADC1);

    /* Check the end of ADC1 calibration */
    while(ADC_GetCalibrationStatus(ADC1));

    }

u16 Get_Measure()
    {
    // Start ADC1 Software Conversion
    ADC_SoftwareStartConvCmd( ADC1, ENABLE );

     // Wait for end of conversion
    while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET);

    // Return the conversion value
    return (ADC_GetConversionValue(ADC1));
    }


/* Private function prototypes -----------------------------------------------*/
void RCC_Configuration(void);
void GPIO_Configuration(void);
void Delay(__IO uint32_t nCount);
void start_dma(uint32_t *sintable);

/* Private functions ---------------------------------------------------------*/

/**
  * @brief   Main program.
  * @param  None
  * @retval None
  */
int main(void)
{


  RCC_Configuration();

  /* Enable GPIOx Clock */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);

  /* Initialise LEDs LD3&LD4, both off */
  GPIO_DeInit(GPIOC);

  ADConverter_Init();


  Usart1Init();


  /* main while */
  while(1)
  {
    ADC_Data = Get_Measure();

    Usart1Put(0x00);
    Usart1Put(0x00);
    Usart1Put(0x00);
    Usart1Put(0x00);
    Usart1Put(0x00);
    Usart1Put(0xFF);
    Usart1Put(0xFF);
    Usart1Put(0xFF);
    Usart1Put(0xFF);
    Usart1Put(0xFF);
    Usart1Put(0xFF);
    Usart1Put(0xFF);
    Usart1Put(0xFF);
    Delay(10);

  }
}

/**
  * @brief  Inserts a delay time.
  * @param  nTime: specifies the delay time length, in milliseconds.
  * @retval None
  */
void Delay(uint32_t nTime)
{
  uint32_t TimingDelay = nTime;
  uint32_t i;

  while(TimingDelay != 0){
    i = 1000;
    while( i > 0 ){
      i--;
    }//*/
    TimingDelay--;
  }
}

/**
  * @brief  Decrements the TimingDelay variable.
  * @param  None
  * @retval None
  */

void RCC_Configuration(void)
{
  /* RCC system reset(for debug purpose) */
  RCC_DeInit();

  /* Enable HSE */
  RCC_HSEConfig(RCC_HSE_ON);

  /* Wait till HSE is ready */
  ErrorStatus HSEStartUpStatus = RCC_WaitForHSEStartUp();

  if(HSEStartUpStatus == SUCCESS)
  {
    /* Enable Prefetch Buffer */
    FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);

    /* Flash 2 wait state */
    FLASH_SetLatency(FLASH_Latency_0);

    /* HCLK = SYSCLK */
    RCC_HCLKConfig(RCC_SYSCLK_Div1);

    /* PCLK2 = HCLK */
    RCC_PCLK2Config(RCC_HCLK_Div1);

    /* PCLK1 = HCLK/2 */
    RCC_PCLK1Config(RCC_HCLK_Div1);

    /* ADCCLK = PCLK2/4 */
    RCC_ADCCLKConfig(RCC_PCLK2_Div4);

    /* PLLCLK = 8MHz * 7 = 56 MHz */
    //RCC_PLLConfig(RCC_PLLSource_PREDIV1, RCC_PLLMul_7);

    /* PLLCLK = (8MHz/2) * 6 = 24 MHz */
        RCC_PREDIV1Config(RCC_PREDIV1_Source_HSE, RCC_PREDIV1_Div2);
        RCC_PLLConfig(RCC_PLLSource_PREDIV1, RCC_PLLMul_6);

    /* Enable PLL */
    RCC_PLLCmd(ENABLE);

    /* Wait till PLL is ready */
    while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET)
    {
    }

    /* Select PLL as system clock source */
    RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);

    /* Wait till PLL is used as system clock source */
    while(RCC_GetSYSCLKSource() != 0x08)
    {
    }
  }

/* Enable peripheral clocks --------------------------------------------------*/
  /* Enable DMA1 and DMA2 clocks */
  RCC_AHBPeriphClockCmd(RCC_AHBPeriph_DMA1, ENABLE);

  /* Enable ADC1, ADC2, ADC3 and GPIOC clocks */
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1 | RCC_APB2Periph_GPIOC, ENABLE);
}

void Usart1Init(void)

{

GPIO_InitTypeDef GPIO_InitStructure;
USART_InitTypeDef USART_InitStructure;
USART_ClockInitTypeDef USART_ClockInitStructure;

//enable bus clocks
RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1 | RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE);

//Set USART1 Tx (PA.09) as AF push-pull
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init(GPIOA, &GPIO_InitStructure);

//Set USART1 Rx (PA.10) as input floating
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
GPIO_Init(GPIOA, &GPIO_InitStructure);
USART_ClockStructInit(&USART_ClockInitStructure);
USART_ClockInit(USART1, &USART_ClockInitStructure);

USART_InitStructure.USART_BaudRate = 9600;
USART_InitStructure.USART_WordLength = USART_WordLength_8b;
USART_InitStructure.USART_StopBits = USART_StopBits_1;
USART_InitStructure.USART_Parity = USART_Parity_No ;
USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;

//Write USART1 parameters
USART_Init(USART1, &USART_InitStructure);

//Enable USART1
USART_Cmd(USART1, ENABLE);
}

void Usart1Put(uint8_t ch)
{
    USART_SendData(USART1, (uint8_t) ch);
    //Loop until the end of transmission
    while(USART_GetFlagStatus(USART1, USART_FLAG_TC) == RESET)
    {
    }
}

[RP6Conrad (Gast)]

Hasst du auch noch ein Level-converter um von 3 Volt (UART Discovery) 
nach +/-13 V RS232 Level (PC)  zu schalten ?

[Stefan S. (v0od0o)]

Hallo RP6Conrad,
Nein, habe ich nicht. Allerdings versorgt sich der USB-Adapter eben über 
den USB-Port, d.h. knappe 5 Volt. Zudem sende ich momentan nur von uC zu 
PC und nicht anders herum, sodass der Pegel auf PC-Seite kaum relevant 
sein sollte, solange sich der uC an den Standard hält.

[Robert (Gast)]

Hast Du

#define PLL_M      8
und
HSE_VALUE = 8000000

mal geändert?

[Noname (Gast)]

RP6Conrad:
>Hasst du auch noch ein Level-converter um von 3 Volt (UART Discovery)
>nach +/-13 V RS232 Level (PC) zu schalten ?

Stefan S.:
>Nein, habe ich nicht. Allerdings versorgt sich der USB-Adapter eben über
>den USB-Port, d.h. knappe 5 Volt. Zudem sende ich momentan nur von uC zu
>PC und nicht anders herum, sodass der Pegel auf PC-Seite kaum relevant
>sein sollte, solange sich der uC an den Standard hält.

Ich kenne nun nicht alle Discovery Boards, nur das Discovery STM32F1 
(welches hast Du denn Stefan?), aber soweit ich weiss haben die keinen 
Pegelwandler an Board.

Inwiefern Deine Antwort, Stefan, die von RP6Conrad gestellte Frage 
beantwortet ist mir nicht klar. Denn es bleiben folgende Tatsachen zu 
bedenken:
1. Der USART1 des STM gibt 0V/3,3V aus und sein Eingang erwartet 
0V/3,3V. Darüber hinaus ist gerade dieser Eingang nicht 5V tolerant, 
ganz zu schweigen von +/- 13V.
2. Wenn also der RS232-USB Converter an seinem RX-Eingang nur 0V/3,3V 
sieht dann kann das unter Umständen als Pegelwechsel verstanden werden 
oder auch nicht. Das hängt von der konkreten Schaltung des Eingangs ab. 
Eigentlich sollen dort die +/- 13V zu sehen sein.
3. Die Pegel werden an den Ausgängen des STM invertiert ausgegeben resp. 
invertiert am Eingang erwartet. Die üblichen Pegelwandler invertieren 
nämlich. Das würde die invertierten Daten erklären, wenn auch einzelne 
Bytes resp. Bits nicht invertiert worden sind. Das wird mit Punkt 2. 
zusammenhängen.
4. Ob der RS232/USB Wandler vom PC mit 5V versorgt wird ist für diese 
Punkte irrelevant. Das ändert nichts an den anderen Tatsachen.

Was meinst Du dazu, Stefan?

[Stefan S. (v0od0o)]

@Robert:
außerhalb der main.c habe ich, soweit ich mich erinnern kann, nicht 
verändert.

@Noname:
Ah, mir scheint ich bin von einigen grundlegenden Voraussetzungen 
ausgegangen, die du gerade als grundlegend falsch herausgestellt hast. 
Wenn ich die ganze Zeit invertierte Signale an den PC schicke, dann kann 
auch nicht viel dabei herauskommen, da ja nicht einmal die Start- und 
Stoppbits richtig erkannt werden können, selbst wenn es die 
Pegelprobleme nicht gäbe. Dann werd ich mich wohl mal wieder in die 
Bastelecke zurückziehen. Vielen Dank!

PS: mein Controller ist ein STM32F103 oder so und die Pins von USART1 
sind als 5V-tolerant angegeben.

[Noname (Gast)]

>mein Controller ist ein STM32F103 oder so und die Pins von USART1
>sind als 5V-tolerant angegeben.

Du redest wahrscheinlich vom Discovery VL.
Aufgepasst. Der 103 ist der Debugger/Flasher der über USB an den PC 
angeschlossen wird. Das ist nicht der Prozessor auf dem Dein Programm 
läuft. Auf dem Discovery VL ist ein STM32F100 der eigentliche 
Anwendungsprozessor.

Wie auch immer: Auch bei dem F100 sind die USART1 Pins fünf Volt 
tolerant. Da habe ich was falsches geschrieben.

[Stefan S. (v0od0o)]

Achso ja, steht sogar drauf wenn man genau guckt. Ich hatte gedacht, das 
F100 wäre der Oberbegriff und nicht der eigentlich richtige Controller. 
Aber naja. Praktischerweise sind ja die Dokumentationen für F10x - 
zumindest jene, die mir bisher über den Weg gelaufen sind.

Joa, VL ist richtig. Wenn man "STM32 Discovery" in die Google 
Bildersuche eingibt, sieht aber eh alles gleich aus - somit seh ich da 
auf den ersten Blick kein Unterscheidungsmerkmal zu etwaigen anderen 
STM32 Discovery-Boards.

[Robert (Gast)]

Robert schrieb

> Hast Du
>
>
>
> #define PLL_M      8
>
> und
>
> HSE_VALUE = 8000000
>
>
>
> mal geändert?

Sorry, da habe Ich das Board verwechselt.
Das bezieht sich auf STM32F4 Discovery.