STM32F4 printf bleibt hängen

[Michael D. (Gast)]

Hallo zusammen!

Ich bin gerade dabei mich mit dem STM32 einzuarbeiten und verwende 
hierfür:

STM32F4 Discovery
Eclipse
Codesourcery G++ Lite
OpenOCD 0.5.0 mit dem Luminary ICD Board
newlib_stubs von: 
https://sites.google.com/site/stm32discovery/open-source-development-with-the-stm32-discovery/getting-newlib-to-work-with-stm32-and-code-sourcery-lite-eabi

Das erste Programm läuft bereits, allerdings mit folgendem seltsamen 
Phänomen:

printf bleibt hängen, wenn das Programm ohne Debugger ausgeführt wird 
(flashen über ST-Link + Reset).

Wenn ich das Programm vom ICD-Debugger ausflashe und starte dann klappt 
alles und es wird über die UART gesendet. Nachdem ich dann aber das 
Board resette bleibt es wieder hängen.

Da ich über den Debugger dann aber trotzdem den Programcounter auslesen 
kann, konnte ich folgende Stelle ausmachen an welche das Programm hängt:

newlib_stubs.c in funktion "int _write(int file, char *ptr, int len)":

while((USART1->SR & USART_FLAG_TC) == (uint16_t)RESET) {}

Hat jemand eine Idee was hier schief läuft???
(Programm funktioniert über Debugger, aber bleibt ohne Debugger in 
printf hängen)

gdb-script für OpenOCD:

set complaints 1
set output-radix 16
set input-radix 16
set prompt (arm-gdb)
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
set remote memory-read-packet-size 1024
set remote memory-read-packet-size fixed
set remote hardware-watchpoint-limit 6
set remote hardware-breakpoint-limit 6
monitor reset
monitor sleep 200
monitor poll
monitor soft_reset_halt
monitor flash write_image 
"${workspace_loc:/Template/Debug/Template.bin}" 0x08000000 bin

Vielen Dank im Voraus,
Mike

[Matthias K. (matthiask)]

boot0 und boot1 richtig gesetzt?

[tip (Gast)]

stack vergrößern?

[RP6Conrad (Gast)]

Das "printf()" ist keine Standard function in die Standard C Library. 
Bei den IAR compiler wird das ueber eine Sonder-lib in compiler gemacht. 
Da wird dan einen sogenannte "Library configurator" eingestellt.
In program steht dan bei mir :

#ifdef __GNUC__
  /* With GCC/RAISONANCE, small printf (option LD Linker->Libraries->Small printf
     set to 'Yes') calls __io_putchar() */
  #define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
#else
  //#define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
  #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE*f)
#endif /* __GNUC__ */
PUTCHAR_PROTOTYPE   //in main achteraan
{
  /* Place your implementation of fputc here */
  /* e.g. write a character to the USART */
  USART_SendData(USART1, (uint8_t) ch);

  /* Loop until the end of transmission */
  while (USART_GetFlagStatus(USART1, USART_FLAG_TC) == RESET)
  {}

  return ch;
}

Suche mal aus wie diese printf() bei ihre compiler eingebunden ist.

[Michael D. (Gast)]

Hallo

Vielen Dank für Eure Antworten!

tip schrieb:
> stack vergrößern?

habe ich gemacht, bringt aber leider nichts

Matthias K. schrieb:
> boot0 und boot1 richtig gesetzt?

Das Programm an sich läuft ja, es bleibt nur an der besagten Stelle 
hängen, wenn es nicht über den Debugger sondern über einen Reset 
gestartet wird.

RP6Conrad schrieb:
> IAR compiler wird das ueber eine Sonder-lib in compiler gemacht

Ich verwende den Codesourcery Compiler mit newlib.
printf funktioniert auch wenn das Programm über den Debugger gestartet 
wird.

[User (Gast)]

Vielleicht ist deine Initialisierung des USART kaputt, aber der Debugger 
überschreibt das?

[Michael D. (Gast)]

Hallo User...

Nicht kaputt, aber es wird nicht aufgerufen wie ich gerade gesehen 
habe..

main(void) {
  GPIOInit();
  USARTInit();
  while(1) {
    printf("abc");
    delay();
  }
}

GPIOInit wird nicht verlassen - lasse zu debugzwecken davor und danach 
LEDs setzen - die danach werden nicht gesetzt.

Möglich dass mir innerhalb von GPIOInit etwas einen ASSERT wirft.

Trotzdem wundert es mich warum das Programm in while(1) springt und das 
ganze mit dem Debugger auch funktioniert.. Das Binary welches 
aufgespielt wird ist ja dasselbe..

Werde morgen weitermachen und kurz das Ergebnis Posten.

Viele Dank!!

Mike

[Noname (Gast)]

Vom IAR kenne ich noch andere Macken. Vielleicht hat die der 
Codesourcery auch. Versuche mal die Optimierungen abzuschalten. Am 
besten auch mal ein Clean machen.