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
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.
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
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.
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.
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.
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?
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
@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. 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.
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/
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?
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.
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.
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
" 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....
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.
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?
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. 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
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.
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. 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.
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.
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?
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.
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...
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..
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:
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:
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.
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.
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.
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.
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. 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
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 ;-)
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.
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?
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.
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
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.
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
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.
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 =(
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:
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.
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?
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
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.
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?
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.
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.
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.
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...
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.
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.
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.
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?
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.
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.
1
HAL_GPIO_WritePin(GPIOI,0,GPIO_PIN_SET);
2
HAL_Delay(300);
3
HAL_GPIO_WritePin(GPIOI,0,GPIO_PIN_RESET);
4
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:
1
voidSVC_Handler(void)
2
{
3
/* USER CODE BEGIN SVCall_IRQn 0 */
4
5
/* USER CODE END SVCall_IRQn 0 */
6
// HAL_SVCall_IRQHandler
7
/* USER CODE BEGIN SVCall_IRQn 1 */
8
9
/* USER CODE END SVCall_IRQn 1 */
10
}
HAL_SVCall_IRQHandler hab ich wieder auskommentiert, weil Cube das ohne
Semikolon und sonstigen Schnickschnack den der Programmierer gern sieht,
erzeugt.
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.
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.
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...
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.
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)
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.
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.
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?
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.
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:
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.
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:
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.
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
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.
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.
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.
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.
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.
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...
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?
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.
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?
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!
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.
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!
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:
1
13:19:41 : ST-LINK SN : 0675FF544949847067074536
2
13:19:41 : ST-LINK Firmware version : V2J29M18
3
13:19:41 : Connected via SWD.
4
13:19:41 : SWD Frequency = 4,0 MHz.
5
13:19:41 : Connection mode : Normal.
6
13:19:41 : Debug in Low Power mode enabled.
7
13:19:41 : Device ID:0x449
8
13:19:41 : Device flash Size : 1MBytes
9
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.
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. 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.
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.
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.
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.
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.
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. 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.
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?
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.
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.
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
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.
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).
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.
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
Thread beobachten
Seitenaufteilung abschalten