Probleme beim Debuggen mit SW4STM32 und und F7Disco

[J. T. (chaoskind)]

MoinMoin,

ich spiele seit einiger Zeit wieder mit meinem STM32F746g-Discoveryboard 
rum.

Von einem Tag auf den anderen zeigt meine Entwicklungsumgebung beim 
Debuggen nicht mehr die Werte der Variablen an. Ich stecke in einer 
Schleife, der Zählwert soll bei jedem Durchlauf um einen erhöht werden. 
Jedoch wird die Variable immer mit 0 angezeigt, obwohl die Schleife auch 
nach der richtigen Anzahl von Durchläufen beendet wird. Optimierungen 
sind komplett ausgeschaltet.

Ein weiteres Problem das aufgetaucht ist, ist dass der µc scheinbar sein 
Programm vergisst. Aber nur scheinbar. Ich starte eine Debugsession, der 
Controller wird zum Beginn selbiger geflasht und die Session läuft, bis 
auf die nicht angezeigten Werte der Variablen. Wenn ich nun den 
USB-Stecker abziehe, und per Powerbank über den FS_USB_Anschluss 
versorgen will, tut sich nichts (umgejumpert habe ich).

Wenn ich dann aber den Flash AUSLESE! mit dem ST_Link, wird alles 
richtig angezeigt, und dass für mich wirrste ist, dass nach dem auslesen 
alles läuft. Erst wenn ich ihm den Strom wegnehme und wieder anstecke, 
ist es wieder so. Ich muss den Flash erst auslesen, bevor der Controller 
losrennt....

Hat da irgendwer nen hilfreichen Hinweis zu?

MfG Chaos

[holger (Gast)]

Benutzt du Semihosting? Dann mach das mal aus.

[Stefan F. (Gast)]

Wenn beim Debuggen der Wert einer Variable nicht angezeigt wird, kann es 
sein, dass der Compiler sie weg optimiert hat oder dass er sie in einem 
CPU Register vorhält anstatt im RAM.

Du musst die Compiler Option -O0 oder -Og benutzen, damit der Compiler 
code generiert, mit dem der Debugger klar kommt. -O0 deaktiviert alle 
Optimierungen. -Og würde unbenutzte Variablen entfernen, soweit ich 
weiß.

Wenn dein Programm ohne Programmieradapter nicht startet könnte es an 
instabiler oder zu langsam ansteigender Stromversorgung liegen. Wnn das 
Programm nach einem Druck auf den Reset Knopf anläuft, dann war es das.

[J. T. (chaoskind)]

holger schrieb:
> Benutzt du Semihosting? Dann mach das mal aus.

Öh keine Ahnung, ehrlich gesagt, davon höre ich zum ersten mal. Kannst 
du mir auf die Schnelle sagen, wo ich das ausschalte, falls es an sein 
sollte?

Stefanus F. schrieb:
> Wenn beim Debuggen der Wert einer Variable nicht angezeigt wird, kann es
> sein, dass der Compiler sie weg optimiert hat oder dass er sie in einem
> CPU Register vorhält anstatt im RAM.

J. T. schrieb:
> Optimierungen
> sind komplett ausgeschaltet.

Stefanus F. schrieb:
> Wenn dein Programm ohne Programmieradapter nicht startet könnte es an
> instabiler oder zu langsam ansteigender Stromversorgung liegen. Wnn das
> Programm nach einem Druck auf den Reset Knopf anläuft, dann war es das.

Nein tut es nicht. Auch nach einem Druck auf Reset nicht. Ich muss erst 
den Flash auslesen, wenn ich danach dann Reset drücke, dann läuft es an

[Stefan F. (Gast)]

Tja, die Glaskugel weiss nicth mehr weiter, wir brauchen Fakten. 
Schaltplan, Foto, Quelltext, welche Software nutzt du?

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Tja, die Glaskugel weiss nicth mehr weiter, wir brauchen Fakten.
> Schaltplan, Foto, Quelltext, welche Software nutzt du?

Liest du eigentlich die Postings? Bei deinem ersten Versuch übersahst 
du, dass ich die Optimierungen ausgeschaltet habe, und schlägst vor die 
Optimierungen auszuschalten.

Nun fragst du nach der Software, steht auch im Eröffnungspost, SW4STM32.
Quelltext bringt auch nix, weil es Quelltextunabhängig ist. Die 
Variablen werden nicht gezeigt. Egal mit welchem ich es versuche. Und 
Schaltplan und Foto werden auch nichts bringen. Ich benutze ein 
unbearbeites STM32F746g-Disco. Steht übrigens auch im Eröffnungspost.

[Stefan F. (Gast)]

Ich habe Dir die Debug Optionen konkret genannt, weil ich vermutete, 
dass du sie aus versehen oder aus Unkenntnis doch nicht ausgeschaltet 
hast. Mein Vermutung der Unkenntnis ist sicher nicht so weit her geholt, 
nach deiner Info, dass du mit dem Begriff Semihosting nichts anfangen 
kannst.

Wenn du alles besser weißt und keine Fehler machst, brauchst du keine 
Hilfe. Viel Glück bei der Suche des Hardwarefehlers.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Ich habe Dir die Debug Optionen konkret genannt, weil ich vermutete,
> dass du sie aus versehen oder aus Unkenntnis doch nicht ausgeschaltet
> hast.

Da hast du falsch vermutet.

Stefanus F. schrieb:
> Wenn du alles besser weißt und keine Fehler machst, brauchst du keine
> Hilfe. Viel Glück bei der Suche des Hardwarefehlers.

Und schon wieder eine falsche Vermutung. Denn wäre es so, wie du 
vermutest, hätte ich tatsächlich nicht gefragt.

Wie wäre es statt zu vermuten, einfach mal zielführend nachzufragen? 
Aber danke, auf die Hilfe von Leuten, die nur Vermutungen anstellen, und 
damit dann auch noch falsch liegen, kann ich gerne verzichten.

[Stefan F. (Gast)]

Erwartest du ernsthaft eine schnelle treffende Erklärung bei so wenig 
Informationen?

Eine seltsame Arbeitsweise das ist.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> ein Vermutung der Unkenntnis ist sicher nicht so weit her geholt,
> nach deiner Info, dass du mit dem Begriff Semihosting nichts anfangen
> kannst.

BTW was bitte hat Kenntniss über die Einstellung der Optimierungen mit 
Semihosting zu tun?

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Erwartest du ernsthaft eine schnelle treffende Erklärung bei so wenig
> Informationen?

Wie kommst du nun schon wieder auf dieses dünne Brett? Vermutung, 
vermute ich mal D:

Nein ich erwarte sowas wie von Holger. Eine Nennung von Möglichkeiten, 
die nicht schon explizit im Eröffnungspost ausgeschlossen wurden, und 
nicht irgendwelche Vorschläge, die schon im Eröffnungspost 
ausgeschlossen sind.
Auch wenn ich damit evtl nichts anfangen kann, kann es ja ein 
Ansatzpunkt sein, an dem man nachlesen kann.

Wie gesagt, die Optimierungseinstellungen und die verwendete Software 
wurden im Eröffnungspost genanngt, und dennoch musst du danach 
nachfragen. DAS stelle ich mir jedenfalls nicht unter Hilfreich vor.


Und mehr Infos hab ich leider selbst nicht. SW4STM32, Optimierungen o0, 
Quelltextunabhängig tritt das genannte Verhalten auf.

Mehr weiß ich auch nicht.

[Stefan F. (Gast)]

Bei deiner Einstellung, notwendige Infos zurückzuhalten, kann ich Dir 
nicht weiter helfen. Ich denke, das spielt gar keine Rolle, du willst 
von mir wohl auch keine Hilfe. Tut mir Leid, dass ich deine Zeit 
verschwendet habe.

[J. T. (chaoskind)]

Was halte ich denn für Infos zurück? Ich habe schlicht einfach nicht 
mehr Infos.

Was versprichst du dir bitte von einem Foto? Wovon überhaupt? Vom 
handelsüblichen Discoboard mit nem schwarzen Display? Vermutlich nicht 
allzu hilfreich. Von der IDE, die mir alle Variablen auf 0 zeigt? 
Vermutlich genausowenig hilfreich. Solche Bilder würden höchstens für 
Redundanz der Information sorgen, jedoch keine neue zutage fördern. Auch 
der Quelltext wird nicht viel zutage fördern. Ein nahezu unverändertes 
von Cube erstelltes File, lediglich um die BSP_LCD inits erweitert und 
die Zählschleife.

Und ich habe auch prinzipiell nichts gegen Hilfe von dir, nur trägtst du 
bisher irgendwie nichts hilfreiches bei. Das ist mir irgendwie schon in 
diversen anderen Beiträgen aufgefallen.

P.S.

Achja ich nutze auch noch cube zum erstellen eines Projektes. Diese Info 
habe ich tatsächlich bösartigst zurückgehalten.

[J. T. (chaoskind)]

Kann evtl jdm noch etwas zielführendes beitragen?

@Stefan
Entschuldige bitte, ich bin dich eventuell etwas zu sehr angegangen. Ich 
hab nur irgendwie das Gefühl dieses Forum baut immer ab. Ich versuche im 
allgemeinen mein Problem so genau ich kann zu formulieren. Und daher 
nervt diese Standardfragerei nach Bild Foto und sowieso mich nur noch 
ungemein, weil es einfach nichts beitragen würde. Und wenn dann noch 
nach Sachen gefragt wird, die klar im Eingangspost stehen....
Ich habe neulich auch ein Problem sehr ausführlich beschrieben, alle 
benötigten Files angebunden, und dann wird einem gesagt: "das ist zu 
lang, dass les ich mir nicht durch". Da ist es irgendwo schwer, den 
Mittelweg zu finden.

[Harry L. (mysth)]

J. T. schrieb:
> P.S.
>
> Achja ich nutze auch noch cube zum erstellen eines Projektes. Diese Info
> habe ich tatsächlich bösartigst zurückgehalten.

Hast du auch das Serial Wire Interface eingeschaltet? (siehe Anhang)

[J. T. (chaoskind)]

Harry L. schrieb:
> Hast du auch das Serial Wire Interface eingeschaltet?

Danke für den Hinweis, aber das ist aktiviert. Ich glaube, sonst könnt 
ich überhaupt keine Debugsession starten. Zumindest schwang das mal 
zwischen den Zeilen mit, auf ner HandsOnSession von ST.

[Stefan F. (Gast)]

Die Info, dass du als Software auch CubeMX verwendest, ist schon ein 
erheblicher Punkt. Denn darauf folgt die Frage, welche Debugging 
Optionen du dort eingeschaltet hast.

Des Weiteren kann durchaus ein gravierender Fehler in der 
Initialisierungsroutine sein, die du selbst geschrieben hast oder Cube 
MX erzeugt hat. Meine beiden ersten Programme (LED Blinker und 
Hello-World) funktionierten wegen zwei Bugs in Cube HAL nicht.

Erst danach begann ich, mich mit dem Referenzhandbuch zu beschäftigen. 
Mit Hilfe dieses Forums wurden die Fehler im Cube Code identifiziert und 
behoben. Mein Fazit daraus ist, dass ich Cube MX und HAL nicht mehr 
verwende. Denn inzwischen verstehe ich das Referenzhandbuch. Und wenn 
ich mal eine einzelne Passage nicht verstehe, bekomme ich hier Hilfe.

Vorausgesetzt, ich zeige den Hardwareaufbau, den Quelltext und die 
verwendete Software .

Der Hardwareaufbau ist durchaus auch von Interesse, selbst wenn du ein 
fix und fertiges Board verwendest von dessen Korrektheit wir alle 
ausgehen. Ich habe hier z.B. schon öfters sehr dünne lange Kabel 
gesehen, an denen zu viel Spannung abfiel. Ich habe ungeeignete 
Netzteile gesehen (der heftigste Fall war ein Eisenbahntrafo). Und ich 
habe falsch angeschlossene Messgeräte gesehen. Zu lange Leitungen am 
Programmieradapter sind ein weitere Klassiker. Hier wurden schon Fotos 
mit weniger als 5 Bauteilen gezeigt, die Fehler enthielten.

Ein Foto vom Aufbau kann Hinweise auf die Fehlerursache geben. Nicht 
alles im am Schaltplan erkennbar, und du hast ja sogar den zurück 
gehalten.

Es gilt weiterhin:

> Bei deiner Einstellung, notwendige Infos zurückzuhalten,
> kann ich Dir nicht weiter helfen.

Was ich glaube, zu benötigen, habe ich jetzt deutlich genug 
hingeschrieben. Mag sein, dass ich übertreibe, allerdings denke mal 
darüber nach, warum wohl sonst keiner einen Versuch gestartet hat, Dir 
zu helfen. Hmm?

Ich habe mitbekommen, dass gestern Abend mindestens zwei STM32 Experten 
aktiv waren, die sich sehr viel besser auskennen, als ich. Beide 
beteiligen sich üblicherweise erst, wenn das Problem klar ist. Ich 
hingegen versuche im Zweifelsfall, die betroffene Person durch Fragen in 
die richtige Richtung zu lenken.

[Jim M. (turboj)]

J. T. schrieb:
> Wenn ich nun den
> USB-Stecker abziehe, und per Powerbank über den FS_USB_Anschluss
> versorgen will, tut sich nichts (umgejumpert habe ich).

Hast Du mal den Schaltplan studiert wo das Taktsignal herkommt? Und 
nein, ich schaue da ohne angemessene Bezahlung nicht selbst rein.

Ich habe im Hinterkopf das auf einigen STM32 Referenz-Platinen das 
Signal aus dem ST-Link gespeist wird.

Der wird ohne PC dran aber nix generieren...

Abhilfe: STM32 auf internen Takt umprogrammieren.

[m.n. (Gast)]

J. T. schrieb:
> Ein weiteres Problem das aufgetaucht ist, ist dass der µc scheinbar sein
> Programm vergisst

Das kann passieren, wenn etwas mit dem Reset nicht stimmt. Sind 
vielleicht die BOOT-Pins nicht richtig beschaltet?
Der Debugger liefert entweder selber einen Reset oder ist nicht darauf 
angewiesen. Kontrolliere das bitte einmal.

Jim M. schrieb:
> Abhilfe: STM32 auf internen Takt umprogrammieren.

Ohne jetzt nachzusehen: bei fehlendem HSE-Takt wird intern auf HSI 
zurückgechaltet. Daran wird es nicht liegen.

[Stefan F. (Gast)]

m.n. schrieb:
> Sind vielleicht die BOOT-Pins nicht richtig beschaltet?

Unwahrscheinlich, es handelt sich um ein fertiges Board von ST.

> Ohne jetzt nachzusehen: bei fehlendem HSE-Takt wird intern auf HSI
> zurückgeschaltet. Daran wird es nicht liegen.

Nein, das macht der Chip nicht automatisch. Dazu muss man eine 
entsprechende Fehlerbehandlung einprogrammieren.

Aber das Programm und Schaltplan will er uns ja nicht zeigen. Weiter 
herum zu raten scheint mir wenig hilfreich, hat der TO auch schon 
abgelehnt.

[m.n. (Gast)]

Stefanus F. schrieb:
> Aber das Programm und Schaltplan will er uns ja nicht zeigen. Weiter
> herum zu raten scheint mir wenig hilfreich, hat der TO auch schon
> abgelehnt.

Dann halte Dich doch einfach mal zurück. Deine Aussagen geben keine 
Tatsachen sondern Dein Bauchgefühl wider. Damit kann man nicht viel 
anfangen.

[Christopher J. (christopher_j23)]

Jim M. schrieb:
> Ich habe im Hinterkopf das auf einigen STM32 Referenz-Platinen das
> Signal aus dem ST-Link gespeist wird.
>
> Der wird ohne PC dran aber nix generieren...

Warum denn nicht? So lange der ST-Link irgendwoher seine 
Versorgungsspannung bekommt sollte das mit der Taktausgabe doch laufen, 
egal ob am PC angestöpselt oder nicht.

J. T. schrieb:
> Wenn ich dann aber den Flash AUSLESE! mit dem ST_Link, wird alles
> richtig angezeigt, und dass für mich wirrste ist, dass nach dem auslesen
> alles läuft. Erst wenn ich ihm den Strom wegnehme und wieder anstecke,
> ist es wieder so. Ich muss den Flash erst auslesen, bevor der Controller
> losrennt....

Das klingt zu 99% nach aktiviertem Semihosting. Semihosting hat die 
unangenehme Eigenschaft, dass der Controller crasht, wenn kein Debugger 
angeschlossen ist bzw. (afaik) der Debugger nicht mit dem PC verbunden 
ist. Durch das auslesen des Flash stellst du genau diese beiden Dinge 
sicher und alles funktioniert.

Wie du Semihosting in SW4STM32 aktivierst oder deaktivierst kann ich dir 
auf die Schnelle leider nicht sagen, weil ich es hier nicht installiert 
habe aber eine kurze Google-Suche sollte da brauchbare Ergebnisse 
liefern. Prinzipiell sollte man das auswählen können wenn man ein neues 
Projekt erstellt. Bring also möglichst erstmal ein frisches Blinky zum 
laufen.

[J. T. (chaoskind)]

@Stefan:
Noch einmal, ich weigere mich nicht, ich erachte es als sinnlos. Aber 
nun im angehängten Dokument finden sich Schaltpläne und Fotos vom Board 
und meine main. An der Hardware habe ich nichts geändert.

Jim M. schrieb:
> Ich habe im Hinterkopf das auf einigen STM32 Referenz-Platinen das
> Signal aus dem ST-Link gespeist wird.

Auf dem 32f746Disco gibt es Jumper über die du die Spannungsversorgung 
wählen kannst. Wenn du über das ST-Link speist, musst du tatsächlich am 
Rechner eingesteckt sein, weil dann irgendwelche Startsignale vom 
ST-Link erwartet werden.(Habs nicht genauer nachgelesen).

Was mir noch eingefallen ist (das Problem besteht schon länger), einmal 
hab ich versucht, über USB_FS zu versorgen. Also die Spannungsversorgung 
umgejumpert, 5v an USB_FS angesteckt, und es ging nicht. Dann zusätzlich 
das ST_Link angesteckt und den Flash ausgelesen. Dann lief es und danach 
konnt ich sogar sowohl ST-Link abziehen und USB_FS abziehen, und wenn 
ich dann USB_FS wieder ansteckte lief es ganz normal los.


Ich vermute immer noch, dass die Problematik aus der IDE kommen muss. 
Hab ich zwar eigentlich keinen Grund für, da ich bewusst nichts 
verstellt hab. Aber es lief ja alles mal. Und am Board habe ich nicht 
nur bewusst nichts geändert, sondern sicher nichts geändert.

m.n. schrieb:
> Ohne jetzt nachzusehen: bei fehlendem HSE-Takt wird intern auf HSI
> zurückgechaltet. Daran wird es nicht liegen.

HSE ist vorhanden und liegt an. Darüber läuft das Board ja. Und nach dem 
Flash auslesen läufts ja auch.

Christopher J. schrieb:
> Warum denn nicht? So lange der ST-Link irgendwoher seine
> Versorgungsspannung bekommt sollte das mit der Taktausgabe doch laufen,
> egal ob am PC angestöpselt oder nicht.

Damit hat er tatsächlich ein Problem. Wenn ich am USB_Link nur 5V 
einspeise, dann läuft es gar nicht erst los, aber dazu gibt is irgendwo 
auch nen Satz in einm der unendlich vielen PDFs, die es zu dem Board und 
dem µC gibt. Ich weiß nicht mehr wo mir der Satz begegnete.

Christopher J. schrieb:
> Das klingt zu 99% nach aktiviertem Semihosting. Semihosting hat die
> unangenehme Eigenschaft, dass der Controller crasht, wenn kein Debugger
> angeschlossen ist bzw. (afaik) der Debugger nicht mit dem PC verbunden
> ist. Durch das auslesen des Flash stellst du genau diese beiden Dinge
> sicher und alles funktioniert.
>
> Wie du Semihosting in SW4STM32 aktivierst oder deaktivierst kann ich dir
> auf die Schnelle leider nicht sagen, weil ich es hier nicht installiert
> habe aber eine kurze Google-Suche sollte da brauchbare Ergebnisse
> liefern. Prinzipiell sollte man das auswählen können wenn man ein neues
> Projekt erstellt. Bring also möglichst erstmal ein frisches Blinky zum
> laufen.

Dann will ich mal rausfinden, wo ich dass ausschalten kann. Ich hatte 
gestern nur noch grob rausgefunden, wass das Semihosting denn überhaupt 
ist.

Danke für die hilfreichen Antworten

[J. T. (chaoskind)]

J. T. schrieb:
> einmal
> hab ich versucht, über USB_FS zu versorgen. Also die Spannungsversorgung
> umgejumpert, 5v an USB_FS angesteckt, und es ging nicht. Dann zusätzlich
> das ST_Link angesteckt und den Flash ausgelesen. Dann lief es und danach
> konnt ich sogar sowohl ST-Link abziehen und USB_FS abziehen, und wenn
> ich dann USB_FS wieder ansteckte lief es ganz normal los.

Das hier grad nochmal versucht. Das geht auch noch.

[J. T. (chaoskind)]

P.S.
Hier auch noch das Cubefile

[Johannes S. (Gast)]

wenn das semihosting aktiviert ist müsste folgendes in der Linker Flags 
zu finden sein:
-specs=rdimon.specs -lc -lrdimon
Und auch beim debugger starten sollte die Meldung 'semihosting is 
enabled' zu sehen sein, ansonsten wird das nicht die Ursache sein.
Hier ist das gut beschrieben:
http://alphaloewe.com/2017/01/24/enable-semi-hosting-with-openstm32-system-workbench/

[J. T. (chaoskind)]

Das steht in meinem Linkersettings:

-mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16 
-specs=nosys.specs -specs=nano.specs -T"../STM32F746NGHx_FLASH.ld" 
-Wl,-Map=output.map -Wl,--gc-sections -lm

also vermutlich kein Semihosting?

[Johannes S. (Gast)]

könnten theoretisch noch in dem .ld linker input stehen, wird aber eher 
nicht so sein. Als fällt diese Ursache weg.
Um zu sehen welcher clock tatsächlich verwendet wird kann man sich 
SystemClock_Config() ansehen.

[J. T. (chaoskind)]

Ja sieht nach HSE aus. So hatte ich es auch in Cube konfiguriert.... 
wobei auch HSI wird eingeschaltet.... komisch

void SystemClock_Config(void)
{

  RCC_OscInitTypeDef RCC_OscInitStruct;
  RCC_ClkInitTypeDef RCC_ClkInitStruct;
  RCC_PeriphCLKInitTypeDef PeriphClkInitStruct;

    /**Configure the main internal regulator output voltage 
    */
  __HAL_RCC_PWR_CLK_ENABLE();

  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = 16;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 25;
  RCC_OscInitStruct.PLL.PLLN = 432;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = 9;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**Activate the Over-Drive mode 
    */
  if (HAL_PWREx_EnableOverDrive() != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_7) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

  PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_LTDC|RCC_PERIPHCLK_USART1
                              |RCC_PERIPHCLK_SAI2|RCC_PERIPHCLK_I2C1
                              |RCC_PERIPHCLK_CLK48;
  PeriphClkInitStruct.PLLI2S.PLLI2SN = 344;
  PeriphClkInitStruct.PLLI2S.PLLI2SP = RCC_PLLP_DIV2;
  PeriphClkInitStruct.PLLI2S.PLLI2SR = 2;
  PeriphClkInitStruct.PLLI2S.PLLI2SQ = 7;
  PeriphClkInitStruct.PLLSAI.PLLSAIN = 432;
  PeriphClkInitStruct.PLLSAI.PLLSAIR = 2;
  PeriphClkInitStruct.PLLSAI.PLLSAIQ = 3;
  PeriphClkInitStruct.PLLSAI.PLLSAIP = RCC_PLLSAIP_DIV2;
  PeriphClkInitStruct.PLLI2SDivQ = 1;
  PeriphClkInitStruct.PLLSAIDivQ = 2;
  PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_2;
  PeriphClkInitStruct.Sai2ClockSelection = RCC_SAI2CLKSOURCE_PLLI2S;
  PeriphClkInitStruct.Usart1ClockSelection = RCC_USART1CLKSOURCE_PCLK2;
  PeriphClkInitStruct.I2c1ClockSelection = RCC_I2C1CLKSOURCE_PCLK1;
  PeriphClkInitStruct.Clk48ClockSelection = RCC_CLK48SOURCE_PLL;
  if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

  HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSI, RCC_MCODIV_1);

    /**Configure the Systick interrupt time 
    */
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

    /**Configure the Systick 
    */
  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* SysTick_IRQn interrupt configuration */
  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
}

[Johannes S. (Gast)]

Laut Schaltplan ist auch ein 25 MHz Oszillator vorhanden, -X2 sollte 
bestückt sein. D.h. der Clock kommt nicht wie bei einigen anderen 
Nucleos von dem angeflanschten STLink.

[J. T. (chaoskind)]

Johannes S. schrieb:
> aut Schaltplan ist auch ein 25 MHz Oszillator vorhanden, -X2 sollte
> bestückt sein. D.h. der Clock kommt nicht wie bei einigen anderen
> Nucleos von dem angeflanschten STLink.

Ja der ist quasi die Taktquelle von dem ganzen HSE-Geraffel. Bei den 
Discos kannst du angeblich den STlink Teil abknipsen. Wobei ich mir beim 
F7 nicht vorstellen kann, wie das schadlos gehen soll.

Ich bin jetzt grad dabei, wie vorgeschlagen, ein nacktes Blinky zu 
erstellen. Meld mich gleich wieder

[J. T. (chaoskind)]

Nun spuckt Cube so "lustige" Sachen aus wie:

void SVC_Handler(void)
{
  /* USER CODE BEGIN SVCall_IRQn 0 */

  /* USER CODE END SVCall_IRQn 0 */
  HAL_SVCall_IRQHandler
  /* USER CODE BEGIN SVCall_IRQn 1 */

  /* USER CODE END SVCall_IRQn 1 */
}

Wenn ich daraus "

HAL_SVCall_IRQHandler();

" mache, warnt er mich wegen der impliziten Deklaration vom IRQHandler 
und bricht letzlich mit einer undefined reference zu dem Handler ab.....

So richtig durchsichtig is Cube irgendwie auch nicht....

[Johannes S. (Gast)]

J. T. schrieb:
> HAL_SVCall_IRQHandler

Zeile löschen wenn du den nicht definiert hast.

[Johannes S. (Gast)]

oder mal mbed-os ausprobieren, das Disco F746 wird auch unterstützt.
https://github.com/ARMmbed/mbed-os-example-blinky
mbed-cli installieren, das Beispiel wie auf der Seite importieren.
Kompilieren mit 'mbed compile -m DISCO_F746NG -t gcc_arm', das liefert 
in ./BUILD ein .bin das auf das board kopiert werden kann.
Es gibt auch einen export nach SW4STM32: 'mbed export -m DISCO_F746NG -i 
SW4STM32'. Alternativ noch '-z' hinten dran, dann bekommt man ein 
gezipptes project das in der IDE importiert werden kann.
Für dieses Board gibt es auch ein BSP das man auch in mbed benutzen 
kann, habe ich mit dem Disco F469NI auch gerade gemacht.

[Stefan F. (Gast)]

J. T. schrieb:
> Ja sieht nach HSE aus. So hatte ich es auch in Cube konfiguriert....
> wobei auch HSI wird eingeschaltet.... komisch

HSI ist schon beim Reset aktiv und muss bei der Konfiguration der 
Taktquelle zunächst aktiv bleiben.

Die Software schaltet den HSE Oszillator ein, wartet bis er 
eingeschwungen ist und schaltet erst dann auf diesen um.

Erst danach kann man den HSI Oszillator abschalten. Ansonsten hängt sich 
der µC auf.

Dieser Ablauf ist in HAL_RCC_OscConfig() verborgen.

> Ich bin jetzt grad dabei, wie vorgeschlagen, ein
> nacktes Blinky zu erstellen. Meld mich gleich wieder

Gut, so würde ich jetzt auch vorgehen.

Hab ich Dich richtig verstanden, dass du nur das nackte Board ohne 
Modifikation oder externe Beschaltung verwendest?

[J. T. (chaoskind)]

Johannes S. schrieb:
> Zeile löschen wenn du den nicht definiert hast.

Danke das hat geholfen.

So ich hab nun ein minimales blinky gemacht. Nur ein Timer der ne PWM 
macht.

Das Problem bleibt bestehen...  Ich muss den Flash auslesen, damit es 
nach dem Anstecken losläuft.

Die Variablengeschichte hab ich jetzt noch nicht getestet, denke aber, 
da hat sich auch nichts geändert. Ich schau nochmal schnell

[J. T. (chaoskind)]

Ok.... Die Variablenwerte werden mir wieder angezeigt.

[Christopher J. (christopher_j23)]

J. T. schrieb:
> Das steht in meinem Linkersettings:
>
> -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16
> -specs=nosys.specs -specs=nano.specs -T"../STM32F746NGHx_FLASH.ld"
> -Wl,-Map=output.map -Wl,--gc-sections -lm
>
> also vermutlich kein Semihosting?

Möglich aber eben nicht ausgeschlossen. Es könnte theoretisch irgendwo 
einen Haken "Semihosting aktivieren" geben, der das dann noch an die 
Linkeranweisungen anhängt. Wenn du weißt wie man es einschaltet, dann 
kannst du es auch sicher abstellen

[J. T. (chaoskind)]

Christopher J. schrieb:
> Möglich aber eben nicht ausgeschlossen. Es könnte theoretisch irgendwo
> einen Haken "Semihosting aktivieren" geben, der das dann noch an die
> Linkeranweisungen anhängt. Wenn du weißt wie man es einschaltet, dann
> kannst du es auch sicher abstellen

Ich hab zumindest kein solches Häkchen finden können.....

Im Anhang nochmal das Cubefile und die main zum laufenden blinky.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Hab ich Dich richtig verstanden, dass du nur das nackte Board ohne
> Modifikation oder externe Beschaltung verwendest?

Ja genau. Bzw jetzt fürs Blinky hab ich die Masseleitung meines Oszis an 
GND und den Tastkopf auf D3 von CN4.

Dank dir auch für die Erläuterung zum Oszilatoranschwingen!

[J. T. (chaoskind)]

J. T. schrieb:
> Ja genau. Bzw jetzt fürs Blinky hab ich die Masseleitung meines Oszis an
> GND und den Tastkopf auf D3 von CN4.

P.S.

Und in dieser Konfiguration werden mir die Werte von Variablen wieder 
angezeigt, jedoch besteht das Problem mit dem pseudovergesslichen Flash 
weiterhin.

[Stefan F. (Gast)]

Messe mal die Spannung an den beiden Boot Pins.

Und probiere aus, ob dein Problem auch besteht, wenn du das Board über 
seinen USB Anschluss mit einem handy-Ladegerät (statt PC) verbindest. 
Ich will wissen, ob der ST-Link (warum auch immer) unbedingt über USB 
versorgt werden will.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Messe mal die Spannung an den beiden Boot Pins.

Wo finde ich die? Sind die auf die Connectors rausgeführt? Auf nen 
schnellen Blick find ich sie zumindest nicht....

Meinst du die am ST-Link? Boot0 und 1?

[J. T. (chaoskind)]

Die sind im Betrieb beide auf 0V.

[Stefan F. (Gast)]

m.n. schrieb:
> Sind vielleicht die BOOT-Pins nicht richtig beschaltet?

(Keine Reaktion)

J. T. schrieb:
>> Messe mal die Spannung an den beiden Boot Pins.
> Wo finde ich die? Sind die auf die Connectors rausgeführt? Auf nen
> schnellen Blick find ich sie zumindest nicht....

(Ich habe gerade die Augen verdreht)

Denn diese Info steht in dem von Dir geposteten PDF Dokument. Man findet 
sie, indem man Strg-F drücken und dann "boot" eintippt.

[Stefan F. (Gast)]

J. T. schrieb:
> Die (Boot Pins) sind im Betrieb beide auf 0V.

So soll es auch sein.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Und probiere aus, ob dein Problem auch besteht, wenn du das Board über
> seinen USB Anschluss mit einem handy-Ladegerät (statt PC) verbindest.
> Ich will wissen, ob der ST-Link (warum auch immer) unbedingt über USB
> versorgt werden will.

Wenn ich ne Powerbank an den ST-Link USB Anschluss stecke, passiert 
nichts. Wenn ich umjumper und über FS_USB mit der Powerbank versorge, 
geht auch nichts.
Wenn ich dann in diesem Zustand zusätzlich wieder den ST-Link 
USB-Anschluss mit dem Rechner verbinde, den Flash auslese und resete, 
dann läuft es. Danach kann ich dann auch den ST-Link abziehen. Und wenn 
ich dann auch noch den FS_USB abziehe und wieder anstecke, dann läuft es 
als wäre nie was gewesen...

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Denn diese Info steht in dem von Dir geposteten PDF Dokument. Man findet
> sie, indem man Strg-F drücken und dann "boot" eintippt.

Auf den Gedanken kam ich dann auch, nachdem ich sie auf nen schnellen 
Blick nicht fand :D

Stefanus F. schrieb:
> m.n. schrieb:
>> Sind vielleicht die BOOT-Pins nicht richtig beschaltet?
>
> (Keine Reaktion)

Es wurde doch mehrfach erwähnt, das ich ein originales ST-Board benutze. 
Die sollten das schon richtig gemacht haben..

[J. T. (chaoskind)]

Ein bischen Offtopic:
Ich hab nebenbei ein wenig gelesen, wie ich denn mit der HAL den 
PWM-Wert ändern kann. Dabei bin ich auf Konstrukte wie sowas gestoßen:

/* USER CODE BEGIN 4 */
void user_pwm_setvalue(uint16_t value)
{
    TIM_OC_InitTypeDef sConfigOC;
  
    sConfigOC.OCMode = TIM_OCMODE_PWM1;
    sConfigOC.Pulse = value;
    sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH;
    sConfigOC.OCFastMode = TIM_OCFAST_DISABLE;
    HAL_TIM_PWM_ConfigChannel(&htim4, &sConfigOC, TIM_CHANNEL_1);
    HAL_TIM_PWM_Start(&htim4, TIM_CHANNEL_1);  
}
/* USER CODE END 4 */

warum so wahnsinnig umständlich? Was spricht dagegen, dass einfach so zu 
machen?:

uint32_t PWM_Wert = 1500;
uint32_t *RegPt = 0x40000434; //Adresse vom "PWM-Wert-Register"
...
main()
*RegPt = PWM_Wert;

Ich habs grad probiert, und das klappt wunderbar. Handelt man sich damit 
irgendwelche Nebeneffekte ein die ich nicht sehe?

[Harry L. (mysth)]

J. T. schrieb:
> Ich habs grad probiert, und das klappt wunderbar. Handelt man sich damit
> irgendwelche Nebeneffekte ein die ich nicht sehe?

Ja, schwer nachvollziehbaren Code. (magic-Numbers)

Wenn du CubeMX und HAL nutzt, kannst du den PWM-Wert so einstellen:

  htim2.Instance->CCR1 = 2100;

[J. T. (chaoskind)]

Harry L. schrieb:
> htim2.Instance->CCR1 = 2100;

aahhaa! sowas hab ich gesucht. Kannst du mir sagen in welcher Datei ich 
die ganzen defines finde?

Harry L. schrieb:
> Ja, schwer nachvollziehbaren Code. (magic-Numbers)

Gut aber dagegen könnte man den RegPt ja PWM_Wert_Pt nennen und die 
Adresse noch als PWM_Wert_Reg_adr oder so definieren. Aber das ist dann 
vermutlich dass gleiche wie mit der Hal nur in grün.

[Harry L. (mysth)]

J. T. schrieb:
> Kannst du mir sagen in welcher Datei ich
> die ganzen defines finde?

Grep ist dein Freund...

Braucht man meist aber gar nicht.
Eclipse zeigt dir automatisch alle Struct-Member an.

[Harry L. (mysth)]

J. T. schrieb:
> Gut aber dagegen könnte man den RegPt ja PWM_Wert_Pt nennen und die
> Adresse noch als PWM_Wert_Reg_adr oder so definieren. Aber das ist dann
> vermutlich dass gleiche wie mit der Hal nur in grün.

Auch keine gute Idee!
Man nutzt die Bezeichnungen, die auch im Datenblatt stehen.

[Johannes S. (Gast)]

J. T. schrieb:
> Wenn ich ne Powerbank an den ST-Link USB Anschluss stecke, passiert
> nichts.

habe mein Board mal entstaubt und ein mbed blinky reingeladen. Das 
startet auch wenn ich das Board mit einer PB an dem STLink USB versorge.

[Johannes S. (Gast)]

Harry L. schrieb:
> Eclipse zeigt dir automatisch alle Struct-Member an.

genau, oder mit ctrl+click auf das Symbol wird die Datei mit der 
Definition/Implementierung geöffnet.

[Harry L. (mysth)]

Und falls du das noch nicht gefunden hast - dieses PDF solltest du dir 
anschauen:

https://www.st.com/content/ccc/resource/technical/document/user_manual/45/27/9c/32/76/57/48/b9/DM00189702.pdf/files/DM00189702.pdf/jcr:content/translations/en.DM00189702.pdf

[J. T. (chaoskind)]

Harry L. schrieb:
> Auch keine gute Idee!
> Man nutzt die Bezeichnungen, die auch im Datenblatt stehen.

Ok dass leuchtet ein. Danke dir, nun aber wieder zurück zum Thema bitte

[J. T. (chaoskind)]

Harry L. schrieb:
> Und falls du das noch nicht gefunden hast - dieses PDF solltest du dir
> anschauen:

Puh das ist ja n ganz schöner Klopper! Hatte ich aber bisher tatsächlich 
noch nicht gefunden. Nach dem Überfliegen des Inhaltsverzeichnises macht 
das den Eindruck eines mindestens leicht bis mittelschwer hilfreichen 
Dokumentes ;-)

[Stefan F. (Gast)]

Ich denke, dieses PDF ist nur zusammen mit dem Referenzhandbuch der 
STM32F7 Serie vollständig. Also noch ein Klopper oben drauf.

[Harry L. (mysth)]

Stefanus F. schrieb:
> Ich denke, dieses PDF ist nur zusammen mit dem Referenzhandbuch der
> STM32F7 Serie vollständig. Also noch ein Klopper oben drauf.

Nur im Ausnahmefall, bzw. erst später.

Für den Anfang ist da alles, was man zum Programmieren mit HAL benötigt 
enthalten.

[J. T. (chaoskind)]

Harry L. schrieb:
> Für den Anfang ist da alles, was man zum Programmieren mit HAL benötigt
> enthalten.

Das Gefühl hab ich nach dem Inhaltsverzeichnis auch. Den anderen hab ich 
übrigens auf meiner Festplatte, er kam mir bisher aber immer wenig 
hilfreich vor, weswegen die Konsultierungsfrequenz sich über die Zeit 
asymptotisch gegen Null entwickelte ;-) Irgendwie fehlt mir den 
"STM-Monstern" bzw deren Dokumenten die schlichte Klarheit der 
AVR-Dokus.
Aber vermutlich steht weder in dem einen noch in dem anderen was zu der 
Geschichte mit den Variablen und dem Flash.

Können wir uns bitte wieder darauf konzentrieren?

[J. T. (chaoskind)]

Johannes S. schrieb:
> habe mein Board mal entstaubt und ein mbed blinky reingeladen. Das
> startet auch wenn ich das Board mit einer PB an dem STLink USB versorge.

Sorry hab dich bis jetzt irgendwie überlesen. Das spricht dann ja für 
irgendwas mit der Hardware bei mir.
Welche LED sind bei dir am leuchten? Wenn wir mal die USB-Anschlüsse als 
unten definieren, dann leuchtet bei mir die LED direkt unter den 
4PowerJumpern rot, und die neben dem USB-ST-Link blinkt ca 5mal rot grün 
im geschätzten 10Hz-takt und leuchtet dann nen kleinen Moment grün. Der 
kleine Moment ist vermutlich so lang wie einmal rot-grün-rot vom 
schnellen Blinken dauert.

[J. T. (chaoskind)]

Wer auch immer alle meine Beiträge negativ und alle von Stefanus positiv 
bewertet hat, den Beitrag von Stefanus um 17:14 hast du 
fälschlicherweise negativ bewertet. Irgendwo zwischendrin hast du auch 
einen unbewertet gelassen

[Johannes S. (Gast)]

mein blinky lässt die LD1, grün, zwischen Resettaster und den Headerpins 
blinken. Ich hänge das .bin mal an.
Was noch sein könnte sind verstellte Option Bytes, habe meine, die noch 
original sein müssten, mal angehängt. Kann man im STLink Utility 
auslesen lassen. Damit kann man auch ein Update des STLink machen, 
vielleicht ist das auch etas zu alt.
Vergiss die Schei** Bewertungen hier.

[J. T. (chaoskind)]

Johannes S. schrieb:
> mein blinky lässt die LD1, grün, zwischen Resettaster und den Headerpins
> blinken. Ich hänge das .bin mal an.
> Was noch sein könnte sind verstellte Option Bytes, habe meine, die noch
> original sein müssten, mal angehängt. Kann man im STLink Utility
> auslesen lassen

Das werd ich mal testen

Johannes S. schrieb:
> Damit kann man auch ein Update des STLink machen,
> vielleicht ist das auch etas zu alt.

Das Update musste ich vor drei vier Wochen machen, als ich das Board mal 
wieder rausgekramte. Davor ging quasi gaaanix.

Johannes S. schrieb:
> Vergiss die Schei** Bewertungen hier.

Keine Sorge, die kümmern mich nicht. Ich frag mich eh, wer die ernsthaft 
nutzt. Ich fands nur lustig, beim nochmal nachlesen der Beiträge fiel 
mir das auf, alle meine durchgehend -1, alle von Stefanus bis auf den 
einen +1 :D. Freundlich wie ich bin, weise ich natürlich auf den 
offensichtlich gemachten Fehler hin

[Stefan F. (Gast)]

J. T. schrieb:
> Wer auch immer alle meine Beiträge negativ und alle
> von Stefanus positiv bewertet hat ...

Guck da gar nicht hin. Es gibt hier einen (oder mehrere) Spaßvögel, 
welche die Bewertungsfunktion missbrauchen, um Ärger zu provozieren.

Zudem benutzen die meisten anderen die Bewertungsfunktion, um anzugeben, 
ob sie zustimmen oder ablehnen. Dazu ist sie aber nicht vorgesehen, was 
schon aus der Beschriftung hervor geht.

Ich verdeutliche das mal an einem extremen Beispiel:
Wenn ein Islamist ausführlich erklärt, warum er eine Bombe gelegt hat, 
dann finde das äußerst interessant und lesenwert. Aber ich stimme seiner 
Ideologie nicht zu.

Soll ich dann +1 anklicken, oder besser nicht? Das muss jeder für sich 
entscheiden.

[J. T. (chaoskind)]

Meine Option-Bytes sehen genauso aus wie bei dir, und es blinkt auch an 
der LED, wenn ich dein bin flashe. Aber sobald ich den Stecker abziehe 
und wieder anstecke, muss ich den Flash auslesen damit es losläuft. Vor 
dem Auslesen ist ein Druck auf den Resetbutton wirkungsfrei, hinter 
läuft er los, der Controller. Immerhin werden in meinem blinky die 
Variablen shconmal angezeigt. Warum das in meinem größeren Programm 
nicht klappt, wüsste ich auch gern. Alles ganz schon undurchsichtig für 
mich =(

[Harry L. (mysth)]

Geh das mal systematisch an!
Generiere mit CubeMX ein leeres neues Projekt mit deinem Board als 
Template.
Dann fügst du in die main-loop in main.c nur den folgenden Code ein:

/* USER CODE BEGIN 3 */
      HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);
      HAL_Delay(300);
      HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET);
      HAL_Delay(300);

Die Port- und Pin-Bezeichnungen musst du natürlich auf deine Hardware 
anpassen.
In der generierten main.h sind die bereits für die auf dem Board 
istallierten LEDs definiert.

Ansonsten nix anpacken, und dann mal schauen, ob das Problem immer noch 
auftritt.

[J. T. (chaoskind)]

Mir ist grad noch etwas aufgefallen. Die LED neben dem USB-stecker 
leuchtet erst rot wenn ich den Stecker "neu" einstecke. Wenn ich dann 
mit ST-Link Utility connecte blinkt sie in beschriebener Weise und wenn 
ich dann disconnecte, leuchet sie durchgehend grün. Das will mir doch 
sicher auch irgendwas sagen?

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Guck da gar nicht hin. Es gibt hier einen (oder mehrere) Spaßvögel,
> welche die Bewertungsfunktion missbrauchen, um Ärger zu provozieren.
>
> Zudem benutzen die meisten anderen die Bewertungsfunktion, um anzugeben,
> ob sie zustimmen oder ablehnen. Dazu ist sie aber nicht vorgesehen, was
> schon aus der Beschriftung hervor geht.
>
> Ich verdeutliche das mal an einem extremen Beispiel:
> Wenn ein Islamist ausführlich erklärt, warum er eine Bombe gelegt hat,
> dann finde das äußerst interessant und lesenwert. Aber ich stimme seiner
> Ideologie nicht zu.
>
> Soll ich dann +1 anklicken, oder besser nicht? Das muss jeder für sich
> entscheiden.

Dein Beispiel gefällt mir irgendwie :D

[Stefan F. (Gast)]

Ich würde die Konfiguration der Taktquelle für diesen Test auch erstmal 
auf die einfachste Option reduzieren, und zwar alles auf 16 MHz mit HSI 
Oszillator stellen.

[Johannes S. (Gast)]

J. T. schrieb:
> Mir ist grad noch etwas aufgefallen. Die LED neben dem USB-stecker
> leuchtet erst rot wenn ich den Stecker "neu" einstecke.

bei mir leuchtet die auch rot (du meinst die Mehrfarbled?), bei connect 
blinkt es rot/grün und bei disconnect wieder dauer rot, dann grün. Also 
auch wie bei dir.
Hast du mit dem STLink Util auch mal den Speicher komplett gelöscht?

[Harry L. (mysth)]

Stefanus F. schrieb:
> Ich würde die Konfiguration der Taktquelle für diesen Test auch erstmal
> auf die einfachste Option reduzieren, und zwar alles auf 16 MHz mit HSI
> Oszillator stellen.

Warum sollte man sowas bei einem von CubeMX generierten Code für ein 
0815-ST-Boad tun?
Die Grundeinstellungen sind durchaus sinnvoll und funktionieren.

[Johannes S. (Gast)]

Stefanus F. schrieb:
> Ich würde die Konfiguration der Taktquelle für diesen Test auch erstmal
> auf die einfachste Option reduzieren, und zwar alles auf 16 MHz mit HSI
> Oszillator stellen.

warum soll das gleiche Programm bei mir starten und bei ihm nicht? An 
den Takten kann man nichts per HW verstellen, auf dem Disco board sind 
nur Jumper für die Stromversorgung. Der Oszi -X2 ist vorhanden, das war 
doch auch schon geklärt. Das Disco ist kein Nucleo wo der STLink 
abtrennbar ist.

[Stefan F. (Gast)]

Harry L. schrieb:
>> Ich würde die Konfiguration der Taktquelle für diesen Test
>> auch erstmal auf die einfachste Option reduzieren, und zwar
>> alles auf 16 MHz mit HSI Oszillator stellen.

> Warum sollte man sowas bei einem von CubeMX generierten Code für ein
> 0815-ST-Boad tun?

Weil

a) Es vielleicht ein Problem mit dem HSE Oszillator gibt

b) Ich mit genau diesem Stück von Cube HAL erzeugten Code in meinem 
allerersten Projekt auf die Nase gefallen bin*. Ich traue diesem Rotz 
keine 5 Zentimeter weit.

* Der Fehler der mich damals betraf ist inzwischen von ST behoben 
worden.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Ich würde die Konfiguration der Taktquelle für diesen Test auch erstmal
> auf die einfachste Option reduzieren, und zwar alles auf 16 MHz mit HSI
> Oszillator stellen.

Ich glaub auch nich so recht, dass der Wurm da begraben liegt. Bin jetzt 
aber grad nochmal hierbei:

Harry L. schrieb:
> Geh das mal systematisch an!
> Generiere mit CubeMX ein leeres neues Projekt mit deinem Board als
> Template.
> Dann fügst du in die main-loop in main.c nur den folgenden Code ein:
> /* USER CODE BEGIN 3 */
>       HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);
>       HAL_Delay(300);
>       HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET);
>       HAL_Delay(300);

Wobei ich auch da nicht so recht dran glauben kann, ich hab ja eben ein 
quasi leeres Projekt erstellt. Leer bis auf den Timer für ne PWM, die 
ich mir mit dem Oszi anguckte, anstelle die LED blinken zu lassen.

Johannes S. schrieb:
> bei mir leuchtet die auch rot (du meinst die Mehrfarbled?)

Genau die mein ich. Das scheint also auch normal zu sein....

Johannes S. schrieb:
> warum soll das gleiche Programm bei mir starten und bei ihm nicht?

Und dein blinky.bin läuft ja auch bei mir und macht das gleiche wie bei 
dir...

[J. T. (chaoskind)]

Stefanus F. schrieb:
> b) Ich mit genau diesem Stück von Cube HAL erzeugten Code in meinem
> allerersten Projekt auf die Nase gefallen bin*. Ich traue diesem Rotz
> keine 5 Zentimeter weit.

Ja das kenn ich auch noch, das führte dazu, dass ich die Boards erstmal 
ne lange Zeit aus der Hand legte. Aber nun scheint das Zeugs halbwegs zu 
laufen.

Es klappte vor kurzem ja noch alles fehlerfrei, und dann wie gesagt 
traten am nächsten Tag die genannten Probleme auf.

[Harry L. (mysth)]

Stefanus F. schrieb:
> Weil
>
> a) Es vielleicht ein Problem mit dem HSE Oszillator gibt

Dann stellt man das im CubeMX um.

Stefanus F. schrieb:
> b) Ich mit genau diesem Stück von Cube HAL erzeugten Code in meinem
> allerersten Projekt auf die Nase gefallen bin*. Ich traue diesem Rotz
> keine 5 Zentimeter weit.

Kannst du ja für dichso halten, aber mir scheint eher, daß du das 
Konzept von CubeMX nicht wirklich verstanden hast, und auch HAL nur 
oberflächlich kennst.

Der TO hat aber nunmal ein Projekt mit CubeMX und HAL, und ihm dann zu 
raten, das durch solche manuellen Eingriffe an dieser Stelle kaputt zu 
machen ist kontraproduktiv.

[Stefan F. (Gast)]

Harry L. schrieb:
>> a) Es vielleicht ein Problem mit dem HSE Oszillator gibt
> Dann stellt man das im CubeMX um.

Ach nee, genau das habe ich doch empfohlen!

> Mir scheint eher, daß du das
> Konzept von CubeMX nicht wirklich verstanden hast, und auch HAL nur
> oberflächlich kennst.

Das hast du korrekt erkannt.

Wenn aber schon mein leeres Projekt, wo alles auf Default steht, auf dem 
nagelneuen fertigen Board von ST nicht einmal bis zum ersten Breakpoint 
(am Anfang der main() Funktion) kommt, dann kann ich sicher sein, dass 
das Problem nicht vor dem Bildschirm sitzt. Und so war es ja auch.

Mit Hilfe dieses Forums wurde der Fehler im Quelltext der HAL Library 
identifiziert, gemeldet und behoben. Und ich hatte meinen Anreiz, mal 
das Referenzhandbuch zu lesen, anstatt nur die Doku der HAL.

> Der TO hat aber nunmal ein Projekt mit CubeMX und HAL, und ihm dann zu
> raten, das durch solche manuellen Eingriffe an dieser Stelle kaputt zu
> machen ist kontraproduktiv.

Ich habe doch gar nicht von einem manuellen Eingriff geschrieben. 
Selbstverständlich sollte er die Taktkonfiguration in Cube MX 
einstellen. 16 MHz HSI ist technisch gesehen die einfachste Option, da 
schon durch den Hardware-Reset vorgegeben. Bei dieser kann am wenigsten 
schief gehen.

[Harry L. (mysth)]

Stefanus F. schrieb:
> Harry L. schrieb:
>>> a) Es vielleicht ein Problem mit dem HSE Oszillator gibt
>> Dann stellt man das im CubeMX um.
>
> Ach nee, genau das habe ich doch empfohlen!
>
>> Mir scheint eher, daß du das
>> Konzept von CubeMX nicht wirklich verstanden hast, und auch HAL nur
>> oberflächlich kennst.
>
> Das hast du korrekt erkannt.
>
> Wenn aber schon mein leeres Projekt, wo alles auf Default steht, auf dem
> nagelneuen fertigen Board von ST nicht einmal bis zum ersten Breakpoint
> (am Anfang der main() Funktion) kommt, dann kann ich sicher sein, dass
> das Problem nicht vor dem Bildschirm sitzt. Und so war es ja auch.
>
> Mit Hilfe dieses Forums wurde der Fehler im Quelltext der HAL Library
> identifiziert, gemeldet und behoben. Und ich hatte meinen Anreiz, mal
> das Referenzhandbuch zu lesen, anstatt nur die Doku der HAL.
>
>> Der TO hat aber nunmal ein Projekt mit CubeMX und HAL, und ihm dann zu
>> raten, das durch solche manuellen Eingriffe an dieser Stelle kaputt zu
>> machen ist kontraproduktiv.
>
> Ich habe doch gar nicht von einem manuellen Eingriff geschrieben.
> Selbstverständlich sollte er die Taktkonfiguration in Cube MX
> einstellen. 16 MHz HSI ist technisch gesehen die einfachste Option, da
> schon durch den Hardware-Reset vorgegeben. Bei dieser kann am wenigsten
> schief gehen.

Hat aber alles nix mit dem Problem zu tun.
Wenn ein leeres Projekt mit minimalem Blink-Code auf einem ST-Board 
nicht läuft, ist der Fehler wohl eher in der Hardware zu suchen.
USB-Kabel/Port oder das Board selbst.

Oder willst du mir erzählen, daß du in so einer minimal-Konfiguration 
immer noch Software-Fehler vermutest, die solche gravierenden 
Auswirkungen haben?

[Stefan F. (Gast)]

Harry L. schrieb:
> Hat aber alles nix mit dem Problem zu tun.
> Wenn ein leeres Projekt mit minimalem Blink-Code auf einem ST-Board
> nicht läuft, ist der Fehler wohl eher in der Hardware zu suchen.

Davon gehe ich aus.

Indem wir den HSE Oszillator durch HSI austauschen finden wir heraus, ob 
die Problemursache beim Oszillator liegt.

> Oder willst du mir erzählen, daß du in so einer minimal-Konfiguration
> immer noch Software-Fehler vermutest, die solche gravierenden
> Auswirkungen haben?

Die Minimalkonfiguration dient dazu, die Möglichkeit von Softwarefehlern 
weitgehend auszuschließen. Deswegen habe ich dem Vorschlag ausdrücklich 
zugestimmt.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Indem wir den HSE Oszillator durch HSI austauschen finden wir heraus, ob
> die Problemursache beim Oszillator liegt.

Sollte dann aber nicht eigentlich nichts funktionieren, wenn der Fehler 
da läge?

Ich bin immer noch am erstellen, mein Rechner ist heute irgendwie 
hirnerweichend langsam. Teilweise braucht er mehr als 10 sekunden um von 
einem Fenster zu nem anderen zu wechseln und die Inhalte im Fenster 
bauen sich auch nur nach und nach auf.... Zwischendrin hängt die IDE 
dann auch gern mal für ne halbe Minute oder so mit "keine 
Rückmeldung"..... lustigerweise läuft wenn ich dann den Taskmanager 
öffne wieder alles flussig. Aber der Virenscanner findet auch nix...

SO endlich ist es soweit.

Ich hatte nun mit Cube ein neues Projekt für das Board erstellt. Dann 
hab ich die unter "Pinout" alles zurückgesetzt. Clock hab ich wie 
gewünscht auf HSI und bin die PLL umgangen und gehe direkt mit 16MHz auf 
den Syscklock.

Harry L. schrieb:
> HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);
>       HAL_Delay(300);
>       HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET);
>       HAL_Delay(300);
>
> Die Port- und Pin-Bezeichnungen musst du natürlich auf deine Hardware
> anpassen.
> In der generierten main.h sind die bereits für die auf dem Board
> istallierten LEDs definiert.

Irgendwie sind da keine LEDs definiert in der main.h. Aber laut dem von 
mir verlinkten PDF sollte die LED an PI1 stitzen. Das wäre dann d13 am 
Arduinoconnector. Bei dem blinky von johannes sehe ich sowohl an d13 auf 
dem Oszi etwas und die LED blinken.

      HAL_GPIO_WritePin(GPIOI, 0, GPIO_PIN_SET);
      HAL_Delay(300);
      HAL_GPIO_WritePin(GPIOI, 0, GPIO_PIN_RESET);
      HAL_Delay(300);

hab ich stattdessen geschrieben. Aber irgendwie tut sich nix. Also ich 
hab dass in den UserCode3-Teil geschmissen ansonsten das von Cube 
erstellte aber unverändert gelassen. Wobei nicht ganz:

void SVC_Handler(void)
{
  /* USER CODE BEGIN SVCall_IRQn 0 */

  /* USER CODE END SVCall_IRQn 0 */
 // HAL_SVCall_IRQHandler
  /* USER CODE BEGIN SVCall_IRQn 1 */

  /* USER CODE END SVCall_IRQn 1 */
}

HAL_SVCall_IRQHandler hab ich wieder auskommentiert, weil Cube das ohne 
Semikolon und sonstigen Schnickschnack den der Programmierer gern sieht, 
erzeugt.

[J. T. (chaoskind)]

Wie soll das auch gehen. Ich seh gerade das überhaupt keine GPIO inits 
erzeugt wurden..

[Harry L. (mysth)]

J. T. schrieb:
> Ich hatte nun mit Cube ein neues Projekt für das Board erstellt. Dann
> hab ich die unter "Pinout" alles zurückgesetzt.

J. T. schrieb:
> Irgendwie sind da keine LEDs definiert in der main.h.

Natürlich nicht, wenn du vorher im CubeMX alles zurückgesetzt hast.

Deshalb: nochmal von Vorne und alle Vorseinstellungen unverändert 
übernehmen.

Dann nur noch den Blink-Code in der main.c einfügen.

[Stefan F. (Gast)]

J. T. schrieb:
> mein Rechner ist heute irgendwie hirnerweichend langsam.
> lustigerweise läuft wenn ich dann den Taskmanager
> öffne wieder alles flussig.

Das hatte ich vor ein paar Wochen am Arbeitsplatz, wollte mir kein 
Kollege glauben, bis sie selbst geguckt haben.

Das Problem war zwei Tage später von selbst wieder verschwunden. keine 
Ahnung, woran es gelegen hat. Mein Chef vermutet ein fehlerhaftes 
Windows Update. Ich bin mir aber nicht dessen bewusst, unmittelbar 
vorher ein installiert zu haben.

[J. T. (chaoskind)]

Ich beiß gleich in die Tischkante.... Um 21:42 auf New Project geklickt 
im Cube, nun sagt die Uhr 21:46 und es ist immer noch das Auswahlfenster 
mit bläulich unterlegtem "New Project" zu sehen. Ah inzwischen sagt er 
auch "keine Rückmeldung"

P.S. und just wenn ich den Taskmanager in den Vordergrund hole, kommt 
die Auswahl zum Vorschein.... da stimmt doch was ganz gewaltig nicht...

[J. T. (chaoskind)]

So nun einfach ein neues Projekt bei Cube erstellt, die 
Clockeinstellungen musste ich reseten, da die von Cube generierten 
ungültig waren. Des weiteren musste ich "MX_SDMMC1_SD_Init();" 
auskommentieren, da er da in den Errorloop gesprungen ist.

  MX_GPIO_Init();
  MX_ADC3_Init();
  MX_DCMI_Init();
  MX_ETH_Init();
  MX_FMC_Init();
  MX_I2C1_Init();
  MX_I2C3_Init();
  MX_LTDC_Init();
  MX_QUADSPI_Init();
  MX_RTC_Init();
  MX_SAI2_Init();
 // MX_SDMMC1_SD_Init();
  MX_SPDIFRX_Init();
  MX_SPI2_Init();
  MX_TIM1_Init();
  MX_TIM2_Init();
  MX_TIM3_Init();
  MX_TIM5_Init();
  MX_TIM8_Init();
  MX_TIM12_Init();
  MX_USART1_UART_Init();
  MX_USART6_UART_Init();
  MX_USB_OTG_FS_USB_Init();
  MX_USB_OTG_HS_USB_Init();
  /* USER CODE BEGIN 2 */

  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {

  /* USER CODE END WHILE */

  /* USER CODE BEGIN 3 */
      HAL_GPIO_WritePin(GPIOI, 0, GPIO_PIN_SET);
      HAL_Delay(300);
      HAL_GPIO_WritePin(GPIOI, 0, GPIO_PIN_RESET);
      HAL_Delay(300);
  }
  /* USER CODE END 3 */

}

trotzdem blinkt keine LED

[Stefan F. (Gast)]

Kommentiere mal alle init Funktionen (außer die für GPIO) aus. Wenn es 
dann immer noch nicht blinkt, ist dein Board wohl defekt.

[Harry L. (mysth)]

Stefanus F. schrieb:
> Kommentiere mal alle init Funktionen (außer die für GPIO) aus. Wenn es
> dann immer noch nicht blinkt, ist dein Board wohl defekt.

Das wird nix!
HAL_Delay benötigt den Sysick (vom Timer)

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Kommentiere mal alle init Funktionen (außer die für GPIO) aus. Wenn es
> dann immer noch nicht blinkt, ist dein Board wohl defekt.

Es blinkt ja vor allem, wenn ich den das binary von Johannes lade.

[J. T. (chaoskind)]

Harry L. schrieb:
> HAL_Delay benötigt den Sysick (vom Timer)

Das könnt man zur Not ja auch mit ner Zählschleife ersetzen, wenn es 
erst mal nur um die Verzögerung fürs Blinken geht.

[Stefan F. (Gast)]

Harry L. schrieb:
>> Kommentiere mal alle init Funktionen (außer die für GPIO) aus. Wenn es
>> dann immer noch nicht blinkt, ist dein Board wohl defekt.
> Das wird nix!
> HAL_Delay benötigt den Sysick (vom Timer)

Ach ja, richtig.

Was ist eigentlich GPIOI? Ist dessen Wert richtig?

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Was ist eigentlich GPIOI? Ist dessen Wert richtig?

Ich bekomme dafür zumindest keine Fehlermeldung, und laut 
Boardbeschreibung sitzt die LED an Porti 1, dort konnte ich eine im Takt 
des Blinkens wecheselnde Spannung messen, als ich das blinkende binary 
von johannes flashte.

[Harry L. (mysth)]

Stefanus F. schrieb:
> Harry L. schrieb:
>>> Kommentiere mal alle init Funktionen (außer die für GPIO) aus. Wenn es
>>> dann immer noch nicht blinkt, ist dein Board wohl defekt.
>> Das wird nix!
>> HAL_Delay benötigt den Sysick (vom Timer)
>
> Ach ja, richtig.
>
> Was ist eigentlich GPIOI? Ist dessen Wert richtig?

Das sehe ich genauso.
So ist das nicht im Sinne des Erfinders.

In der main.h solltest du sowas in der Art finden:

/* Private define ------------------------------------------------------------*/

#define LED_Pin GPIO_PIN_13
#define LED_GPIO_Port GPIOC

[Stefan F. (Gast)]

J. T. schrieb:
> Es blinkt ja vor allem, wenn ich den das binary von Johannes lade.

Wenn alle Stricke reißen würde ich in Erwägung ziehen, dass deine HAL 
Library fehlerhaft ist.

Du kannst das Board mit deiner IDE auch "ohne Firmware" programmieren. 
Sicher findest du irgendwo im Netz ein minimales Led-Blinker Beispiel 
für deinen STM.

[J. T. (chaoskind)]

Harry L. schrieb:
> In der main.h solltest du sowas in der Art finden:/* Private define
> ------------------------------------------------------------*/
>
> #define LED_Pin GPIO_PIN_13
> #define LED_GPIO_Port GPIOC

Leider taucht nichts auf in der main.h. Weder die manuelle Suche noch 
die Suche der IDE brachte die Zeichenfolge "led" zutage.(case sensitive 
war bei der Suche deaktiviert).

Das ist alles was in der main.h steht:

/**
  ******************************************************************************
  * @file           : main.h
  * @brief          : Header for main.c file.
  *                   This file contains the common defines of the application.
  ******************************************************************************
  ** This notice applies to any and all portions of this file
  * that are not between comment pairs USER CODE BEGIN and
  * USER CODE END. Other portions of this file, whether 
  * inserted by the user or by software development tools
  * are owned by their respective copyright owners.
  *
  * COPYRIGHT(c) 2018 STMicroelectronics
  *
  * Redistribution and use in source and binary forms, with or without modification,
  * are permitted provided that the following conditions are met:
  *   1. Redistributions of source code must retain the above copyright notice,
  *      this list of conditions and the following disclaimer.
  *   2. Redistributions in binary form must reproduce the above copyright notice,
  *      this list of conditions and the following disclaimer in the documentation
  *      and/or other materials provided with the distribution.
  *   3. Neither the name of STMicroelectronics nor the names of its contributors
  *      may be used to endorse or promote products derived from this software
  *      without specific prior written permission.
  *
  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
  * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  *
  ******************************************************************************
  */

/* Define to prevent recursive inclusion -------------------------------------*/
#ifndef __MAIN_H__
#define __MAIN_H__

/* Includes ------------------------------------------------------------------*/

/* USER CODE BEGIN Includes */

/* USER CODE END Includes */

/* Private define ------------------------------------------------------------*/

#define LCD_B0_Pin GPIO_PIN_4
#define LCD_B0_GPIO_Port GPIOE
#define OTG_HS_OverCurrent_Pin GPIO_PIN_3
#define OTG_HS_OverCurrent_GPIO_Port GPIOE
#define QSPI_D2_Pin GPIO_PIN_2
#define QSPI_D2_GPIO_Port GPIOE
#define RMII_TXD1_Pin GPIO_PIN_14
#define RMII_TXD1_GPIO_Port GPIOG
#define FMC_NBL1_Pin GPIO_PIN_1
#define FMC_NBL1_GPIO_Port GPIOE
#define FMC_NBL0_Pin GPIO_PIN_0
#define FMC_NBL0_GPIO_Port GPIOE
#define ARDUINO_SCL_D15_Pin GPIO_PIN_8
#define ARDUINO_SCL_D15_GPIO_Port GPIOB
#define ULPI_D7_Pin GPIO_PIN_5
#define ULPI_D7_GPIO_Port GPIOB
#define ARDUINO_PWM_D3_Pin GPIO_PIN_4
#define ARDUINO_PWM_D3_GPIO_Port GPIOB
#define SWO_Pin GPIO_PIN_3
#define SWO_GPIO_Port GPIOB
#define SPDIF_RX0_Pin GPIO_PIN_7
#define SPDIF_RX0_GPIO_Port GPIOD
#define SDMMC_CK_Pin GPIO_PIN_12
#define SDMMC_CK_GPIO_Port GPIOC
#define ARDUINO_PWM_D9_Pin GPIO_PIN_15
#define ARDUINO_PWM_D9_GPIO_Port GPIOA
#define SWCLK_Pin GPIO_PIN_14
#define SWCLK_GPIO_Port GPIOA
#define SWDIO_Pin GPIO_PIN_13
#define SWDIO_GPIO_Port GPIOA
#define DCMI_D6_Pin GPIO_PIN_5
#define DCMI_D6_GPIO_Port GPIOE
#define DCMI_D7_Pin GPIO_PIN_6
#define DCMI_D7_GPIO_Port GPIOE
#define RMII_TXD0_Pin GPIO_PIN_13
#define RMII_TXD0_GPIO_Port GPIOG
#define ARDUINO_SDA_D14_Pin GPIO_PIN_9
#define ARDUINO_SDA_D14_GPIO_Port GPIOB
#define VCP_RX_Pin GPIO_PIN_7
#define VCP_RX_GPIO_Port GPIOB
#define QSPI_NCS_Pin GPIO_PIN_6
#define QSPI_NCS_GPIO_Port GPIOB
#define FMC_SDNCAS_Pin GPIO_PIN_15
#define FMC_SDNCAS_GPIO_Port GPIOG
#define RMII_TX_EN_Pin GPIO_PIN_11
#define RMII_TX_EN_GPIO_Port GPIOG
#define LCD_B1_Pin GPIO_PIN_13
#define LCD_B1_GPIO_Port GPIOJ
#define OTG_FS_VBUS_Pin GPIO_PIN_12
#define OTG_FS_VBUS_GPIO_Port GPIOJ
#define Audio_INT_Pin GPIO_PIN_6
#define Audio_INT_GPIO_Port GPIOD
#define FMC_D2_Pin GPIO_PIN_0
#define FMC_D2_GPIO_Port GPIOD
#define SDMMC_D3_Pin GPIO_PIN_11
#define SDMMC_D3_GPIO_Port GPIOC
#define SDMMC_D2_Pin GPIO_PIN_10
#define SDMMC_D2_GPIO_Port GPIOC
#define OTG_FS_P_Pin GPIO_PIN_12
#define OTG_FS_P_GPIO_Port GPIOA
#define NC1_Pin GPIO_PIN_8
#define NC1_GPIO_Port GPIOI
#define SAI2_MCLKA_Pin GPIO_PIN_4
#define SAI2_MCLKA_GPIO_Port GPIOI
#define LCD_DE_Pin GPIO_PIN_7
#define LCD_DE_GPIO_Port GPIOK
#define LCD_B7_Pin GPIO_PIN_6
#define LCD_B7_GPIO_Port GPIOK
#define LCD_B6_Pin GPIO_PIN_5
#define LCD_B6_GPIO_Port GPIOK
#define LCD_B4_Pin GPIO_PIN_12
#define LCD_B4_GPIO_Port GPIOG
#define SAI2_SDB_Pin GPIO_PIN_10
#define SAI2_SDB_GPIO_Port GPIOG
#define LCD_B2_Pin GPIO_PIN_14
#define LCD_B2_GPIO_Port GPIOJ
#define OTG_FS_PowerSwitchOn_Pin GPIO_PIN_5
#define OTG_FS_PowerSwitchOn_GPIO_Port GPIOD
#define DCMI_D5_Pin GPIO_PIN_3
#define DCMI_D5_GPIO_Port GPIOD
#define FMC_D3_Pin GPIO_PIN_1
#define FMC_D3_GPIO_Port GPIOD
#define ARDUINO_D7_Pin GPIO_PIN_3
#define ARDUINO_D7_GPIO_Port GPIOI
#define ARDUINO_D8_Pin GPIO_PIN_2
#define ARDUINO_D8_GPIO_Port GPIOI
#define OTG_FS_N_Pin GPIO_PIN_11
#define OTG_FS_N_GPIO_Port GPIOA
#define uSD_Detect_Pin GPIO_PIN_13
#define uSD_Detect_GPIO_Port GPIOC
#define FMC_A0_Pin GPIO_PIN_0
#define FMC_A0_GPIO_Port GPIOF
#define SAI2_SCKA_Pin GPIO_PIN_5
#define SAI2_SCKA_GPIO_Port GPIOI
#define SAI2_FSA_Pin GPIO_PIN_7
#define SAI2_FSA_GPIO_Port GPIOI
#define LCD_HSYNC_Pin GPIO_PIN_10
#define LCD_HSYNC_GPIO_Port GPIOI
#define SAI2_SDA_Pin GPIO_PIN_6
#define SAI2_SDA_GPIO_Port GPIOI
#define LCD_B5_Pin GPIO_PIN_4
#define LCD_B5_GPIO_Port GPIOK
#define LCD_BL_CTRL_Pin GPIO_PIN_3
#define LCD_BL_CTRL_GPIO_Port GPIOK
#define DCMI_VSYNC_Pin GPIO_PIN_9
#define DCMI_VSYNC_GPIO_Port GPIOG
#define LCD_B3_Pin GPIO_PIN_15
#define LCD_B3_GPIO_Port GPIOJ
#define OTG_FS_OverCurrent_Pin GPIO_PIN_4
#define OTG_FS_OverCurrent_GPIO_Port GPIOD
#define SDMMC_CMD_Pin GPIO_PIN_2
#define SDMMC_CMD_GPIO_Port GPIOD
#define TP3_Pin GPIO_PIN_15
#define TP3_GPIO_Port GPIOH
#define ARDUINO_SCK_D13_Pin GPIO_PIN_1
#define ARDUINO_SCK_D13_GPIO_Port GPIOI
#define OTG_FS_ID_Pin GPIO_PIN_10
#define OTG_FS_ID_GPIO_Port GPIOA
#define RCC_OSC32_IN_Pin GPIO_PIN_14
#define RCC_OSC32_IN_GPIO_Port GPIOC
#define FMC_A1_Pin GPIO_PIN_1
#define FMC_A1_GPIO_Port GPIOF
#define LCD_DISP_Pin GPIO_PIN_12
#define LCD_DISP_GPIO_Port GPIOI
#define LCD_VSYNC_Pin GPIO_PIN_9
#define LCD_VSYNC_GPIO_Port GPIOI
#define DCMI_PWR_EN_Pin GPIO_PIN_13
#define DCMI_PWR_EN_GPIO_Port GPIOH
#define DCMI_D4_Pin GPIO_PIN_14
#define DCMI_D4_GPIO_Port GPIOH
#define ARDUINO_PWM_CS_D10_Pin GPIO_PIN_0
#define ARDUINO_PWM_CS_D10_GPIO_Port GPIOI
#define VCP_TX_Pin GPIO_PIN_9
#define VCP_TX_GPIO_Port GPIOA
#define RCC_OSC32_OUT_Pin GPIO_PIN_15
#define RCC_OSC32_OUT_GPIO_Port GPIOC
#define B_USER_Pin GPIO_PIN_11
#define B_USER_GPIO_Port GPIOI
#define LCD_G6_Pin GPIO_PIN_1
#define LCD_G6_GPIO_Port GPIOK
#define LCD_G7_Pin GPIO_PIN_2
#define LCD_G7_GPIO_Port GPIOK
#define ARDUINO_PWM_D5_Pin GPIO_PIN_8
#define ARDUINO_PWM_D5_GPIO_Port GPIOA
#define OSC_25M_Pin GPIO_PIN_0
#define OSC_25M_GPIO_Port GPIOH
#define FMC_A2_Pin GPIO_PIN_2
#define FMC_A2_GPIO_Port GPIOF
#define LCD_INT_Pin GPIO_PIN_13
#define LCD_INT_GPIO_Port GPIOI
#define LCD_R0_Pin GPIO_PIN_15
#define LCD_R0_GPIO_Port GPIOI
#define LCD_G4_Pin GPIO_PIN_11
#define LCD_G4_GPIO_Port GPIOJ
#define LCD_G5_Pin GPIO_PIN_0
#define LCD_G5_GPIO_Port GPIOK
#define ARDUINO_RX_D0_Pin GPIO_PIN_7
#define ARDUINO_RX_D0_GPIO_Port GPIOC
#define FMC_A3_Pin GPIO_PIN_3
#define FMC_A3_GPIO_Port GPIOF
#define LCD_CLK_Pin GPIO_PIN_14
#define LCD_CLK_GPIO_Port GPIOI
#define ULPI_NXT_Pin GPIO_PIN_4
#define ULPI_NXT_GPIO_Port GPIOH
#define LCD_G1_Pin GPIO_PIN_8
#define LCD_G1_GPIO_Port GPIOJ
#define LCD_G3_Pin GPIO_PIN_10
#define LCD_G3_GPIO_Port GPIOJ
#define FMC_SDCLK_Pin GPIO_PIN_8
#define FMC_SDCLK_GPIO_Port GPIOG
#define ARDUINO_TX_D1_Pin GPIO_PIN_6
#define ARDUINO_TX_D1_GPIO_Port GPIOC
#define FMC_A4_Pin GPIO_PIN_4
#define FMC_A4_GPIO_Port GPIOF
#define FMC_SDNME_Pin GPIO_PIN_5
#define FMC_SDNME_GPIO_Port GPIOH
#define FMC_SDNE0_Pin GPIO_PIN_3
#define FMC_SDNE0_GPIO_Port GPIOH
#define LCD_G0_Pin GPIO_PIN_7
#define LCD_G0_GPIO_Port GPIOJ
#define LCD_G2_Pin GPIO_PIN_9
#define LCD_G2_GPIO_Port GPIOJ
#define ARDUINO_D4_Pin GPIO_PIN_7
#define ARDUINO_D4_GPIO_Port GPIOG
#define ARDUINO_D2_Pin GPIO_PIN_6
#define ARDUINO_D2_GPIO_Port GPIOG
#define ARDUINO_A4_Pin GPIO_PIN_7
#define ARDUINO_A4_GPIO_Port GPIOF
#define ARDUINO_A5_Pin GPIO_PIN_6
#define ARDUINO_A5_GPIO_Port GPIOF
#define FMC_A5_Pin GPIO_PIN_5
#define FMC_A5_GPIO_Port GPIOF
#define NC2_Pin GPIO_PIN_2
#define NC2_GPIO_Port GPIOH
#define LCD_R7_Pin GPIO_PIN_6
#define LCD_R7_GPIO_Port GPIOJ
#define FMC_D1_Pin GPIO_PIN_15
#define FMC_D1_GPIO_Port GPIOD
#define ULPI_D6_Pin GPIO_PIN_13
#define ULPI_D6_GPIO_Port GPIOB
#define FMC_D15_Pin GPIO_PIN_10
#define FMC_D15_GPIO_Port GPIOD
#define ARDUINO_A1_Pin GPIO_PIN_10
#define ARDUINO_A1_GPIO_Port GPIOF
#define ARDUINO_A2_Pin GPIO_PIN_9
#define ARDUINO_A2_GPIO_Port GPIOF
#define ARDUINO_A3_Pin GPIO_PIN_8
#define ARDUINO_A3_GPIO_Port GPIOF
#define FMC_SDCKE0_Pin GPIO_PIN_3
#define FMC_SDCKE0_GPIO_Port GPIOC
#define FMC_D0_Pin GPIO_PIN_14
#define FMC_D0_GPIO_Port GPIOD
#define ULPI_D5_Pin GPIO_PIN_12
#define ULPI_D5_GPIO_Port GPIOB
#define FMC_D14_Pin GPIO_PIN_9
#define FMC_D14_GPIO_Port GPIOD
#define FMC_D13_Pin GPIO_PIN_8
#define FMC_D13_GPIO_Port GPIOD
#define ULPI_STP_Pin GPIO_PIN_0
#define ULPI_STP_GPIO_Port GPIOC
#define RMII_MDC_Pin GPIO_PIN_1
#define RMII_MDC_GPIO_Port GPIOC
#define ULPI_DIR_Pin GPIO_PIN_2
#define ULPI_DIR_GPIO_Port GPIOC
#define FMC_A6_Pin GPIO_PIN_12
#define FMC_A6_GPIO_Port GPIOF
#define FMC_A11_Pin GPIO_PIN_1
#define FMC_A11_GPIO_Port GPIOG
#define FMC_A9_Pin GPIO_PIN_15
#define FMC_A9_GPIO_Port GPIOF
#define LCD_R5_Pin GPIO_PIN_4
#define LCD_R5_GPIO_Port GPIOJ
#define QSPI_D1_Pin GPIO_PIN_12
#define QSPI_D1_GPIO_Port GPIOD
#define QSPI_D3_Pin GPIO_PIN_13
#define QSPI_D3_GPIO_Port GPIOD
#define EXT_RST_Pin GPIO_PIN_3
#define EXT_RST_GPIO_Port GPIOG
#define RMII_RXER_Pin GPIO_PIN_2
#define RMII_RXER_GPIO_Port GPIOG
#define LCD_R6_Pin GPIO_PIN_5
#define LCD_R6_GPIO_Port GPIOJ
#define DCMI_D3_Pin GPIO_PIN_12
#define DCMI_D3_GPIO_Port GPIOH
#define RMII_REF_CLK_Pin GPIO_PIN_1
#define RMII_REF_CLK_GPIO_Port GPIOA
#define ARDUINO_A0_Pin GPIO_PIN_0
#define ARDUINO_A0_GPIO_Port GPIOA
#define DCMI_HSYNC_Pin GPIO_PIN_4
#define DCMI_HSYNC_GPIO_Port GPIOA
#define RMII_RXD0_Pin GPIO_PIN_4
#define RMII_RXD0_GPIO_Port GPIOC
#define FMC_A7_Pin GPIO_PIN_13
#define FMC_A7_GPIO_Port GPIOF
#define FMC_A10_Pin GPIO_PIN_0
#define FMC_A10_GPIO_Port GPIOG
#define LCD_R4_Pin GPIO_PIN_3
#define LCD_R4_GPIO_Port GPIOJ
#define FMC_D5_Pin GPIO_PIN_8
#define FMC_D5_GPIO_Port GPIOE
#define QSPI_D0_Pin GPIO_PIN_11
#define QSPI_D0_GPIO_Port GPIOD
#define FMC_BA1_Pin GPIO_PIN_5
#define FMC_BA1_GPIO_Port GPIOG
#define FMC_BA0_Pin GPIO_PIN_4
#define FMC_BA0_GPIO_Port GPIOG
#define LCD_SCL_Pin GPIO_PIN_7
#define LCD_SCL_GPIO_Port GPIOH
#define DCMI_D0_Pin GPIO_PIN_9
#define DCMI_D0_GPIO_Port GPIOH
#define DCMI_D2_Pin GPIO_PIN_11
#define DCMI_D2_GPIO_Port GPIOH
#define RMII_MDIO_Pin GPIO_PIN_2
#define RMII_MDIO_GPIO_Port GPIOA
#define ULPI_CLK_Pin GPIO_PIN_5
#define ULPI_CLK_GPIO_Port GPIOA
#define RMII_RXD1_Pin GPIO_PIN_5
#define RMII_RXD1_GPIO_Port GPIOC
#define FMC_A8_Pin GPIO_PIN_14
#define FMC_A8_GPIO_Port GPIOF
#define LCD_R3_Pin GPIO_PIN_2
#define LCD_R3_GPIO_Port GPIOJ
#define FMC_SDNRAS_Pin GPIO_PIN_11
#define FMC_SDNRAS_GPIO_Port GPIOF
#define FMC_D6_Pin GPIO_PIN_9
#define FMC_D6_GPIO_Port GPIOE
#define FMC_D8_Pin GPIO_PIN_11
#define FMC_D8_GPIO_Port GPIOE
#define FMC_D11_Pin GPIO_PIN_14
#define FMC_D11_GPIO_Port GPIOE
#define ULPI_D3_Pin GPIO_PIN_10
#define ULPI_D3_GPIO_Port GPIOB
#define ARDUINO_PWM_D6_Pin GPIO_PIN_6
#define ARDUINO_PWM_D6_GPIO_Port GPIOH
#define LCD_SDA_Pin GPIO_PIN_8
#define LCD_SDA_GPIO_Port GPIOH
#define DCMI_D1_Pin GPIO_PIN_10
#define DCMI_D1_GPIO_Port GPIOH
#define ULPI_D0_Pin GPIO_PIN_3
#define ULPI_D0_GPIO_Port GPIOA
#define RMII_CRS_DV_Pin GPIO_PIN_7
#define RMII_CRS_DV_GPIO_Port GPIOA
#define ULPI_D2_Pin GPIO_PIN_1
#define ULPI_D2_GPIO_Port GPIOB
#define ULPI_D1_Pin GPIO_PIN_0
#define ULPI_D1_GPIO_Port GPIOB
#define LCD_R1_Pin GPIO_PIN_0
#define LCD_R1_GPIO_Port GPIOJ
#define LCD_R2_Pin GPIO_PIN_1
#define LCD_R2_GPIO_Port GPIOJ
#define FMC_D4_Pin GPIO_PIN_7
#define FMC_D4_GPIO_Port GPIOE
#define FMC_D7_Pin GPIO_PIN_10
#define FMC_D7_GPIO_Port GPIOE
#define FMC_D9_Pin GPIO_PIN_12
#define FMC_D9_GPIO_Port GPIOE
#define FMC_D12_Pin GPIO_PIN_15
#define FMC_D12_GPIO_Port GPIOE
#define FMC_D10_Pin GPIO_PIN_13
#define FMC_D10_GPIO_Port GPIOE
#define ULPI_D4_Pin GPIO_PIN_11
#define ULPI_D4_GPIO_Port GPIOB
#define ARDUINO_MISO_D12_Pin GPIO_PIN_14
#define ARDUINO_MISO_D12_GPIO_Port GPIOB
#define ARDUINO_MOSI_PWM_D11_Pin GPIO_PIN_15
#define ARDUINO_MOSI_PWM_D11_GPIO_Port GPIOB

/* ########################## Assert Selection ############################## */
/**
  * @brief Uncomment the line below to expanse the "assert_param" macro in the 
  *        HAL drivers code
  */
/* #define USE_FULL_ASSERT    1U */

/* USER CODE BEGIN Private defines */

/* USER CODE END Private defines */

#ifdef __cplusplus
 extern "C" {
#endif
void _Error_Handler(char *, int);

#define Error_Handler() _Error_Handler(__FILE__, __LINE__)
#ifdef __cplusplus
}
#endif

#endif /* __MAIN_H__ */

/************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/

[Stefan F. (Gast)]

Sieht so aus, als hättest du in Cube MX den Pin mit der LED nicht 
konfiguriert und beschriftet.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Du kannst das Board mit deiner IDE auch "ohne Firmware" programmieren.
> Sicher findest du irgendwo im Netz ein minimales Led-Blinker Beispiel
> für deinen STM.

Es blinkt doch aber... Mir gehts auch gar nicht ums blinken. Die 
Programme die ich flashe, laufen ja alle soweit. Wenn sie denn starten. 
Und wie ich sie zum starten bringe habe ich ja nun oft genug 
beschrieben.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Sieht so aus, als hättest du in Cube MX den Pin mit der LED nicht
> konfiguriert und beschriftet.

Ja ich hab einfach ein neues File erstellen lassen und nichts dran 
geändert, ausser den weiter oben genannten Änderungen an den 
Clockeinstellungen

[Harry L. (mysth)]

Da sind doch alle Pin&Port-Definitionen.
Welche davon zu deiner LED gehört lässt sich im Schaltplan ablesen.
Für jeen definierten Pin gibt es ein Paar aus Pin- und Port-Definition 
und die Zuordnung der Namen zu den Pins siehst du im CueMX

Stefanus F. schrieb:
> Wenn alle Stricke reißen würde ich in Erwägung ziehen, dass deine HAL
> Library fehlerhaft ist.

...ja, nee...is klar.
ich bezweifel ja nicht, daß in HAL noch Fehler verborgen sind, aber ganz 
sicher nicht in diesen Trivial-Funktionen.

M.M.n passen die Parameter von HAL_GPIO_WritePin einfach nicht.
Das wäre auch ohne HAL nicht anders.

[Johannes S. (Gast)]

Port I1 ist richtig für die LED, den tickert auch mein blinky.
Ich verstehe den Aufriss mit den Takten und CubeMX Codes auch nicht, das 
gleiche Programm startet bei mir sofort und bei JT erst nach Zugriffen 
vom STLink. Also muss doch eher irgendwas mit dem STLink oder 
irgendeiner Bootconfig faul sein.

[J. T. (chaoskind)]

Harry L. schrieb:
> Welche davon zu deiner LED gehört lässt sich im Schaltplan ablesen.

Laut Schaltplan ist es PI1 siehe ich meine seite 19 wars, in dem weiter 
oben von mir angehängten PDF.

[Johannes S. (Gast)]

Über den virtuellen Comport gibt mein Programm beim Start noch ein Hello 
aus, 9600 oder 115200 bps.

[J. T. (chaoskind)]

In CubeMX gucke ich unter "Configuration" in "System" in "GPIO", dort 
taucht PI1 nirgendwo auf... Also liegt der Fehler irgendwo in Cube, dass 
der GPIO einfach nicht konfiguriert ist, somit ist erklärt wieso mein 
blinky nicht blinkt, das andere aber schon.

Aber um es nochmal zu betonen, das blinken ist überhaupt nicht das 
Problem. Mein erstes gepostetes Program malt auch hübscheste Muster aufs 
LCD, nur ist der Startvorgang halt minimal unkomfortabel.

[J. T. (chaoskind)]

Johannes S. schrieb:
> Über den virtuellen Comport gibt mein Programm beim Start noch ein Hello
> aus, 9600 oder 115200 bps.

Dein Hello macht mein DISCO_F746 zum Lügner :D

Aber auf 9600 kann ich es problemlos empfangen.

[Johannes S. (Gast)]

ja, ist aber nur ein konstanter Text, ich könnte dein Board auch zum 
Xeon machen :)
Die Led an PI1 ist im Cube für das Board nicht konfiguriert, da liegt 
Arduino SPI drauf und wird nicht als Output konfiguriert, müsste man 
also erst anders definieren. Aber das behebt ja nicht das eigentliche 
Problem...

[J. T. (chaoskind)]

Johannes S. schrieb:
> Aber das behebt ja nicht das eigentliche
> Problem...

Mein Reden, mein Reden

[Stefan F. (Gast)]

Johannes S. schrieb:
> Ich verstehe den Aufriss mit den Takten und CubeMX Codes auch nicht

Ich habe auch nicht damit gerechnet, dass es so schwierig sein wird, ein 
simples Blinky ans laufen zu bringen.

Sinn der Aktion war eigentlich nur, ein möglichst einfaches Programm 
zu haben, das ohne externen Takt auskommt, um zu prüfen, ob der 
externe Oszillator ein Problem hat.

Ich habe inzwischen den Faden verloren. Tritt das Start-Problem mit 
internem Takt auch auf?

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Ich habe inzwischen den Faden verloren. Tritt das Start-Problem mit
> internem Takt auch auf?

Ja tut es. Nochmal kurz das Startproblem geschildert: Ich stecke Power 
in den USB-link stecker, nix tut sich auch nicht nach resetdrücken. 
Flash auslesen. Programm läuft. Reset drücken läuft weiterhin. Strom 
abziehen und wieder anstecken, geht nicht mehr, ich muss wieder den 
flash auslesen damit es losläuft.
Wenn ich aber umjumpere das ich über USB_FS versorge, dann läuft es erst 
auch nicht. Dann stecke ich zusätzlich den USB-link ein, versorge weiter 
über uSB_FS und lese den Flash aus, drücke reset und dann läuft es. Nun 
ziehe ich USB_Link ab, versorgt wird weiter über UBB_FS und es läuft 
weiter. Ich ziehe USB_FS ab, und da nun keine Spannungsversorgung mehr 
da ist, geht es erwartungsgemäß aus. Nun stecke ich USB_FS wieder ein 
und es läuft.
Jumpere ich zurückj auf USB_Link versorgung, geht die ganze Sache wieder 
von vorne los.

Ich bin mir langsam recht sicher, der Fehler dürfte nicht im Takt 
sitzen.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Sinn der Aktion war eigentlich nur, ein möglichst einfaches Programm
> zu haben, das ohne externen Takt auskommt, um zu prüfen, ob der
> externe Oszillator ein Problem hat.

Sollte aber nicht eigentlich gar nichts laufen, wenn der externe ein 
Problem hat?

[m.n. (Gast)]

J. T. schrieb:
> Sollte aber nicht eigentlich gar nichts laufen, wenn der externe ein
> Problem hat?

Nein, wenn HSE aussetzt ist HSI aktiv.
Ihr dreht an den völlig falsche Schrauben!

[Stefan F. (Gast)]

J. T. schrieb:
> Stefanus F. schrieb:
>> Sinn der Aktion war eigentlich nur, ein möglichst einfaches Programm
>> zu haben, das ohne externen Takt auskommt, um zu prüfen, ob der
>> externe Oszillator ein Problem hat.
>
> Sollte aber nicht eigentlich gar nichts laufen, wenn der externe ein
> Problem hat?

Meistens ja. Ich habe aber einmal erlebt, dass ein Quarz Oszillator (am 
AVR) nur dann anlief, wenn ich ein andere Netzteil benutzte. 
Letztendlich lag die Ursache bei falsch bestückten Lastkapazitäten.

Wo sind wir jetzt?

Am externen Takt liegt es nicht.
Am Programm liegt es nicht.
Zeit, die Hardware zu untersuchen.
Ein Druck auf den Reste-Knopf bringt nichts, habe ich das richtig in 
Erinnerung?

Prüfe mal, wie hoch die Versorgungsspannung des µC und die Spannung am 
Reset Pin ist, während das Problem auftritt.

[m.n. (Gast)]

Stefanus F. schrieb:
> Prüfe mal, wie hoch die Versorgungsspannung des µC und die Spannung am
> Reset Pin ist, während das Problem auftritt.

Vielleicht noch die Kondensatoren tauschen? :-(
Solche Probleme gibt es, wenn das System keinen ordentlichen Reset 
erhält. Ob nun das Programm im RAM liegt, die Position der Vektortabelle 
nicht richtig eingetragen ist oder sich ein BOOT-Modus vordrängelt.
Da muß man suchen und nicht bei Banalitäten!

[Johannes S. (Gast)]

very strange.
Nochmal von meinem Board das sofort anläuft, egal woher die Spannung 
kommt wenn der Jumper richtig steht:

STLink Version: V2.J29.M18
CPU ist Rev. Z, wird im STLink Util rechts oben angezeigt.
nach dem connect zeigt das STLink Util:

13:19:41 : ST-LINK SN : 0675FF544949847067074536
13:19:41 : ST-LINK Firmware version : V2J29M18
13:19:41 : Connected via SWD.
13:19:41 : SWD Frequency = 4,0 MHz.
13:19:41 : Connection mode : Normal.
13:19:41 : Debug in Low Power mode enabled.
13:19:41 : Device ID:0x449 
13:19:41 : Device flash Size : 1MBytes
13:19:41 : Device family :STM32F74x/F75x

Andere Hardware ist sicher nicht angeschlossen?
Das Boot Option Byte ADD0 steht sicher auf 0x0080 (start adresse 
0x00200000).
Zeigt das STLink nach dem anstecken ab 0x00200000 plausible Werte?

Klemmt vielleicht einfach die Reset Taste? Wenn ich die gedrückt halte 
und USB anschliesse läuft das Programm auch nicht an, allerdings nach 
loslassen und nochmal drücken dann doch.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Wo sind wir jetzt?
>

Nochmal kurz das Startproblem geschildert: Ich stecke Power
in den USB-link stecker, nix tut sich auch nicht nach resetdrücken.
Flash auslesen. Programm läuft. Reset drücken läuft weiterhin. Strom
abziehen und wieder anstecken, geht nicht mehr, ich muss wieder den
flash auslesen damit es losläuft.
Wenn ich aber umjumpere das ich über USB_FS versorge, dann läuft es erst
auch nicht. Dann stecke ich zusätzlich den USB-link ein, versorge weiter
über uSB_FS und lese den Flash aus, drücke reset und dann läuft es. Nun
ziehe ich USB_Link ab, versorgt wird weiter über UBB_FS und es läuft
weiter. Ich ziehe USB_FS ab, und da nun keine Spannungsversorgung mehr
da ist, geht es erwartungsgemäß aus. Nun stecke ich USB_FS wieder ein
und es läuft.
Jumpere ich zurückj auf USB_Link versorgung, geht die ganze Sache wieder
von vorne los.

> Am externen Takt liegt es nicht.
Vermutlich nicht, richtig

> Am Programm liegt es nicht.
Soweit bekomme ich jedes binary zum laufen.

> Zeit, die Hardware zu untersuchen.
> Ein Druck auf den Reste-Knopf bringt nichts, habe ich das richtig in
> Erinnerung?

Das hängt davon ab, in welchem Zustand meines "Kabelsteckzyklus" ich 
bin. Wenn ich den Flash einmal ausgelesen hab, läuft es ja alles ganz 
normal, als wäre nie was gewesen. Auch wenn ich auf USB_FS umjumper 
läuft es dann ja völlig normal. Von daher würde ich den Fehler auch 
irgendwo in der Gegend vom ST-Link suchen. Aber da hab ich halt so 
garkeine Ahnung von..

Stefanus F. schrieb:
> Prüfe mal, wie hoch die Versorgungsspannung des µC
 ca3.2V
> und die Spannung am
> Reset Pin ist, während das Problem auftritt.
0V

m.n. schrieb:
> Vielleicht noch die Kondensatoren tauschen? :-(

Das würd ich nach Möglichkeit gern vermeiden

m.n. schrieb:
> Solche Probleme gibt es, wenn das System keinen ordentlichen Reset
> erhält. Ob nun das Programm im RAM liegt, die Position der Vektortabelle
> nicht richtig eingetragen ist oder sich ein BOOT-Modus vordrängelt.
> Da muß man suchen und nicht bei Banalitäten!

Ich zweifel daran, dass es an der Versorgung liegt, die sieht recht 
stabil aus. Ich vermute wie gesagt irgendwas in der Richtung vom ST-Link

[J. T. (chaoskind)]

J. T. schrieb:
>> und die Spannung am
>> Reset Pin ist, während das Problem auftritt.
> 0V

P.S.

nachdem Flashauslesen wenns dann läuft, liegen 3,3V über dem 
Resetbutton, die dann bei Tastendruck auch einbrechen.

[Johannes S. (Gast)]

am Reset Button sind ein einfaches RC mit R39 / C25, da liegt nach USB 
ein sofort 3,3 V an. Dieses Signal ist auch gut am Arduino Connector 
zugänglich. Läuft das Program los wenn der NRST mit Jumper Wire auf 3V3 
gelegt wird?
Vielleicht hat der 3V3 Regler auch ein Problem?
Die Stromaufnahme ist bei mir 300 mA @ 5V (über die ext. Versorgung 
angeschlossen) und wenn mein blinky läuft.

[J. T. (chaoskind)]

Johannes S. schrieb:
> Dieses Signal ist auch gut am Arduino Connector
> zugänglich. Läuft das Program los wenn der NRST mit Jumper Wire auf 3V3
> gelegt wird?

Am Arduino Connector liegen die 3.3V auch an, auch schon wenn das 
Programm noch nicht läuft, am Resetbutton dann aber noch nicht. Aber 
wenn ich die dann mit nrst lege, läuft es auch nicht los.

[J. T. (chaoskind)]

Johannes? kannst du mal testen, was die BiColor LED am USB-Link bei dir 
macht, wenn du über USB-FS versorgst? Bei mir blinkt sie rot, ca 1sek an 
1sek aus.

[Johannes S. (Gast)]

J. T. schrieb:
> Bei mir blinkt sie rot, ca 1sek an
> 1sek aus.

hier genauso.

J. T. schrieb:
> auch schon wenn das
> Programm noch nicht läuft, am Resetbutton dann aber noch nicht.

das ist merkwürdig, lt. Schaltplan ist das doch das gleiche Signal, NRST 
wird durch den Taster erzeugt.

[J. T. (chaoskind)]

Johannes S. schrieb:
> Andere Hardware ist sicher nicht angeschlossen?
Ab und an das Oszi zum messen, und am Rechner steckt ne Maus... Sonst 
nix.

> Das Boot Option Byte ADD0 steht sicher auf 0x0080 (start adresse
> 0x00200000).
> Zeigt das STLink nach dem anstecken ab 0x00200000 plausible Werte?
>
siehe Anhänge

> Klemmt vielleicht einfach die Reset Taste? Wenn ich die gedrückt halte
> und USB anschliesse läuft das Programm auch nicht an, allerdings nach
> loslassen und nochmal drücken dann doch.

Ziemlich sicher nicht, dagegen spricht dass es absolut wiederholbar ist. 
Das wäre doch sehr verwunderlich, wenn die klemmende Taste sich merken 
würde wann welche Spannung angelegt wurde.

[J. T. (chaoskind)]

J. T. schrieb:
> Am Arduino Connector liegen die 3.3V auch an, auch schon wenn das
> Programm noch nicht läuft, am Resetbutton dann aber noch nicht. Aber
> wenn ich die dann mit nrst lege, läuft es auch nicht los.

Hier hab ich mich missverständlich ausgedrückt. Am Arduino Connector 
liegen die 3.3V nur am 3.3V Port. Am NRST liegen 0V wenn es noch nicht 
läuft. NRST ist immer gleich mit dem direkt am Resetbutton gemessenen 
Wert.
Wenns denn erst mal läuft gehen NRST und am Resetbutton gemssen 
gleichzeotig auf 0 beim messen.

[Johannes S. (Gast)]

aber meine STLink Version ist deutlich neuer V2J29 zu V2J21. STLink ist 
V4.2, das müsste ziemlich aktuell sein. Lade das mal von ST und mache 
dann nochmal das STLink Firmwareupdate.

Und das am Taster noch 0V anliegen ist merkwürdig. Wenn das Programm 
nicht läuft, per Draht NRST mal auf GND und dann auf 3V3 legen?

[J. T. (chaoskind)]

Johannes S. schrieb:
> Und das am Taster noch 0V anliegen ist merkwürdig. Wenn das Programm
> nicht läuft, per Draht NRST mal auf GND und dann auf 3V3 legen?

Wurde auch schon vorgeschlagen, brachte aber nichts.

[Johannes S. (Gast)]

NRST muss im Betrieb auf 3V3 liegen. Nur beim Einschalten wird es durch 
C25 (über dem Taster) kurz auf GND gezogen und dann über R39 auf 3V3. 
Sehr billig bei so einem HiTech Board, aber vielleicht hat der µC eine 
Reetschaltung eingebaut, habe ich nicht nachgesehen.

[J. T. (chaoskind)]

Johannes S. schrieb:
> aber meine STLink Version ist deutlich neuer V2J29 zu V2J21. STLink ist
> V4.2, das müsste ziemlich aktuell sein. Lade das mal von ST und mache
> dann nochmal das STLink Firmwareupdate.

Bin jetzt auf V2j32 und es blinkt wieder direkt beim Anstecken los!!!!!

Ich verstehe nur nicht, wo das Problem überhaupt herkam. Es ging ja mal, 
dann ging es ohne Änderung von einen Tag auf den anderen nicht mehr....


Juuuchuuu ich kann auch wieder über die PowerBank versorgen.Also über 
alle Stecker!

Vielen herzlichen Dank an alle mithelfenden, das war irgendwie ne 
schwere Geburt, für eineam Ende so einfach Lösung :D

[Johannes S. (Gast)]

Gückwunsch, ein selten blödes Problem...
Aber so lernt man die Interna seiner Hardware kennen :)

[Stefan F. (Gast)]

m.n. schrieb:
> Stefanus F. schrieb:
>> Prüfe mal, wie hoch die Versorgungsspannung des µC und die Spannung am
>> Reset Pin ist, während das Problem auftritt.
>
> Vielleicht noch die Kondensatoren tauschen? :-(
> Solche Probleme gibt es, wenn das System keinen ordentlichen Reset
> erhält.

Ich nehme allerdings an, dass ein Druck auf den Reset Knopf als 
"ordentlicher Reset" durch geht. Und der funktioniert jedenfalls auch 
nicht.

Deswegen komme ich auf so krude Sachen.

[Stefan F. (Gast)]

Johannes S. schrieb:
> NRST muss im Betrieb auf 3V3 liegen.

Richtig. Die gemessenen 0V sind ein wichtiger Hinweis. Die Fehlerursache 
hängt demnach mit Sicherheit direkt am NRST Pin (wurde inzwischen auch 
bestätigt).

> Sehr billig bei so einem HiTech Board, aber vielleicht hat der µC eine
> Reetschaltung eingebaut, habe ich nicht nachgesehen.

Hat er. Der NRST Pin ist sowohl Eingang als auch Ausgang. Der 
Mikrocontroller erzeugt intern aber nur einen kurzen Low-Impuls. Er hält 
die Leitung nicht auf Low (es sei denn, er ist defekt).

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Ich nehme allerdings an, dass ein Druck auf den Reset Knopf als
> "ordentlicher Reset" durch geht. Und der funktioniert jedenfalls auch
> nicht.

Aber halt nur, wenn auf der einen Seite vom Knopf auch 3.3V anliegen, 
die dann auf Gnd gezogen werden können. Und aus mir völlig rätselhaften 
Gründen, wurden die halt erst nach dem Flash lesen angelegt. Aber auch 
nur bei Versorgung über den USB_STlink. Und nach nem Update vom ST-Link 
läuft nun wieder alles wie es sich gehört.

[Stefan F. (Gast)]

Offensichtlich hat die fehlerhafte Firmware des ST-Link den NRST Pin 
herunter gezogen und dort festgehalten.

[J. T. (chaoskind)]

Stefanus F. schrieb:
> Offensichtlich hat die fehlerhafte Firmware des ST-Link den NRST Pin
> herunter gezogen und dort festgehalten.

Ja das ist offensichtlich und somit eigentlich nicht erwähnenswert. Was 
aber nicht offensichtlich ist, und meinen gequälten Verstand weiter 
malträtiert, ist die Frage nach dem warum. Die ursprüngliche 
Konfiguration lief ja mal. Und dann trat das Problem ohne jegliche 
Änderung auf. Abends das funktionierende Board ausgemacht und am 
nächsten Tag wieder angesteckt. Startet nicht. Ich dachte mir "nanu 
Flash verloren?!?! Hmm ma auslesen, oh nu läufts ja". Und so nahm das 
Drama dann seinen Lauf