Hallo zusammen,
nach Jahren bin ich das erste Mal wieder hier.
Ich versuche ein Bluepill auf möglichst niedrige Stromaufnahme zu
drücken.
Zunächst habe ich den LDO und den Widerstand für die Power-LED
herausgelötet. Ich speise das Board über den 3.3V-Pin ein.
Das Board habe ich seit ca. 1 Jahr. Auf dem STM32F103C8T6 steht 9901D 93
MYS 530. Im Thema über die Fälschungen habe ich gelesen das dies keine
Fälschung sein soll.
Wenn das Board in den Tiefschlaf geht (Stop Mode), messe ich immer noch
6.4mA. Laut Datenblatt sollte der Strom im unteren uA-Bereich liegen.
Ich habe schon so Einiges versucht.
-Minimales Blink-Programm mit Arduino.
-Minimales Blink-Programm mit Std-Bibliothek in Eclipse.
-Beides direkt geflasht, ohne USB-Bootloader.
-Beides mit stm32duino-Bootloader (USB).
-Beides mit HID-Bootloader (USB).
-Alle möglichen CLK disabled oder auch nicht.
-Ein Programm das sofort in den Standby geht.
-Mit den Cube-Bibliotheken schaffe ich das nicht, Programm bootet nicht.
Ist evtl. noch ein versteckter Verbraucher auf dem Board, etwa ein
Kondensator mit hohem Leckstrom? Ich müsste Alles herunter löten, um das
heraus zu bekommen.
Eine Frage ist, ob hier schon Jemand diese Erfahrungen mit dem Board
gemacht hat?
Hier ist ein Auszug aus dem Blink-Programm. Das läuft natürlich in einer
Schleife. Den Gpio-Pin initialisiere ich nach dem Aufwachen wieder.
Jörg W. schrieb:> Wenn das Board in den Tiefschlaf geht (Stop Mode), messe ich immer noch> 6.4mA. Laut Datenblatt sollte der Strom im unteren uA-Bereich liegen.
Daraus würde ich den Schluß ziehen, dass er wohl nicht im Tiefschlaf
ist.
> Ist evtl. noch ein versteckter Verbraucher auf dem Board, etwa ein> Kondensator mit hohem Leckstrom?
Ein Kondensator mit derart hohem Leckstrom wäre wohl kein Kondensator
mehr, sondern schlicht kaputt.
Überhaupt: Es ist ja doch ziemlich übersichtlich, was da so auf so'nem
Bluepill-Board drauf ist. Außer dem Regler sieht nicht's davon nach
einer größeren Stromsenke aus. Aber klar: wenn man Pullup-Widerstände an
32 Ausgängen nach Masse zieht, können da schon einige mA zusammenkommen.
Also: Ich würde meine Aufmerksamkeit auf zwei Sachen richten:
1. Was ist mit den Pins, die dein Programm NICHT benutzt? Wie sind die
initialisiert und was hängt jeweils an äußerer Beschaltung dran?
2. Wurde wirklich der Tiefschlaf-Zustand erreicht?
Ich müsste Alles herunter löten, um das
> heraus zu bekommen.> Eine Frage ist, ob hier schon Jemand diese Erfahrungen mit dem Board> gemacht hat?>> Hier ist ein Auszug aus dem Blink-Programm. Das läuft natürlich in einer> Schleife. Den Gpio-Pin initialisiere ich nach dem Aufwachen wieder.>
Stefan ⛄ F. schrieb:> Jörg W. schrieb:>> Ist evtl. noch ein versteckter Verbraucher auf dem Board>> Der Spannungsregler
@Jörg W.:
Nimms nicht persönlich, er hat es nicht so mit dem Lesen von Postings,
wie Du auch in anderen Threads feststellen kannst.
Wie misst Du denn die Stromaufnahme?
Und wie sieht das:
"-Ein Programm das sofort in den Standby geht."
aus?
Also, die LED blinkt für 0.2 Sekunden auf. Der Stromverbrauch ist da
kurzzeitig 29mA (CPU läuft mit 72Mhz). Dann ist die LED für 10 Sekunden
aus. Der Stromverbrauch ist dann 6.4 mA. Wenn der Stop-Mode nicht
erreicht wird, würde die LED kontinuierlich leuchten, weil sie ja durch
die Schleife sofort wieder eingeschaltet würde.
An den Pins hängt sonst nichst dran. Nur das was im Schaltplan zu sehen
ist. Der 5V-Bereich ist abgekoppelt, durch den fehlenden
Spannungsregler. Den USB-Stecker ziehe ich auch wieder heraus und speise
nur über den 3.3V-Pin ein.
GPIO_Mode_IPU ist In PullUp. Ich habe auch Flaoting und Pull Down
ausprobiert. Der Unterschied ist 0.1mA.
John, nein ich nehme so schnell nichts persönlich.
Ich messe mit meinem billigen Multimeter. Das zeigt allerdings, wenn ich
ein ebenfalls modifizierte Nano V3 in den Tiefschlaf versetze 7uA an.
Das minimale Programm sieht so aus:
SystemInit
GpioInit (LED)
Led Aus
PWR_EnterSTANDBYMode();
6.4mA
Danach wacht er natürlich nicht mehr auf.
So, nachdem ich lange auf eine Lieferung von Reichelt gewartet habe,
melde ich mich wieder. Ich habe zwei STM32L431CBT6 und einige andere
Teile bestellt. DHL hat aber die erste Lieferung beschädigt und Reichelt
hat auch bei der Ersatzlieferung viel Zeit verstreichen lassen. Das
kenne ich eigentlich nicht so von Reichelt.
Nun aber habe ich die Teile und inzwischen auch den STM32F103 durch den
STM32L431 ausgetauscht.
Vorher hatte ich festgestellt, das im spannungslosen Zustand der
Widerstand zwischen 3.3V und GND etwa 528 Ohm waren. Das erklärt die
Stromaufnahme im Stop Modus! Nachdem ich den STM32F103 entfernt habe
(die rüde Methode mit Cuttermesser um die Pads zu schonen), war der
Widerstand zwischen 3.3V und GND > 5 MOhm! Ich denke die STM32F103 auf
beiden Bluepill die ich habe sind Fake.
Nun mit dem STM32L431 ist der Widerstand auch im MOhm-Bereich.
Ich habe auch ein HAL-Beispiel am laufen, dabei sinkt die Stromaufnahme
im Stop2 auf 1,8uA! Das ist genau das, was man laut Datenblatt erwarten
kann.
Für diejenigen, die nicht noch einmal oben lesen wollen: Ich habe den
Widerstand für die PWR-LED herausgelötet und auch den Spannungsregler.
Falls jemand das mit seinem Bluepill vergleichen möchte.
Jörg W. schrieb:> beiden Bluepill die ich habe sind Fake.
Nö, die hats einfach durchgeschossen. Die 32Bit-Boliden sind in der
Regel deutlich empfindlicher gegen ESD und Überspannung als die robusten
8Bitter (8051, AVR).
Wurden sie denn in einer ESD-Verpackung geliefert und hast Du bei
Inbetriebnahme auch eine ESD-Unterlage und ein ESD-Armband benutzt?
Was hast du für einen Lötkolben?
Meine Weller ist/war ein richtiger IC Killer.
Die Spitze ist normal nicht geerdet. Die kapazitiven Kopplung über den
Trafo reicht aus um die Pins zu schädigen. Da geht dann der
Stromverbrauch in die Höhe. Zwar habe ich die Größenordnung die du da
beschreibst noch nicht gesehen aber hunderte µA sinds eigentlich immer.
Harte Erde am Lötkolben macht das besser - dafür muss man sich halt über
andere Dinge Gedanken machen (z.B. wie bekomme ich die Ladung vor dem
Löten vom Board. sonst bringst du den IC durch ESD um...)
73
Ich habe zwar eine billige Lötstation von Pollin, aber bislang habe ich
wissentlich noch nichts damit zerstört. Meine beiden Bluepill hatten
genau die gleiche Stromaufnahme im Stop. Beide habe ich vor 2-3 Jahren
gekauft. Einer davon lag die ganze Zeit in dem originalen verschweissten
ESD-Tütchen.
Aber, ich lasse das gelten, das die Teile beim Einlöten der Stiftleiste
eventuell beschädigt wurden. In Zukunft werde ich dann vorsichtiger
sein. Immerhin benutze ich beruflich auch ESD-Schutz, wenn ich sensible
Teile handhabe (z.B. IGBTs von MW-Frequenzumrichtern).
Nun, nachdem ich den Prozessor getauscht habe, ist ja Alles gut. Ich
habe, um Platz zum Löten zu haben, die Stiftleisten und den 8 MHz
Kristall vorher entfernt und dann den neuen STM32L431 aufgelötet. Neue
Stiftleisten und den Kristall habe ich dann auch wieder aufgelötet.
Ich werde ja sehen, wenn ich mein Projekt nun Schritt für Schritt auf
den STM32L431 portiere, wie es dann aussieht. Mein Projekt habe ich mit
der Std-Lib gemacht und muss jetzt Alles nach HAL portieren.
Jörg W. schrieb:> Ich> habe, um Platz zum Löten zu haben, die Stiftleisten und den 8 MHz> Kristall vorher entfernt und dann den neuen STM32L431 aufgelötet.
Wie hast du das denn hingekriegt? Mit Heißluft?
Jörg W. schrieb:> Mein Projekt habe ich mit> der Std-Lib gemacht und muss jetzt Alles nach HAL portieren
Na da hält sich mein Mitleid aber in Grenzen. Warum machst du dann den
gleichen Fehler nochmal?
temp schrieb:> Na da hält sich mein Mitleid aber in Grenzen. Warum machst du dann den> gleichen Fehler nochmal?
Wird es nicht langsam Zeit wieder Zeit für komplett neue noch viel
bessere und glücklich machendere Bilbiothek? :-)
Vor zehn Jahren machten wir ein industrielles Firmenprojekt mit dem F103
wo Tiefschlaf notwendig war. Das funktionierte einwandfrei mit Atollic
TS als Toolchain. Die RTC lief mit einer BR1225 mindestens 5 Jahre.
Schlafstrom war um 1uA. Soweit ich mich erinnern kann machte die
Einstellung der Schlafbedingungen keine großen Schwierigkeiten. Man muß
nur aufpassen, daß die Pins und externe HW so konzipiert wird, daß
nichts übersehen wurde und im Schlafbetrieb kein unnötiger Querstrom
fließen kann. Das muß man von Anfang an akribisch durchplanen. Auch darf
man nicht vergessen stromfressende Peripherien wie den ADC u.a.
abzuschalten. Auch Takt Ressourcen genau verstehen und konfigurieren.
Ahnungslos schrieb:> Jörg W. schrieb:>> Ich>> habe, um Platz zum Löten zu haben, die Stiftleisten und den 8 MHz>> Kristall vorher entfernt und dann den neuen STM32L431 aufgelötet.>> Wie hast du das denn hingekriegt? Mit Heißluft?
Nein, von den Stiftleisten habe ich den Kunstoff entfernt und dann die
Stifte einzeln heraus gelötet. Das ging ziemlich schnell. Heissluft
wolte ich nicht benutzen. So haben die Pads das überlebt und ich habe
keine anderen Bauteile verbrannt. Die Lötpads sind ziemlich hin, wenn
man zu lange daran herumlötet.Ich musste dann natürlich neue
Stiftleisten einlöten. Den alten Prozessor habe herausgeschnitten und
die abgeschnittenen Beinchen mit der Lötspitze schnell entfernt,
anschliessend mit Sauglitze überschüssiges Lötzinn entfernt.
Und den neuen Prozessor habe ich erst an ein bis zwei Beinchen angelötet
und dann mit einem Okkular den korrekten Sitz überprüft. Dann habe ich
alle Beinchen mit etwas Lötzinn verlötet und überschüssiges Lötzinn mit
Sauglitze entfernt. Zwischendurch und am Ende habe ich gereinigt.
Bevor jetzt wieder große Kritik aufkommt: Ich habe hier zu Hause kein
professionelles Werkzeug. Und den Prozessor hatte ich eh in Verdacht,
dass er die 528 Ohm verursacht, und so nicht mehr für mich brauchbar
ist.
Ausserdem ist das ein privates Projekt.
temp schrieb:> Jörg W. schrieb:>> Mein Projekt habe ich mit>> der Std-Lib gemacht und muss jetzt Alles nach HAL portieren>> Na da hält sich mein Mitleid aber in Grenzen. Warum machst du dann den> gleichen Fehler nochmal?
Welche Fehler? Bitte genauer sein.
Gerhard O. schrieb:> Vor zehn Jahren machten wir ein industrielles Firmenprojekt mit dem F103> wo Tiefschlaf notwendig war. Das funktionierte einwandfrei mit Atollic> TS als Toolchain. Die RTC ...
Danke für die Tips.
Ich habe übrigens hier
https://forum.odroid.com/viewtopic.php?f=116&t=24698 schon mal ein
Batterie-Projekt veröffentlicht. Die Sensoren laufen jetzt 4 Jahre mit
den CR2450. Die ersten Batterien muss ich jetzt bald tauschen.
Jörg W. schrieb:> temp schrieb:>> Jörg W. schrieb:>>> Mein Projekt habe ich mit>>> der Std-Lib gemacht und muss jetzt Alles nach HAL portieren>>>> Na da hält sich mein Mitleid aber in Grenzen. Warum machst du dann den>> gleichen Fehler nochmal?>> Welche Fehler? Bitte genauer sein.
Er meinte die aufgeblasene HAL. Ich verwende anstatt auch lieber die
alternative LL Peripherie Bibliothek. Das kann man in IDE-MX irgendwo
unter Advanced Features einstellen. Die LL bibs sind denen der
ehemaligen SPL viel ähnlicher und schlanker. Ob die LLs für den F103
schon erhältlich sind, kann ich nicht bestätigen weil ich zur Zeit mit
dem L496 arbeite und mit dem F103 schon ewig lange nichts mehr gemacht
habe. Beim F103 arbeite ich sowieso lieber mit der SPL-V3.5.X.
Vielleicht kann das jemand hier im Forum bestätigen oder selber bei ST
nachforschen.
Jörg W. schrieb:> Gerhard O. schrieb:>> Vor zehn Jahren machten wir ein industrielles Firmenprojekt mit dem F103>> wo Tiefschlaf notwendig war. Das funktionierte einwandfrei mit Atollic>> TS als Toolchain. Die RTC ...>> Danke für die Tips.> Ich habe übrigens hier> https://forum.odroid.com/viewtopic.php?f=116&t=24698 schon mal ein> Batterie-Projekt veröffentlicht. Die Sensoren laufen jetzt 4 Jahre mit> den CR2450. Die ersten Batterien muss ich jetzt bald tauschen.
Deine Link produziert leider einen 403 Fehler;-)
Ich komm da jetzt auch nicht mehr rein.
Ich wollte schauen, ob der Link anders ist wenn ich abgemeldet bin.
Hardkernel hat heute einen neuen SBC gestartet, den Odroid C4.
Ja, ich habe das Blink-Beispiel auf dem F103 auch mit der LL gemacht.
Ich habe noch nicht entschieden ob ich HAL oder LL mache, oder beides
mixe. Ich sehe trotzdem immer noch nicht wo da ein Fehler sein soll. Ich
habe mich entschieden das mit STM32 zu machen und gehe gerne und mit
Vergnügen daran. Am Ende muss mein Project in den Flash passen (das wird
es) und möglichst niedrige Stromaufnahme haben. Allerdings möchte ich
den RAM behalten, deswegen gehe ich in Stop2 und nicht in Standby oder
Shutdown.
Jörg W. schrieb:> Ja, ich habe das Blink-Beispiel auf dem F103 auch mit der LL> gemacht.> Ich habe noch nicht entschieden ob ich HAL oder LL mache, oder beides> mixe. Ich sehe trotzdem immer noch nicht wo da ein Fehler sein soll. Ich> habe mich entschieden das mit STM32 zu machen und gehe gerne und mit> Vergnügen daran. Am Ende muss mein Project in den Flash passen (das wird> es) und möglichst niedrige Stromaufnahme haben. Allerdings möchte ich> den RAM behalten, deswegen gehe ich in Stop2 und nicht in Standby oder> Shutdown.
Falls Du noch unsicher bist welcher Libstyle Dir am besten zusagt,
probiere sie alle aus. Da machst Du keinen Fehler. HAL funktioniert
natürlich mehr oder weniger gut obwohl man manchmal genau wie mit allen
anderen LIBs mit den BUGs leben muss. Auch die alte SPL hatte die. Viele
Wege führen nach ROM. Musst halt selber herausfinden welcher Weg am
wenigsten steinig ist. Ist alles eine subjektive Auffassung.
In der Firma arbeiten wir hauptsächlich mit LL und HAL wo es mehr Sinn
hat. Für den persönlichen Gebrauch verwende ich immer noch V3.5 SPL mit
dem F103 unter V9.3.x TS weil ich schon viel Zeit darin investiert habe
und es gut funktioniert. Abgesehen davon finde ich die SPL schlanker.
Auch kann man eigene Sachen leicht davon ableiten. Zumindest hat man
Beispiele wie man es machen muss am Anfang.
Ich bin nicht wirklich ein Freund von graphischen Werkzeugen wie MX-IDE.
Ich versuchte mal ein altes Projekt mit MX-IDE umzuschreiben und
identische Einstellungen zum alten Quellcode und MX-IDE zu finden war
eine reine Qual weil man die graphischen Selektionen und deren
Verwendung nicht immer leicht mit dem alten Code korrelieren konnte. Ist
halt Geschmackssache und der neue Trend alles immer mehr zu abstrahieren
ist ja nicht neu. Abgesehen davon kann man alten Hunden wie mir nur
selten neue Tricks lehren;-)
Ich ziehe Werkzeuge und Methoden vor auf die ich mich verlassen kann und
deren Schrullen man genügend kennt um effizient damit umgehen zu können.
Nirgendwo gilt der Leitsatz mehr als beim Programmieren, dass ein Feind
den man kennt, besser zu unterwerfen ist. Sich andauernd mit neuen
Methoden und Tools herumzuschlagen ist nicht unbedingt mein Metier. Wenn
man wirklich produktiv sein will, dann ist Zuverlässigkeit der Werkzeuge
und viel Erfahrung der springende Punkt. Aber das sieht jeder anders.
Genau wie ein Musikant muss das Instrument im Schlaf funktionieren. Der
kann sich auch nicht erlauben andauernd am Instrument herumzufummeln.
Genauso ist es mit Entwicklungswerkzeugen. Das muss einfach
funktionieren sonst ist es nichts wert.
Mit MX muss man auch sehr aufpassen, dass man eigenen Code nur in die
erlaubten Bereiche fasst. Sonst kann man bei wiederholten Gebrauch von
MX Überraschungen erleben. Da ist freie Gestaltung wie früher auch
angenehmer. Was mich betrifft finde ich MX nicht unbedingt sehr
nützlich. Aber in der Firma verwenden wir es. Auch kann man schnell mal
was zusammenstoepseln. Da ist MX natürlich fast unschlagbar.
Jörg W. schrieb:> Der Link sollte jetzt wieder funktionieren.
Ja! Tut es jetzt;-)
Das werde ich mir später näher ansehen. Ich befasste mich auch vor
Jahren mit solcher Sensortechnik. Allerdings mit PICs. Aber jetzt ruft
die Arbeit...
Stefan ⛄ F. schrieb:> Gerhard O. schrieb:>> MX ... MX ... MX>> Das Produkt heißt Cube MX.
Das stimmt schon. Ich bezog mich aber auf das Cube-IDE wo TS und Cube MX
integriert ist. CUBE MX ist allein stehend.
https://blog.st.com/stm32cubeide-free-ide/
Ich habe nun für den L431 ein Blinkt-Beispiel mit Stop2, Aufwachen mit
RTC nach 5s und NRF24L01+ mit der LL-Bibliothek gemacht.
Dabei komme ich im Stop2 auf gesamt 4.5uA.
Wenn ich alle GPIO, wie im Beispiel, mit LL_GPIO_MODE_ANALOG und
LL_GPIO_PULL_NO einstelle, dann werden es ca 1.1mA.
Thread beobachten
Seitenaufteilung abschalten