[Cortex-M3] Problem mit dem UART

[Philipp (Gast)]

Hallo,
ich setze gerade ein neues Projekt auf und bin schon am verzweifeln. Die 
Initialisierung des UART (STM32F103RB) funktioniert nicht.

Während des ladens (OLIMEX OCD mit Board von OLIMEX) kommen kurz einige 
Zeichen und dann ist Stille.

Hier der wichtigste Code.

int main()
{
    GPIO_InitTypeDef    GPIO_InitStructure;
    USART_InitTypeDef   USART_InitStructure;

    uint8_t byRecBuffer[64] = "Das ist ein Test\r\n";
    uint8_t byRecBufferIndex = 0;

    /* Configure the system clocks */
    RCC_Configuration();
      
    // Enable GPIO clock
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE);
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);

    /* NVIC Configuration */
    NVIC_Configuration();

    /* Enable GPIOC clock */
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);

    // Configure PC.12 as Output push-pull 
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_Init(GPIOC, &GPIO_InitStructure);

    // Tx1 as Push-Pull
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
    GPIO_Init(GPIOA, &GPIO_InitStructure);

    // Rx1 as Floating
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
    GPIO_Init(GPIOA, &GPIO_InitStructure);

    // Tx2 as Push-Pull
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
    GPIO_Init(GPIOA, &GPIO_InitStructure);

    // Rx2 as Floating
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
    GPIO_Init(GPIOA, &GPIO_InitStructure);

    // init Terminal
    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_HardwareFlowControl =   USART_HardwareFlowControl_None;
    USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
    USART_Init(USART2, &USART_InitStructure);
  
    // enable serial
    USART_Cmd(USART2, ENABLE);

    // Enable the USART2 Pins Software Remapping
    GPIO_PinRemapConfig(GPIO_Remap_USART2, ENABLE);  
 
    while (1)
    {
      byRecBufferIndex = 0;
    
      while (byRecBufferIndex < strlen(byRecBuffer))
      {
        /* Wait until end of transmit */
        while(USART_GetFlagStatus(USART2, USART_FLAG_TXE)== RESET);

        /* Write one byte in the USARTz Transmit Data Register */
        USART_SendData(USART2, byRecBuffer[byRecBufferIndex++]);
      }
    }
 
    return 0;
}

Schon mal Danke fürs ansehen.

Philipp

[Tartaruga (Gast)]

Hi

Hast du das Problem schon gelöst? Ich steh jetzt nämlich vor den selben 
Problem. Vielleicht hast du ja einen Tipp ??

Lg

[Gebhard R. (Firma: Raich Gerätebau & Entwicklung) (geb)]

Auf ersten Blick sollte das funktionieren, weiß allerdings nichts über
RCC_Configuration();
Am besten die Geschichte auf dauersenden stellen (z. B. 0xAA senden) und 
mit dem Oszi mal die Baudrate kontrollieren.

Grüße

[KeinPlan (Gast)]

Versuch mal ob es was bringt, das Remap vor der GPIO PIN Config 
auszuführen.

[Markus (Gast)]

Hi
Ich hab folgenden Code verwendet. Die Funktionen sind eh von der 
standard library von stm.

int main(void){

USART_InitTypeDef USART_InitStructure;
uint8_t TxBuffer[] = "AT\n";
uint8_t RxBuffer[RxBufferSize];
uint8_t NbrOfDataToTransfer = TxBufferSize;
uint8_t TxCounter = 0;
uint8_t RxCounter = 0;

/*RCC Configuration*/
{//start RCCConfig
  /* Setup the microcontroller system. Initialize the Embedded Flash Interface,  
     initialize the PLL and update the SystemFrequency variable. */
  SystemInit();
    
  /* Enable GPIOx and AFIO clocks */
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE);

  /* Enable USART2 clocks */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);
}//end RCCConfig

/*GPIO Configuration*/
{//start GPIOConfig

GPIO_InitTypeDef GPIO_InitStructure;

  GPIO_PinRemapConfig(GPIO_Remap_USART2, ENABLE);

  /* Configure USART2 RTS and USART2 Tx as alternate function push-pull */
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_2;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
  GPIO_Init(GPIOA, &GPIO_InitStructure);

  /* Configure USART2 CTS and USART2 Rx as input floating */
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_3;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
  GPIO_Init(GPIOA, &GPIO_InitStructure);

}//end GPIOConfig

/*LastUartConfiguration*/

{//start LastUartConfig

  USART_InitStructure.USART_BaudRate = 115200;
  USART_InitStructure.USART_WordLength = USART_WordLength_8b;
  USART_InitStructure.USART_StopBits = USART_StopBits_1;
  USART_InitStructure.USART_Parity = USART_Parity_No;
  USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_RTS_CTS;
  USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;    //Receive and transmit is enabled

  USART_Init(USART2, &USART_InitStructure);
  USART_Cmd(USART2, ENABLE);
}//end LastUartConfig


while(1)//(NbrOfDataToTransfer--)
  {
    USART_SendData(USART2, (uint16_t)0xAA);
  //USART_SendData(USART2, TxBuffer[TxCounter++]);
    while(USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET);          
  }
  
  /* Receive a string (Max RxBufferSize bytes) 
  do
  { 
    if((USART_GetFlagStatus(USART2, USART_FLAG_RXNE) != RESET)&&(RxCounter < RxBufferSize))
    {
       RxBuffer[RxCounter] = USART_ReceiveData(USART2);
       //USART_SendData(USART2, RxBuffer[RxCounter++]);
    }   
 
  }
  while((RxBuffer[RxCounter - 1] != '\n')&&(RxCounter != RxBufferSize));

  while (1)
  {
  }




}//end main

Ich was ich nciht verstehe ist warum in der Funktion 
"USART_SendData(USART2, (uint16_t)0xAA)"

void USART_SendData(USART_TypeDef* USARTx, uint16_t Data)
{
  /* Check the parameters */
  assert(IS_USART_ALL_PERIPH(USARTx));
  assert(IS_USART_DATA(Data)); 
    
  /* Transmit Data */
  USARTx->DR = Data;//(Data & (uint16_t)0x01FF);

wird bei der Zuweisung an das USARTx->DR nichts hineingeschrieben. Also 
wenn ich beim Debuggen einen schritt drüber bin dann hat das Register 
keinen Wert. Anbei hänge ich noch ein Bild von meinen Einstellungen an. 
Da ist auch zu sehen dass das Register leer ist :-(

Ich hoffe es kann mir wer weiterhelfen

danke schon mal im Vorraus

Lg
Markus

[(prx) A. K. (prx)]

Offen hängender Kommentar.

Da DR eigentlich 2 Register darstellt, eines pro Richtung, und ausserdem 
der Inhalt der sendenden Richtung u.U. sofort ins Schieberegister 
wandert, hat ein Debugger Probleme, den Inhalt wie von dir erwartet 
anzuzeigen.

Manche Pins mit mehreren Zusatzfunktionen sind etwas verknotet. Siehe 
Errata.

[Markus (Gast)]

OK verstehe... Ich hab aber den Pin schon ans Oszi gehängt so wie es 
schon vorgeschlagen worden ist und ich musste leider feststellen das der 
Tx Pin auf +2,5 V geschalten wird.

[Random .. (thorstendb)]

Hi Leutz,

hier mal das ganze ohne dieses DriverLibGeraffel. Da hat man immer 
Probleme, wenn was nicht funzt und muss doch auf die Regs runter.
Daher nutze ich die DLs nur als Example - mehr nicht.


VG,
/th.

[Gebhard R. (Firma: Raich Gerätebau & Entwicklung) (geb)]

Du remapst Uart2, da werden doch die Pins PD5/6 verwendet, die du aber 
nicht konfigurierst. Mach das mal.

Grüße Gebhard

[Random .. (thorstendb)]

ei ...
so viele Downloads - any comments?

VG,
/th.

[(prx) A. K. (prx)]

Markus schrieb:

> schon vorgeschlagen worden ist und ich musste leider feststellen das der
> Tx Pin auf +2,5 V geschalten wird.

Das klingt eher so, als würde an dem Pin überhaupt nichts verschaltet, 
denn 2,5V ist bei nicht exzessiver Last nix Halbes und nix Ganzes, 
jedenfalls bei 3,3V Versorgung.

Passt auch zum Code. Du konfigurierst die standardmässigen GPIO Pins auf 
PORTA für UART2, leitest UART2 aber auf die alternativen abgeschalteten 
PORTD Pins um. Willst du die nun auf PORTA (dann lass den Remap weg) 
oder auf PORTD (dann konfiguriere die richtigen Portpins)?

[(prx) A. K. (prx)]

Random ... schrieb:
> Hi Leutz,
>
> hier mal das ganze ohne dieses DriverLibGeraffel. Da hat man immer
> Probleme, wenn was nicht funzt und muss doch auf die Regs runter.
> Daher nutze ich die DLs nur als Example - mehr nicht.

In USART*_IRQHandler

volatile unsigned int IIR;
...
USART1->SR &= ~USART_FLAG_RXNE;         // clear interrupt
u1_rxBuffer_putchar(USART1->DR & 0xFF); // write buffer

wird das RXNE Bit vom Lesen von DR automatisch kassiert, muss also nicht 
explizit gelöscht werden. Und das volatile ist für solche lokale 
Variablen überflüssig (ziemlich ineffizient).

[Random .. (thorstendb)]

g ist irgendein rest, der mal übriggeblieben ist, den ich dann in die 
Fkt geschrumpft, aber nicht komplett angepasst hab ^^

[Markus (Gast)]

Eigentlich will ich den UART 2 schon auf Port A ausgeben. Vorallem weil 
der Port D bei meine Eval Board (STM32-H103) nicht rausgeführt wird.

Also wenn ich das Remap weglasse dann wird nach dem Senden des 1. 
Zeichens das USART_FLAG_TXE Flag nicht mehr auf SET geschalten die 
Abfrage ist dann quasi eine endless loop

Lg

Danke Random ... für deinen Code... hab leider jetzt erst am Abend Zeit 
mit das anzusehen

[DrMaex (Gast)]

Hallo, bin gerade auch damit beschäftigt mit dem STM32-H103 Board 
Zeichen über den USART zu schicken und wollte fragen ob es jetzt einem 
hier gelungen ist und welche Einstellungen dazu vorgenommen werden 
müssen.
Mit Hilfe von "A.K." habe ich es zwar geschafft überhaupt Etwas heraus 
zu schicken aber es ist auf keinem Fall das, was ich schicken will. Am 
Hyperterminal empfange ich nur Smilies, Dreiecke und so weiter. Advanced 
Serial Port Monitor weigert sich komplett was zu empfangen......habe die 
main.c angehänt.
Was mir im Moment auch nicht klar ist, warum meine LED durchgehend 
leuchtet....theoretisch sollte da ein deutlich wahrnehmbares Blinken 
vorhanden sein...


Vielen Dank im Voraus


Max

[(prx) A. K. (prx)]

DrMaex schrieb:

> zu schicken aber es ist auf keinem Fall das, was ich schicken will. Am
> Hyperterminal empfange ich nur Smilies, Dreiecke und so weiter.

Wetten dass die Bitrate falsch ist? Da die Lib zwar umständlich aber 
richtig rechnet, geht sie vermutlich von einer falschen Annahme über den 
Takt des betreffenden APB Busses aus.

[DrMaex (Gast)]

Hmm also ehrlich gesagt stehe ich etwas auf dem Schlauch....
habe die clk_Init() etwas verändert was allerdings keine Veränderung 
gebracht hat...ich schildere meinen Gedankengang bzw. Interpretation:

void Clk_Init (void)
{
 //Internen Oscillator starten (8 MHz)
  RCC_HSICmd(ENABLE);
 
 // warten bis fertig
  while(RCC_GetFlagStatus(RCC_FLAG_HSIRDY) == RESET);

  //Systemtak von internen Oscillator antreiben
  RCC_SYSCLKConfig(RCC_SYSCLKSource_HSI);
  
// Externen Oscillarot starten (8MHZ)
  RCC_HSEConfig(RCC_HSE_ON);

  // warten bis fertig
  while(RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET);

  // 3.PLL initialisieren mit 8 MHz*9=72 MHz
  RCC_PLLConfig(RCC_PLLSource_HSE_Div1,RCC_PLLMul_9);
  
//PLL aktivieren
  RCC_PLLCmd(ENABLE);

  // warten bis fertig
  while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET);

//KEINE AHNUG WAS DIESE ZEILE MACHT  
// Flash 1 wait state
  *(vu32 *)0x40022000 = 0x12;

 //Systemtak von PLL antreiben ->System läuft mit 72 MHz
  RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);

//warten bis Systemtakt-Herkunft übernommen wurde
  while(RCC_GetSYSCLKSource() != 0x08)
  {
  }

  // Takte für die Peripherie setzen

//AHB Takt (HCLR) 72 MHz 
  RCC_HCLKConfig(RCC_SYSCLK_Div1);

//USb Takt 72/1.5=48 MHz
  RCC_USBCLKConfig(RCC_USBCLKSource_PLLCLK_1Div5);

// APB2 takt 72 MHz (Dieser Takt treibt u. A. den USART1 an)
  RCC_PCLK2Config(RCC_HCLK_Div1);

//APB1 Takt 72/2=36 MHz (u. A. USART2,USART3)
  RCC_PCLK1Config(RCC_HCLK_Div2);

//ADC Takt (APB2)/8=9MHz
  RCC_ADCCLKConfig(RCC_PCLK2_Div8);
}

Also demnach sollte der uC keine Annahmen mehr beim Ausrechnen der 
Baud-Rate machen..... es kommen aber immer noch keine richtigen Zeichen 
an. Habe vorläufig kein Hyperterminal zuhause, aber sowohl Tera-Term als 
Advanced Serial Port Monitor zeigen keine gescheiten Zeichen an. Auch 
ein Atmel328(Arduino) dessen RX auf TX umgeleitet wird kann die Daten 
nicht interpretieren die aus dem Pin des STM32 rauskommen. Wo steckt 
mein Denkfehler??

Danke


Gruß
Max

[(prx) A. K. (prx)]

Welche Möglichkeiten des Debuggings stehen dir zu Verfügung? Mit Oszi 
kannst du feststellen, was tatsächlich an Baudrate aus der UART 
rauskommt. Mit JTAG kannst du dir ansehen, was der Lib-Code als 
Taktfrequenz annimmt - da gibt's ein paar Variablen zu, eine davon 
verwendet die Lib für die Baudratendefinition. Vielleicht stimmt das 
nicht überein - z.B. mit 8MHz Quarz gerechnet und 12MHz sind drin.

Alternativ kannst du mal den Quarz ignorieren und ohne PLL auf Basis des 
HSI arbeiten. Für den ersten Test ist der genau genug. Nur muss auch 
dann die Angabe der Taktfrequenz irgendwo im Programm oder Projekt einen 
gewissen Bezug zur Realität haben.

[DrMaex (Gast)]

Hab jetzt versucht nur dem dem HSI Clock zu arbeiten.
In der „stm32f10x_rcc.h“ steht

/* Typical Value of the HSI in Hz */
#define HSI_Value                 ((u32)8000000)

Meine Konfiguration der Takte schaut folgendermaßen aus:

void Clk_Init (void)
{
  // 1. Clocking the controller from internal HSI RC (8 MHz)
  RCC_HSICmd(ENABLE);
  // wait until the HSI is ready
  while(RCC_GetFlagStatus(RCC_FLAG_HSIRDY) == RESET);
  RCC_SYSCLKConfig(RCC_SYSCLKSource_HSI);
  while(RCC_GetSYSCLKSource() != 0x00)
    {
    }
  // 2. Enable ext. high frequency OSC
 // RCC_HSEConfig(RCC_HSE_ON);
  // wait until the HSE is ready
  //while(RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET);
  // 3. Init PLL
  RCC_PLLConfig(RCC_PLLSource_HSI_Div2,RCC_PLLMul_9); // 36 MHz
  RCC_PLLCmd(ENABLE);
  // wait until the PLL is ready
  while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET);
  // 4. Set system clock divders
  RCC_HCLKConfig(RCC_SYSCLK_Div1);
  RCC_USBCLKConfig(RCC_USBCLKSource_PLLCLK_1Div5);
  RCC_ADCCLKConfig(RCC_PCLK2_Div8);
  RCC_PCLK2Config(RCC_HCLK_Div1);
  RCC_PCLK1Config(RCC_HCLK_Div2);
  // Flash 1 wait state
  //*(vu32 *)0x40022000 = 0x12;
  // 5. Clock system from PLL
  //RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);
  //while(RCC_GetSYSCLKSource() != 0x08)
  //{
  //}
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE);
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC | RCC_APB2Periph_GPIOA,    ENABLE);
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);}

In der “stm32f10x_usart.c” wird die Baudrate folgendermaßen Verarbeitet

/*---------------------------- USART BRR Configuration -----------------------*/
  tmpreg = 0x00;

  /* Configure the USART Baud Rate -------------------------------------------*/
  RCC_GetClocksFreq(&RCC_ClocksStatus);
  if ((*(u32*)&USARTx) == USART1_BASE)
  {
    apbclock = RCC_ClocksStatus.PCLK2_Frequency;
  }
  else
  {
    apbclock = RCC_ClocksStatus.PCLK1_Frequency;
  }

  /* Determine the integer part */
  integerdivider = ((0x19 * apbclock) / (0x04 * (USART_InitStruct->USART_BaudRate)));
  tmpreg = (integerdivider / 0x64) << 0x04;

  /* Determine the fractional part */
  fractionaldivider = integerdivider - (0x64 * (tmpreg >> 0x04));
  tmpreg |= ((((fractionaldivider * 0x10) + 0x32) / 0x64)) & ((u8)0x0F);

  /* Write to USART BRR */
  USARTx->BRR = (u16)tmpreg;
}

Mit der Berechnung selbst kann ich leider nichts anfangen.
Wenn ich probiere das Programm zu debuggen sehe ich folgendes 
(Screenshot im Anhang siehe oben)
Ich vermute das ist genau die Variable die als Baudrate ins Register 
geschrieben wird…

Ich bin langsam am verzweifeln…

Mal eine andere Frage bezüglich des Flashens und der Hardware 
Konfiguration vielleicht liegt da der Hund begraben:
Also was mich als erstes etwas stutzig macht ist anscheinend braucht ja 
die RS232 +-12 Volt als Pegel, mein TX Pin liegt aber bei 3.26 
Volt.(Direkt auf Com Verbunden)
Beim Kompilieren geht soweit alles glatt

**** Build of configuration Debug for project stm_h103 ****
make all 
.compiling
arm-none-eabi-gcc -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb  main.c
.compil
arm-none-eabi-gcc -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb  stm32f10x_rcc.c 
.compili
arm-none-eabi-gcc -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb  stm32f10x_gpio.c 
..linking
arm-none-eabi-ld -v -Tstm_h103_blink_rom.cmd -nostartfiles -o main.out  main.o stm32f10x_rcc.o stm32f10x_gpio.o 
GNU ld (Sourcery G++ Lite 2008q1-126) 2.18.50.20080215
...copying
arm-none-eabi-objcopy -Obinary main.out main.bin
arm-none-eabi-objdump -S main.out > main.list

Beim Flashen iritiren mich die Meldungen ala “not enough working area 
available“

Warning: /cygdrive/C/gccfd/projects/stm_h103/Release: No such file or directory.
Warning: /cygdrive/C/gccfd/projects/stm_h103: No such file or directory.
mi_cmd_break_watch: Missing <expression>
No registers.
target remote localhost:3333
main () at main.c:45
45  {
symbol-file main.out
monitor soft_reset_halt
requesting target halt and executing a soft reset
monitor flash erase_sector 0 0 31
erased sectors 0 through 31 on flash bank 0 in 1.031303s
monitor flash write_image main.bin 0x08000000 bin
not enough working area available(requested 8192, free 8144)
wrote 7120 byte from file main.bin in 0.875045s (7.946020 kb/s)
thbreak main
Hardware assisted breakpoint 1 at 0x8e8: file main.c, line 49.
cont
main () at main.c:49
49      Clk_Init();
mi_cmd_var_create: unable to create variable object
mi_cmd_var_create: unable to create variable object
mi_cmd_var_create: unable to create variable object
mi_cmd_var_create: unable to create variable object
mi_cmd_disassemble: Invalid filename.

Ist das normal?

Tut mir leid wegen des langen Beitrags…


Danke

Gruß
Max

[(prx) A. K. (prx)]

Man kann sich auch von hinten durch die Brust ins Auge stechen. Wenn du 
dir die komplette Taktprogrammierung einsparst läuft IMHO alles auf 
HSI=8MHz. Auf was denn sonst ;-).

Den Baudratenteiler programmiert man trivialerweise so:
 UARTx->BRR = APBx-Takt / Baudrate;
Dass man sich das Leben auch schwerer machen kann beweist die Lib.

[DrMaex (Gast)]

Also scheint es alles zwar kompliziert programmiert zu sein sollte aber 
dennoch funktionieren....was heute einem Kumpel aufgefallen ist, ist, 
dass der uC selbst sehr heisst wird, nicht lauwarm,  heiss! Man kann den 
Finger nicht dran lassen, ich mein ok das Ding ist ziemlich schnell und 
die LED blinkt fleissig weiter aber hmmm.... leider habe ich keinen 
Thermometer zur Hand deswegen die Frage, ist das normal?

p.s. meinst du dass man bereits nach

RCC_HSICmd(ENABLE);
  // wait until the HSI is ready
  while(RCC_GetFlagStatus(RCC_FLAG_HSIRDY) == RESET);
  RCC_SYSCLKConfig(RCC_SYSCLKSource_HSI);
  while(RCC_GetSYSCLKSource() != 0x00)
    {
    }

aufhören könnte und die Peripherie Teiler und Takte bekommen 
irgendwelche Default-Werte verpasst?


Danke

Gruß
Max

[(prx) A. K. (prx)]

DrMaex schrieb:

> p.s. meinst du dass man bereits nach
> aufhören könnte und die Peripherie Teiler und Takte bekommen
> irgendwelche Default-Werte verpasst?

Nicht nur dies.

Hast du schon einmal einen Prozessor gesehen, der gänzlich ohne Takt 
seine Befehle ausführt? (für Experten: ja, ich weiss das es das gibt, 
aber der hier gehört nicht dazu).

Wenn du dir das nicht vorstellen kannst, dann überleg mal, oder noch 
besser schau nach, mit welchem Takt der STM32 den obigen Code nach dem 
Reset auszuführen beginnt.

[(prx) A. K. (prx)]

DrMaex schrieb:

> dass der uC selbst sehr heisst wird, nicht lauwarm,  heiss! Man kann den
> Finger nicht dran lassen,

Ganz ganz schlecht. Sollte nicht spürbar warm werden.

[DrMaex (Gast)]

Ne, klar ohne Takt wäre es schwierig aber nachdem ich gesehen hatte was 
man da einstellen kann habe ich dem ARM einfach alles zugetraut :) Bzw. 
halt zumindest, dass die Peripherie nicht ohne explizite Angaben zum 
Takt funktioniert.
Beschäftige mich erst seit kurzem mit uC und habe die ganzen Strukturen 
noch nicht ganz verinnerlicht und lerne die Sachen eher bei Bedarf, nur 
dann kann ich erst den nötigen Ehrgeiz aufbringen. Einfach so ohne 
Anwendung schalte ich viel zu schnell auf Durchzug....
Da sich jetzt der Verdacht, dass ein heisser Prozessor nicht gut ist, 
bestätigt werde ich wahrscheinlich die Arbeiten an dem STM32-H103 Board 
einstellen und mich nach Alternativen umschauen...
Vielen Dank für die Hilfe!


Gruß
Max