Guten Tag zusammen
Bei der implementierung einer Uart Schnittstelle, die ich als feedback
zwischen PC und einem Stm32f070CBT6 verwende (IDE Keil /ARM
Compiler/MDK-Proffessional),habe ich folgendes Problem:
- Wenn ich debugge bekomme ich alle relevanten Informationen, auch nach
einem SW reset
- Wenn ich den chip flash bekomme ich nur wirre Zeichen, zumindest bei
allen Ausgaben, die vor dem Main ausgeführt werden (nach einem HW
reset)..
Ich gehe von einem Timming Problem aus, im debuge mode werden die
Ausgänge auf digital gesetzt daher könnte es sein, dass nach dem
download die Pins nicht richtig konfiguriert sind. Die fehlerhaften
Informationen erhalte ich nach dem HW Reset.
Was ändert sich noch beim debugen im gegensatz zum eine download auf dem
Chip?
Über einen heissen tip würde ich mich sehr freuen :)
Zu wenig Informationen...
Du debuggst im RAM oder Flash?
Was meinst du ganz genau mit SW Reset? Es gibt davon verschiedene und
beim debuggen wird ganz gerne kein echter Reset ausgelöst.
Michael schrieb:> zumindest bei> allen Ausgaben, die vor dem Main ausgeführt werden
Welchen Takt nimmst du und wann initialisierst du ihn?
Takt und Uart müssen natürlich vor der ersten Ausgabe initialisiert
werden.
Michael schrieb:> - Wenn ich debugge bekomme ich alle relevanten Informationen, auch nach> einem SW resetMichael schrieb:> Was meinst du ganz genau mit SW Reset? --> Der Watchdog self-test> erfolgt wie in Bild 3/4 dargestellt (Auszug Applikation note 3307)
Es ging mir um den SW reset beim Debuggen. Ich vermute, dass es kein
echter Reset ist und damit die Einstellungen der UART erhalten bleiben.
Michael schrieb:> void USART_Configuration(void)
Offen ist, ob du die UART Initialisierung vor deinen ganzen Tests
aufrufst.
Da es hier um Selbsttests geht, ich g´kenne es so, dass diese vor der
Initialisierung der C-Umgebung durchgeführt werden. Da wäre ich mir
unsicher, ob printf() schon funktioniert.
Steffen R. schrieb:> Offen ist, ob du die UART Initialisierung vor deinen ganzen Tests> aufrufst.
Die Uart Konfiguration erfolgt vor den startup selbsttests,
anschschliessend nach den startup und vor den run-time tests nach dem
Einsprung ins main erneut
Steffen R. schrieb:> Da es hier um Selbsttests geht, ich g´kenne es so, dass diese vor der> Initialisierung der C-Umgebung durchgeführt werden. Da wäre ich mir> unsicher, ob printf() schon funktioniert.
Mein Problem ist eben, dass ich die printf Ausgaben nur beim debuggen
mit Hterm anzeigen kann, aber beim debuggen failed z.B. der flash
integritäts test. Wenn ich den code auf den chip flash, funktioniert das
Programm, aber ich weiss nicht genau wie es sich verhält, weil ich kein
Feedback über den Erfolg oder fail der Tests bekomme.
Das mit dem Reset schaue ich mir jetzt nochmal genauer an.
Michael schrieb:> Mein Problem ist eben, dass ich die printf Ausgaben nur beim debuggen> mit Hterm anzeigen kann, aber beim debuggen failed z.B. der flash> integritäts test. Wenn ich den code auf den chip flash, funktioniert das> Programm, aber ich weiss nicht genau wie es sich verhält, weil ich kein> Feedback über den Erfolg oder fail der Tests bekomme.
Verstehe ich nicht.
Ich debugge auf dem Chip...
Für mich ist es nur ein Unterschied, ob ich den Jtag gesteckt habe oder
nicht.
Oder ob ich mit Debug oder Release übersetze.
Wenn du das Projekt nicht selbst aufgesetzt hast, kann es sein, dass es
nur im Release nichts anzeigt, z.B. weil STL_VERBOSE_POR nicht gesetzt
ist.
Nimmst du eine echte UART Schnittstelle am PC oder eine virtuelle per
USB. Bei letzterem stören vielleicht die vielen Resets.
Vielleicht nutzt Du im Release auch eine andere printf()
Implementierung.
Ich persönlich würde erstmal die Selbsttest übergehen und schauen, dass
das Programm ohne Debugger überhaupt eine Ausgabe macht.
Und im STL_InitClock_Xcross_Measurement() wird der Clock geändert. Falls
hier was fehlschlägt, wird dann der Clock wieder zurückgeändert, bevor
eine Ausgabe erfolgt?
Wie wäre es statt printf() eine Funktion anzuspringen, bei der zuerst
Clock und UART wieder richtig eingestellt werden und dann die Ausgabe
erfolgt.
Naja, die Ausgaben sind auch nur im Fehlerfall. Vielleicht läuft ja
alles durch?
Steffen R. schrieb:> Wenn du das Projekt nicht selbst aufgesetzt hast, kann es sein, dass es> nur im Release nichts anzeigt, z.B. weil STL_VERBOSE_POR nicht gesetzt> ist.
Das Beispiel ist von STM und ich habe es für meine Zwecke angepasst,
STL_VERBOSE_POR ist gesetzt und wird ausgeführt
Steffen R. schrieb:> Nimmst du eine echte UART Schnittstelle am PC oder eine virtuelle per> USB. Bei letzterem stören vielleicht die vielen Resets.
USB hab aber auch mit dem oszi nichts vernünftiges bekommen
> Vielleicht nutzt Du im Release auch eine andere printf()> Implementierung.> Ich persönlich würde erstmal die Selbsttest übergehen und schauen, dass> das Programm ohne Debugger überhaupt eine Ausgabe macht.
Die Ausgabe erfolgt, aber die Zeichen werden nicht detektiert.. unten
habe ich die Ausgabe mit debugger und nach dem flashen gepostet
> Und im STL_InitClock_Xcross_Measurement() wird der Clock geändert. Falls> hier was fehlschlägt, wird dann der Clock wieder zurückgeändert, bevor> eine Ausgabe erfolgt?> Wie wäre es statt printf() eine Funktion anzuspringen, bei der zuerst> Clock und UART wieder richtig eingestellt werden und dann die Ausgabe> erfolgt.
Eigentlich ja, aber ich schreibe jetzt mal wie du gesagt hast eine
Funktion welche clock &Uart immer gleich initialisiert
> Naja, die Ausgaben sind auch nur im Fehlerfall. Vielleicht läuft ja> alles durch?
Erfolgreiche Tests werden ebenfalls ausgegeben, sorry wenn ich mich
undeutlich ausgedrückt habe, die Zeichen kommen immer beim debuggen und
flashen nur sind Sie beim flashen falsch angezeigt wie in Bild 1,
deshalb dachte ich an ein timming Problem oder das die Uart die falsche
baudrate berechnet
beim debuggen:
<\n>
<\n>
<\r> ******* Self Test Library Init (Zeile 153 - STL_StartUp)
*******<\n>
<\r> Start-up CPU Test OK<\n>
<\r>Pin reset <\r><\n>
SW reset <\r><\n>
... Power-on or software reset, testing IWDG ... <\r><\n>
<\n>
<\n>
<\r> ******* Self Test Library Init (Zeile 153 - STL_StartUp)
*******<\n>
<\r> Start-up CPU Test OK<\n>
<\r>Pin reset <\r><\n>
IWDG reset <\r><\n>
... IWDG reset from test or application, testing WWDG<\r><\n>
<\n>
<\n>
<\r> ******* Self Test Library Init (Zeile 153 - STL_StartUp)
*******<\n>
<\r> Start-up CPU Test OK<\n>
<\r>Pin reset <\r><\n>
IWDG reset <\r><\n>
WWDG reset <\r><\n>
... WWDG reset, WDG test completed ... <\r><\n>
FLASH 32-bit CRC Error at Start-up<\n>
<\r> >>>>>>>>>> POR FailSafe Mode <<<<<<<<<<<\n>
und so siehts nach dem flash download aus:
?|}????x?<30>??~^?????O?|=???}?<31>??z?<<30>?????<31>/?}???z?>?x~????x??
??=_??~?<31>????????????z???????>^<15>?~??<31>?}<31><15>??^??}?^?????
?z~??^?{<??{_???^<31>??}????|}????x?<30>??~^?????O?|=???}?<31>??z?<<30
>?????<31>/?}???z?>?x~????x????=_??~?<31>?????o?|??<31>?????????^<31 >????????}?__/?z????????{????z?>?y?<???}<???_??_/???|}????x?<30>??~^?
????O?|=???}???|=??????x=?????z?>?x~????x????=_??~?<31>?<31><15>????
?o??<31>?????????^<31>????????__<31>????????}<31>/?y>^??~?<30>/?><30>??
{????y???x??x}??<?7?(:<25>?}=<28>?<25>;{<_?_\~<29><25><????|<27>{ Clock
frequency OK <\n>
<\r> Control Flow Checkpoint 2 OK <\n>
<\r><\n>
<\r> STM32F0xx Cortex-M0 <\n>
<\r> IEC60335 test @ARMc <\n>
<\r> ... main routine starts ...<\r><\n>
Ich versuchs jetzt mal mit deinem Vorschlag, vielen Dank für die Mühe,
echt klasse
Michael schrieb:> und so siehts nach dem flash download aus:>> ?|}????x?<30>??~^?????O?|=???}?<31>??z?<<30>?????<31>/?}???z?>?x~????x??> ??=_??~?<31>????????????z???????>^<15>?~??<31>?}<31><15>??^??}?^?????> ?z~??^?{<??{_???^<31>??}????|}????x?<30>??~^?????O?|=???}?<31>??z?<<30>>?????<31>/?}???z?>?x~????x????=_??~?<31>?????o?|??<31>?????????^<3 1>>????????}?__/?z????????{????z?>?y?<???}<???_??_/???|}????x?<30>??~^ ?> ????O?|=???}???|=??????x=?????z?>?x~????x????=_??~?<31>?<31><15>????> ?o??<31>?????????^<31>????????__<31>????????}<31>/?y>^??~?<30>/?><30>??> {????y???x??x}??<?7?(:<25>?}=<28>?<25>;{<_?_\~<29><25><????|<27>{ Clock> frequency OK <\n>> <\r> Control Flow Checkpoint 2 OK <\n>> <\r><\n>> <\r> STM32F0xx Cortex-M0 <\n>> <\r> IEC60335 test @ARMc <\n>> <\r> ... main routine starts ...<\r><\n>>> Ich versuchs jetzt mal mit deinem Vorschlag, vielen Dank für die Mühe,> echt klasse
Ich tippe mal auf falschen Takt (LSI statt HSI?) oder darauf, dass das
Startbit nicht korrekt erkannte wird (von deinem RS232 nach USB
Umsetzer).
Wenn möglich, mal auf 2 Stoppbits gehen? Vielleicht kann er dann auch
besser das Startbit erkennen.
Michael schrieb:> USB hab aber auch mit dem oszi nichts vernünftiges bekommen
Da etwas herauskommt, verstehe ich diese Aussage nicht.
Heißt es du siehst dort auch die Wirren Zeichen oder "unsinnige"
Pegelwechsel?
