10W Bitcoin miner mit 450GH/s für Raspberry Pi

OP Persönliche Seite #7584342
Lesenswert?

Markus W. schrieb:

Verwendest Du eine Backplane auf der Unterseite der Platine, siehe Anhang. Dort sind ja auch Kondensatoren platziert, wenn ich Dein Layout ansehe (blaue Footprints).

Jap, hab das Original benutzt, das dabei war.

Die Backplate für LGA1151 passt wunderbar.

Glaub die sollten für 1151 alle gleich sein 🤔

edit: Die für 1150 1151 1155 1156 sehen wohl alle gleich aus.

Lochabstand 75mm.

#7584634
Lesenswert?

OP Persönliche Seite #7585152
Lesenswert?

Hab mit rev2 einen Bug auf dem Qaxe gefunden - zum Glück leicht zu beheben 😍

Die 330µF-Caps sind falsch platziert - die müssen direkt an den Buck.

Man kann dafür ein paar 100µFs entfernen - 4 sollten aber bleiben. Und einen der 100µ kann man stattdessen unter die ASICs packen.

Ergebnis ist dann:

  • 1.2V Buck wird fast 20°C weniger heiß (bei meinen Tests hatte ich mit einem kleinen 40mm Lüfter oben drauf geblasen - der Unterschied vorher zu nachher ist schon echt ganz erheblich, mit aktiver Kühlung misst der 2te Temperatursensor auf der Unterseite des Boards unter dem Buck-Converter 48°C, vorher 65°C)
  • Stromaufnahme geringer (8 bis fast 10W) - läuft dann auf ziemlich genau 40W (laut meinem Netzteil)
  • 485MHz ASIC Clock funktioniert jetzt so wie es soll 🥳
  • avg Hashrate mit Benchmarking-Program fast exakt 1,8TH und damit genauso schnell wie 4 PiAxe 😍

Werde das morgen dann im Board fixen und als rev3 comitten.

#7585998
Lesenswert?

Wenn Deine 100uF C's einen schlechteren ESR haben, dann warum nicht gleich alle am LTC befindlichen durch 330uF ersetzen und die am ASIC so belassen, wie vorgesehen? Ich habe allerdings nicht im PCB Layout nachgesehen ob es einen Größen-Unterschied beim vorgesehenen Pad der 100uF und 330uF gibt.

Ich werde mal im DB des LTC's stöbern und mir Durchlesen was der Hersteller empfiehlt.

Hast Du bei der Rev.2 nur einen Platzierungsfehler der beiden C-Kategorien gemacht und den nur in Rev.3 ausgebessert, oder hast Du festgestellt (durch Messung Temp. und Rippel) dass mit den 330uF C's der LTC-Regler stabiler und effektiver rennt?

Markus

Sorry wegen den zwei Anhängen. Erst zeigt der Hinzufügen Button nichts an und dann hat man plötzlich zwei Anhänge dran. Falls ein Mod. eins davon löschen kann, bitte ich darum.

Angehängte Dateien:
OP Persönliche Seite #7586146
Lesenswert?

Markus W. schrieb:

Wenn Deine 100uF C's einen schlechteren ESR haben, dann warum nicht gleich alle am LTC befindlichen durch 330uF ersetzen und die am ASIC so belassen, wie vorgesehen?

Was heißt denn "wie vorgesehen"? 🤔

Die am ASIC sind mehr oder weniger willkürlich platziert und offensichtlich wohl falsch, weshalb der Buck zum Oszillieren angefangen hat 😁

Die dicken Caps müssen an den LTC - sonst werden die Leiterbahnen dazwischen zum Inductor und destablisieren alles ... Denke ich zumindest

#7586152
Lesenswert?

Hast Du auch eine derartige Beobachtung bei piaxe gemacht?

Kann Das von Dir beobachtete "Oszillieren" nicht auch von dem Arbeitsverhalten der ASIC's stammen. Die wechseln doch bestimmt von Auftrag zu Auftrag ihr Lastverhalten.

Markus

PS.: Ich werde zu meinen C's 330uF und 100uF kleine NPO/COG 10-100nF C's parallel schalten. Die sind gut für die Transienten.

OP Persönliche Seite #7586221
Lesenswert?

Markus W. schrieb:

Kann Das von Dir beobachtete "Oszillieren" nicht auch von dem Arbeitsverhalten der ASIC's stammen. Die wechseln doch bestimmt von Auftrag zu Auftrag ihr Lastverhalten.

Mmhmm, was ich so beobachtet habe, laufen die einfach immer relativ gleichmäßig vorsichhin.

Man hält sie auch nicht an oder so, schiebt nur einen neuen Job rein.

Markus W. schrieb:

PS.: Ich werde zu meinen C's 330uF und 100uF kleine NPO/COG 10-100nF C's parallel schalten. Die sind gut für die Transienten.

Das ist sicherlich eine gute Idee - da sind eh viel zu wenig 100nFs drauf auf dem Board.

Der Bitaxe hatte überall schon 1µF Cs, hab mich immer gewundert, ob das so sein soll oder "künstlerische Freiheit" war.

OP Persönliche Seite #7587163
Lesenswert?

Hab nochwas herausgefunden ...

Qaxe rev1 hatte das Problem, dass es bei 485MHz ASIC Clock nicht auf die 1,8TH/s avg gekommen ist.

Waren dann nur 1,5TH und bei 100% CPU-Kühlung sogar noch deutlich weniger ... 1TH bis 1.2TH 🙈

Hab die Core-Spannung erhöht um 0,05V (R6 statt 20k sind jetzt 22k) und jetzt klappt es.

1.8TH bei 32°C bei 100% Lüfter 🥳

Wenn das wegen ein paar Millivolt so empfindlich ist, könnte der Ripple vom Buck Konverter schon echt was ausmachen ...

OP Persönliche Seite #7587185
Lesenswert?

Mampf F. schrieb:

Wenn das wegen ein paar Millivolt so empfindlich ist, könnte der Ripple vom Buck Konverter schon echt was ausmachen ...

Jemand hat mir noch den Tipp gegeben, dass ich meine Alu-Polymer Cs durch MLCCs ersetzen sollte.

Die gibts mit 330µF in 1210 und haben nur 1/3tel so hohen ESR.

Er meinte aber auch, ich sollte lieber gleich meinen uralt LTC3856 entsorgen und was modernes mit eigenbauten MOSFETs benutzen 😂

#7587201
Lesenswert?

entsorgen und was modernes mit eigenbauten MOSFETs benutzen.

Den Tipp was das sein könnte hat er Dir aber nicht gegeben :-( ?

Er meinte aber auch, ich sollte lieber gleich meinen uralt LTC3856 entsorgen und was modernes mit eigenbauten MOSFETs benutzen.

Macht Sinn, dann werden die Schaltstrukturen kleiner, das Routing einfacher und wahrscheinlich das EMI und der Wirkungsgrad besser.

Markus

PS.:

Die Preise von den 330uF MLCC's sind auch nicht schlecht. Eventuell ist die 6.3V Version zu hoch gegriffen. Der ASIC hat ja max. 1.2V+x

https://www.mouser.de/c/passive-components/capacitors/?q=MLCC%20330UF&capacitance=330%20uF&case%20code%20-%20in=1210&product=General%20Type%20MLCCs&voltage%20rating%20dc=6.3%20VDC&NewSearch=1

100uF 16V:

https://www.mouser.de/c/passive-components/capacitors/ceramic-capacitors/mlccs-multilayer-ceramic-capacitors/multilayer-ceramic-capacitors-mlcc-smd-smt/?capacitance=100%20uF&case%20code%20-%20in=1210&dielectric=X5R&voltage%20rating%20dc=16%20VDC

#7587506
Lesenswert?

Mampf F. schrieb:

Markus W. schrieb:

Den Tipp was das sein könnte hat er Dir aber nicht gegeben :-( ?

Doch, den hier zum Beispiel:

https://www.ti.com/product/TPS546D24A

Zwei davon ... glaub einer würde nicht ganz reichen.

Hat allerdings Power-Bus, das man dann noch in der Firmware implementieren müsste 🤔

Den verwende ich auch gerade für das 8er Design. An sich reicht der alleine aus. Muss aber aktiv/passiv definitiv gekühlt werden. Der BUS ist nicht zwingend erforderlich. Die Einstellung kann auch über externe Spannungsgeiler realisiert werden.

OP Persönliche Seite #7587555
Lesenswert?

Den verwende ich auch gerade für das 8er Design. An sich reicht der alleine aus. Muss aber aktiv/passiv definitiv gekühlt werden. Der BUS ist nicht zwingend erforderlich. Die Einstellung kann auch über externe Spannungsgeiler realisiert werden.

Oh nice 😍

Wie machst du das mit 8 wenn jeder ASIC 10A+ schluckt und einer alleine nur 40 kann?

#7587599
Lesenswert?

Ich nehme an Be N. nimmt zwei davon, jeweils einen für vier ASIC's

Der IC kostet ja nach Stückzahl zwischen 6 - 5 Euro (netto) z.B. bei Mouser. (für 1, 10, 100 Stück.)

Die Frage, die sich mir stellt, ist wie weit man an die 40A bzw. 4x 10A der vier Kanäle ran gehen darf und um wie viel % dieser Wert überschritten werden kann, bei entsprechender Kühlung.

Markus

#7587657
Lesenswert?

Markus W. schrieb:

Ich nehme an Be N. nimmt zwei davon, jeweils einen für vier ASIC's

Der IC kostet ja nach Stückzahl zwischen 6 - 5 Euro (netto) z.B. bei Mouser. (für 1, 10, 100 Stück.)

Die Frage, die sich mir stellt, ist wie weit man an die 40A bzw. 4x 10A der vier Kanäle ran gehen darf und um wie viel % dieser Wert überschritten werden kann, bei entsprechender Kühlung.

Markus

Wenn wir mal davon ausgehen dass wir die Spannung auf 3.6V wandeln und einen Verbrauch des Qaxe von 50W haben würde das einer Stromlast von 13,88A entsprechen für den 3V6 Zweig. Schaut man sich dein Bild von Qaxe an sprechen wir von 4A bei 12V ;-)

Also einer wird hier ausreichen meiner Meinung nach oder hab ich einen Denkfehler?

Dann wäre die Leistung von Qaxe ja auch falsch. Wenn man mit 10A pro BM1366 rechnet wären wir allein bei 4 Chips bei einer Last von 144W, also das dreifache der aktuellen Leistungsaufnahme.

#7587666
Lesenswert?

Markus W. schrieb:

Wenn ich das richtig verstanden habe, nehmen doch die ASIC's bei 1,2V+-Delta die 10A auf - oder?

Das sind dann die besagten 12W pro ASIC in der AL, AG und eventuell etwas weniger bei der BS Version.

Und die 4x 10A sind doch die Ausgangsströme des TPS Reglers.

Sehe ich das richtig?

Markus

VDD sind 3V6 nicht 1V2... Ich glaub wir laufen grad irgendwo umher :D

#7587973
Lesenswert?

Markus W. schrieb:

@Be N.

Hast du mal versucht die ASICs mit 1.5V zu befeuern? Wenn wir auf 1.5V gehen würden würde die PowerStage mit dem TPS546D24ARVFR für 4 34A liefern. Bei 1.2V sind's 42A

verstehe ich nicht!

1.5V vers 1.2 42A => (51W vers 50.4W)

Was willst Du damit ausdrücken? Oder ist das ein Tippo?

Markus

Ganz normale Leistungsrechnung. Je höher die Spannung umso geringer der Strom. Stromlast des TPS546D24ARVFR sinkt bei Erhöhung der Corespannung von 1.2V auf 1.5V.

1.2V: TPS546D24ARVFR müsste 42A liefern. Da max. 40A möglich sind bräuchte man zwei alleine schön für 4 ASICs

1.5V: TPS546D24ARVFR müsste knapp 33A liefern. Völlig in der Spezifikation, würde ausreichen.

OP Persönliche Seite #7587975
Lesenswert?

Be N. schrieb:

Ganz normale Leistungsrechnung. Je höher die Spannung umso geringer der Strom. Stromlast des TPS546D24ARVFR sinkt bei Erhöhung der Corespannung von 1.2V auf 1.5V.

Weiß nicht, ob ich dich richtig verstanden habe, die ASICs sind aber keine Schaltregler sondern Widerstände.

Wenn du ihnen mehr Spannung gibst, ziehen sie auch mehr Strom. Vermutlich steigt die Verlustleistung im Quadrat zur Spannung (P = U^2/R)

Weiß nicht, wie dann deine Bilanz am Schaltregler aussieht ...

Be N. schrieb:

Sieht top aus! Hast du den Schaltplan mit deinen lokalen Änderungen schon committed?

Jap, hab ich als rev3 gepusht.

#7588004
Lesenswert?

Mampf F. schrieb:

Be N. schrieb:

Ganz normale Leistungsrechnung. Je höher die Spannung umso geringer der Strom. Stromlast des TPS546D24ARVFR sinkt bei Erhöhung der Corespannung von 1.2V auf 1.5V.

Weiß nicht, ob ich dich richtig verstanden habe, die ASICs sind aber keine Schaltregler sondern Widerstände. Wenn du ihnen mehr Spannung gibst, ziehen sie auch mehr Strom. Vermutlich steigt die Verlustleistung im Quadrat zur Spannung (P = U^2/R) Weiß nicht, wie dann deine Bilanz am Schaltregler aussieht ...

Dann sollten wir aber vom TPS546 Abstand nehmen und weiterhin mit externen Mosfets arbeiten die parallel geschalten sind um die Leistung zu erhöhen. Den TPS müsste man mindestens 3 mal für 8 ASICs vorsehen. Das sind Mehrkosten die sich nicht lohnen um externe Mosfets zu sparen

OP Persönliche Seite #7588051
Lesenswert?

Be N. schrieb:

Dann sollten wir aber vom TPS546 Abstand nehmen und weiterhin mit externen Mosfets arbeiten die parallel geschalten sind um die Leistung zu erhöhen. Den TPS müsste man mindestens 3 mal für 8 ASICs vorsehen. Das sind Mehrkosten die sich nicht lohnen um externe Mosfets zu sparen

Hmm ja, es hat schon einen Grund wieso Bitmain eine Seriel-Parallel Konfiguration benutzt.

Das wäre bei > 4 ASICs schon sinnvoll.

Du kannst natürlich 4S2P versuchen, solltest aber zumindest die Level-Shifter mal durchsimulieren, um sicher zu sein, dass das auch so funktioniert wie sie sollen.

Ich persönlich würde ADUM digitale Isolatoren bevorzugen - die gibt es mit zB 3 + 1 (3 TX, 1 RX). Aber die sind teurer ... 🙈

Manche Sachen benötigt man pro ASIC - wie die 0,8V und 1,8V Erzeugung und einen Oszillator.

#7588341
Lesenswert?

Bin grad am designen eines 6-Kerners. Zwei mal Powerstage, gemeinsame Masse aber getrennte VDDs, 3S2P sozusagen. Dazu der STM, damit dürfte der Levelshifter entfallen. Beide Powerstages liefern 35A. Sollte mehr wie ausreichend sein.

Die Induktivitäten sind allerdings recht groß. Muss man berücksichtigen.

#7588525
Lesenswert?

Vielleicht hab ich das auch falsch beschrieben. 3S2P ist es nicht direkt… ich versorge jeweils 3 ASICs mit den geregelten 1.2V der Powerstages. Beide liefern 1.2V 35A

Liegen alle auf der selben Masse. Die ersten drei ASICs werden über PS1 (VDD1 1.2V) versorgt und die anderen drei mit PS2 (VDD2 1.2V).

Somit dürfte der Levelshifter entfallen. Ich hoffe ich hab das jetzt verständlicher ausgedrückt

3P*2 würde es besser beschreiben

OP Persönliche Seite #7588776
Lesenswert?

Kleines Update an einer "Neben-Front".

Gehäuse konnte ich jetzt erfolgreich im 2.Versuch drucken.

Mit PETG hatte ich noch nicht soviele Erfahrungen, aber es hat jetzt geklappt.

Etwas spooky, imho, das Ding senkrecht zu drucken, weil man eine recht kleine Standfläche und dafür eine recht hohe Höhe hat.

Man benötigt dann keinerlei Supports und kann den Qaxe von hinten einfach hineinschieben.

Es fehlen noch ein paar Kleinigkeiten ... "Kühlergrill" vorne, schwarze Streifen auf der "Motorhaube" und Flammenaufkleber auf der Seite 😅

Angehängte Dateien:
OP Persönliche Seite #7589175
Lesenswert?

Be N. schrieb:

Wäre das rein theoretisch möglich das System zu kaskadieren? Sprich die Steuereinheit weglassen und ein Board mit PowerUnit und den ASICs fertigen und RX TX durchschleifen? Dürfte doch bis 12 ASICs funktionieren… rein theoretisch

Das funktioniert bis zu 127 ASICs soweit ich das gesehen habe.

Dann gibt es Limits im ASIC - man kann zB keinem ASIC die Chip-ID 128 geben.

Antminer S19 Pro oder so hat so 104 Chips kaskadiert.

Spricht nichts dagegen :)

#7589292
Lesenswert?

Gerade gefunden:

The hash board consists of 204 BM1366 chips (PCB silk screen order BM1 to BM204), divided into 17 groups (domains), each domain consists of 12 ASIC chips. The operating domain voltage of the BM1366 chip used in the S19 XP Hyd hash board is around 1.14 to 1.25V. The chip VDDIO of domains 1 to 15 is powered by 1.2V&0.8V LDO. Each domain uses 4 LDOs for power supply (one LDO outputs 1.2V and 3 LDOs output 0.8V power supply). Each 0.8V LDO supplies power to 4 ASIC chips, as shown in Figure 4-1. Each of the 16th and 17th high-voltage domains has two MP2019s that output 2V to the LDO, and then the LDO supplies power to the chip VDDIO. Among them, one MP2019 supplies power to 1.2V & 0.8V LDO, and the other one supplies power to 0.8V LDO, a total of 2 groups, as shown in Figure 4-2. Comparing the 1366 hash board with other models, add 16 level_shifters to perform addition operations on the signals. A total of 16 are used from the second domain to the last domain. Level_shifter 1-13 is powered by the voltage of the previous domain, and 14, 15, and 16 are powered by 1 MP2019. There are 4 temperature sensors (T0 to T3), including 1 for inlet and outlet, and 2 for connection chips, as shown in Figure 4-3.

OP Persönliche Seite #7600433
Lesenswert?

Kleines Update ...

Habs geschafft das Gehäuse so zu lackieren, wie ich es mir vorgestellt habe.

Ist nicht perfekt - aber wenn man nicht genauer hinkuckt akzeptabel^^

Ist noch nicht fertig, Kühlergrill fehlt noch, mach ich voraussichtlich morgen.

Fällt mir ein, muss die STL Files noch in das Repository werfen 🤔

Und nochwas anderes - hab mit Bedauern festgestellt, dass der STM32L151C8T6 keinen DFU Bootloader eingebaut hat 🥺

Der Boot-Taster auf rev3 ist daher quasi sinnlos ... Das ist etwas, das mich an den STM32 früher schon genervt hat, man muss für jede Variante immer extra nachschauen, ob er einen DFU Bootloader hat oder nicht ... Beim L151 nahm ich es fällschlicherweise an 😑

Nicht alle L151 haben keinen DFU-Bootloader, es gibt wieder Varianten, die haben ihn ...

Angehängte Dateien:
Beitrag #7601018 wurde von einem Moderator gelöscht.
Beitrag #7601032 wurde von einem Moderator gelöscht.
Beitrag #7601188 wurde von einem Moderator gelöscht.
Beitrag #7601267 wurde von einem Moderator gelöscht.
Beitrag #7601285 wurde von einem Moderator gelöscht.
Beitrag #7601399 wurde von einem Moderator gelöscht.
Beitrag #7601400 wurde von einem Moderator gelöscht.
Beitrag #7601402 wurde von einem Moderator gelöscht.
Beitrag #7601405 wurde von einem Moderator gelöscht.
Beitrag #7601410 wurde von einem Moderator gelöscht.
Beitrag #7601412 wurde von einem Moderator gelöscht.
#7601447
Lesenswert?

@Mampf F.,

ich habe nun alle benötigten Teile beisammen um mir vier qaxe und zwei piaxe aufzubauen. Ein Kollege aus dem Forum hat sich an meine Bestellung dran gehängt und bekommt zwei der qaxe boards bestückt.

Was mich Thomas interessiert, ist die Ansteuerung vom PC aus, in meinem Fall eine Radxa X2L.

Steht im github Repo was dazu? Zu der Miner-SW meine ich.

Das geht wohl über RS232/USB Protokoll. Muss ich mir den piaxe Code ansehen und selber Hand anlegen, oder hast Du da schon den Code dazu und verfügbar gemacht?

Die zwei piaxe sollen nur den Unterschied zwischen AL/AG und den BS ASICs verdeutlichen. Ich habe nur zwei der neuen Versionen geordert und wollte nicht gleich das Geld für die qaxe Bestückung ausgeben, erst wenn es signifikante Unterschiede beim Verbrauch und Rechen- Leistung geben sollte.

Mittlerweile habe ich gesehen, das es auch eine BM1366BP Version gibt. Habe aber leider immer noch keine Antwort vom Verkäufer erhalten, wie sich die AG/AL/BS/BP Versionen voneinander unterscheiden.

Markus

OP Persönliche Seite #7601461
Lesenswert?

Markus W. schrieb:

ich habe nun alle benötigten Teile beisammen um mir vier qaxe und zwei piaxe aufzubauen

Wow, ist ja schon fast Massenproduktion 😅

Markus W. schrieb:

Das geht wohl über RS232/USB Protokoll. Muss ich mir den piaxe Code ansehen und selber Hand anlegen, oder hast Du da schon den Code dazu und verfügbar gemacht?

Die Miner-Software ist fix und fertig:

https://github.com/shufps/piaxe-miner/

Du musst nur die config.yml.example zu config.yml kopieren und den QAxe aktivieren.

Da fällt mir ein - ich wollte noch was einbauen, womit die Python Software die beiden virtuellen COM-Ports automatisch findet, dazu bin ich noch nicht gekommen 🤔 Derzeit muss man in dmesg kucken, welche ttyACMs quasi aktiviert wurden und sie in der Config eintragen.

OP Persönliche Seite #7601463
Lesenswert?

Markus W. schrieb:

Mittlerweile habe ich gesehen, das es auch eine BM1366BP Version gibt. Habe aber leider immer noch keine Antwort vom Verkäufer erhalten, wie sich die AG/AL/BS/BP Versionen voneinander unterscheiden.

Eventuell sind die Chips gebinnt ... Aber keine Ahnung auf was. Vlt auf Frequenz, vlt auf Hashrate, vlt auf Stromverbrauch.

Das weiß man leider nicht.

#7601479
Lesenswert?

gebinnt? (gepinnt?)

Ich habe nur irgendwo gelesen, dass der AG für Luftkühlung und der AL für Wasserkühlung eingesetzt werden, oder umgekehrt. Ob das stimmt und wo der Unterschied dann liegt??? Möglicherweise kann man bei Wasserkühlung näher an die Chip-Maximal- Werte herangehen, da diese Kühlungsart konstanter und verlässlicher ist als der Luftstrom eines Lüfters. Ist aber nur eine Vermutung und kein Fakt.

Markus

PS.: Mit Deiner Aufbaugeschwindigkeit kann ich leider nicht mithalten. Habe auch Dein Künstliche-Last-Projekt bewundernd angesehen. Scheinst in dieser Hinsicht sehr produktiv zu sein oder ist das generell Dein "bread & butter"?

OP Persönliche Seite #7601495
Lesenswert?

Markus W. schrieb:

gebinnt? (gepinnt?)

ge-bin-nt für binning wie das auch mit LEDs gemacht wird, um LEDs mit einigermaßen gleicher Charakteristik bei Produktstreuung in der Fertigung zu bekommen 😅

Markus W. schrieb:

PS.: Mit Deiner Aufbaugeschwindigkeit kann ich leider nicht mithalten. Habe auch Dein Künstliche-Last-Projekt bewundernd angesehen. Scheinst in dieser Hinsicht sehr produktiv zu sein oder ist das generell Dein "bread & butter"?

Nope, mache das alles in meiner Freizeit Abends oder am Wochenende und investiere zum Teil unhealthy-viel Zeit 🙈 Hauptberuflich bin ich Linux Server Admin.

Und dann kann es sein, dass ich wieder 5 Jahre garnichts baue, bis ich wieder etwas finde, was mich so richtig anfixt 😅

Gast #7601552
Lesenswert?

Mampf F. schrieb:

Markus W. schrieb:

gebinnt? (gepinnt?)

Binnung für Bündelung.

Markus W. schrieb:

Möglicherweise kann man bei Wasserkühlung näher an die Chip-Maximal- Werte herangehen, da diese Kühlungsart konstanter und verlässlicher ist als der Luftstrom eines Lüfters.

Verlässlicher sicher nicht, da kann mehr schief gehen. Es is effektiver wegen der guten Wärmeabführung, weil das Wasser sehr viel Wärme aufnehmen kann, ohne groß Temperatur zu nehmen.

#7601574
Lesenswert?

Ihr beide meint also die Kategorisierung in "Bins" Fächern, wie es bei der Selektion von Chips aus verschiedenen Regionen eines Wafers der Fall ist, z.B nach Maximalem Takt oder min. Timing oder Fehler/Verunreinigungen wie bei den Flash Bausteinen. Die Vorgehensweise ist mir zwar bekannt aber der zugehörige Terminus war mir bis dato nicht geläufig.

Danke für die Erklärung.

Markus

#7602828
Lesenswert?

Der o.g. Link bezieht sich wohl auf die u.g. X Meldung.

The newest member of the bitaxe lineup, the bitaxeSupra is working! Single BM1368 ASIC (from the Antminer S21) running arround 620GH/s. Open source everything.

Siehe auch dazu den Link:

https://bitcointalk.org/index.php?topic=5484442.0

PS.: Ich suche bereits eine Weile nach den Datenblättern der ASIC's, konnte aber bis dato nur die der BM138X Serien finden. Hat jemand was zu den BM136X ASIC's im Web gefunden?

https://file12.bitmain.com/shop-product/firmware/BM1384_Datasheet_v2.1.pdf https://file12.bitmain.com/shop-product/firmware/BM1382_Datasheet_v3.0.pdf https://file12.bitmain.com/shop-product/firmware/BM1380_Datasheet_v1.0.pdf

#7603947
Lesenswert?

Ich denke es ist auch im Vergleich nicht zu empfehlen auf den 1368 zu gehen. Er wird laut dem verlinkten Beitrag im 40/50$ Bereich liegen. Die Mehrkosten sind also nicht rentabel. Dazu müsste die Hashrate linear steigen. Das entspräche einem Anstieg der Hashrate auf 1.5TH/s…

Ich bleibe erstmal bei meiner Entwicklung bei dem 1366…

OP Persönliche Seite #7609092
Lesenswert?

Hat zufällig jemand eine Idee, was man für so ein Schaltnetzteil Kabel verwenden sollte?

Hat 5V/60A und für + und - jeweils drei Schraubanschlüsse - also wenn man davon ausgeht, dass ich 50A "verbrennen" möchte 😁

Reichen da 6mm^2 Kabel pro Anschluss? 🤔🤔🤔

Und weiß jemand zufällig, was das für Schraubklemmen sind? Also Hersteller zB, weil ich würde gerne auf einer Platine ein entsprechendes Gegenstück montieren 🤔😅

Angehängte Dateien:
#7609903
Lesenswert?

Mampf F. schrieb:

Hat zufällig jemand eine Idee, was man für so ein Schaltnetzteil Kabel verwenden sollte?

Hat 5V/60A und für + und - jeweils drei Schraubanschlüsse - also wenn man davon ausgeht, dass ich 50A "verbrennen" möchte 😁

Reichen da 6mm^2 Kabel pro Anschluss? 🤔🤔🤔

Ja, 6mm^2 reichen. Als Daumenrichtwert kann man sagen dass bei 12V 6mm^2 60A möglich sind. Bei 5V reicht das aus. Wenn du auf Nummer sicher gehen willst 10mm^2

#7612082
Lesenswert?

Danke!

Bestückung vom QAXE ist angelaufen. PCB-BOT ist fast fertig, in vierfacher Ausführung.

Siehe Links:

https://pixshare.de/oWvCht https://pixshare.de/oWvfY4

Markus

PS.: Die Links sind nur eine Woche gültig!

Ich schreibe Dir noch eine PN, da ich zu den zwei Kondensatoren 100uF/6.3V auf der Unterseite noch Fragen habe. In der BOM stehen sie als Keramik 1210 und auf dem PCB (rev. 0.2) haben sie einen größeren Footprint!

OP Persönliche Seite #7612084
Lesenswert?

Markus W. schrieb:

Ich schreibe Dir noch eine PN, da ich zu den zwei Kondensatoren 100uF/6.3V auf der Unterseite noch Fragen habe. In der BOM stehen sie als Keramik 1210 und auf dem PCB (rev. 0.2) haben sie einen größeren Footprint!

Der größte Unterschied von rev2 zu rev3 ist anderes Kondensator Placement.

Die dicken 330µF sind alle zum Buck gewandert - das kann man auf rev2 nachträglich noch umfummeln. Stattdessen sitzen auf der Rückseite in der Mitte der ASICs zwei 100µF in 1210

Optimal wäre es, wenn rev2 mit den Caps am Buck dann wie rev3 aussieht :)

#7612103
Lesenswert?

Hallo Thomas,

Mitte der ASICs zwei 100µF in 1210

die C's aus der BOM sind aber keramisch 1210, die Footprints gehören eher zu Tantal-C's

Die 1210 C's passen nicht zu den FP, die PAD's sind zu weit auseinander.

Sollen jetzt an diese Stelle keramische oder elektrolyt C's hin?

LG Markus

OP Persönliche Seite #7612106
Lesenswert?

Markus W. schrieb:

die C's aus der BOM sind aber keramisch 1210, die Footprints gehören eher zu Tantal-C's

Bei rev2 waren die keramischen 100µF 1210 alle am Buck, die 330µF alle auf der Rückseite.

Die 1210 C's passen nicht zu den FP, die PAD's sind zu weit auseinander.

Rev3 hat die passenden Footprints. Bei Rev2 kann man mit genügend Lötzinn die 1210er Cs dort hinlöten, wo die Alu-Polymer Caps waren.

Sollen jetzt an diese Stelle keramische oder elektrolyt C's hin?

Auf der Rückseite die keramischen, die dicken Alu-Polymer an den Buck.

Ich hab dir von rev3 screenshots der 3D-View angehängt.

Man kriegt es auf rev2 so hin, dass es wie auf rev3 aussieht.

Angehängte Dateien:
#7612824
Lesenswert?

@Mampf,

habe heute die Erste Pltine fast fertig bestückt. Es fehlen nur noch die ASIC's, die kommen aber erst drauf, wenn ich die Versorgungen geprüft habe.

Dazu gleich eine Frage an Dich,

Nachdem beim Anschluss der 12V Nichts geraucht hat und auch keine nennenswerte Erwärmung auf dem IR-Bild zu sehen ist habe ich die Testpunkte mit einem DVM abgeklappert.

5V und 3.3V sind vorhanden. Beim LTC Regler bin ich mir nicht sicher, ob er erst vom MC konfiguriert werden muß, damit er anläuft und ich die 1.2V und 0.8V zu sehen bekomme.

Der LTC3856 hat ja einen RUN-Pin.

Ist das so?

Hätte mir die Antwort selber geben können.

Laut DB steht da:

RUN (Pin 2/Pin 30): Run Control Input. A voltage above 1.22V on this pin turns on the IC.

Also muss der MC laufen, um die Konverter zu aktivieren und erst dann sehe ich die ASIC Versorgungen 0.8V & 1.2V.

kannst Du das so bestätigen, oder hängt der Pin irgendwo fix an einem Spannungsteiler?

Markus

Angehängte Dateien:
#7612845
Lesenswert?

@Mampf,

ich habe mir gerade die FW für rev 0.2 via rust compiliert. Wie muss ich das File mittels run.sh auf den MC bringen.

PCB an 12V Versorgung und via PC-USB oder anders an den PC anschließen? Irgend einen Jumper setzen - hast Du mal erwähnt.

file ./target/thumbv7m-none-eabi/release/qaxe ./target/thumbv7m-none-eabi/release/qaxe: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

LG+Danke! Markus

#7612961
Lesenswert?

Habe mich durchgebissen und konnte das Binery für den STM32 erzeugen, s.u.

Markus

1
mw@linux-kwm1:/dev/shm/QAXE/FW/qaxe/firmware/fw-rev2
2
>cargo objcopy --release --bin qaxe -- -O binary qaxe-rev2.bin
3
   Compiling defmt-macros v0.3.6
4
   Compiling defmt v0.3.5
5
   Compiling embedded-io v0.6.1
6
   Compiling embassy-net-driver v0.2.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-net-driver)
7
   Compiling embassy-time v0.3.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-time)
8
   Compiling embassy-usb-driver v0.1.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-usb-driver)
9
   Compiling bxcan v0.7.0
10
   Compiling embassy-hal-internal v0.1.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-hal-internal)
11
   Compiling embassy-executor v0.5.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-executor)
12
   Compiling embedded-io-async v0.6.1
13
   Compiling panic-probe v0.3.1
14
   Compiling defmt-rtt v0.4.0
15
   Compiling embassy-sync v0.5.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-sync)
16
   Compiling embassy-net-driver-channel v0.2.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-net-driver-channel)
17
   Compiling embassy-embedded-hal v0.1.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-embedded-hal)
18
   Compiling embassy-usb v0.1.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-usb)
19
   Compiling embassy-stm32 v0.1.0 (/dev/shm/QAXE/FW/qaxe/firmware/embassy/embassy-stm32)
20
   Compiling embassy-stm32l1-examples v0.1.0 (/dev/shm/QAXE/FW/qaxe/firmware/fw-rev2)
21
    Finished release [optimized + debuginfo] target(s) in 6.24s
22
warning: unused import: `BufRead`
23
  --> src/bin/qaxe.rs:24:25
24
   |
25
24 | use embedded_io_async::{BufRead, Read};
26
   |                         ^^^^^^^
27
   |
28
   = note: `#[warn(unused_imports)]` on by default
29

30
warning: 1 warning emitted
1
>file qaxe-rev2.bin
2
qaxe-rev2.bin: ARM Cortex-M firmware, initial SP at 0x20004000, reset at 0x080000f4, NMI at 0x08009ece, HardFault at 0x0800c9d6, SVCall at 0x08009ece, PendSV at 0x08009ece

[Mod: Code-Tags eingefügt]

OP Persönliche Seite #7613490
Lesenswert?

Markus W. schrieb:

Also muss der MC laufen, um die Konverter zu aktivieren und erst dann sehe ich die ASIC Versorgungen 0.8V & 1.2V.

kannst Du das so bestätigen, oder hängt der Pin irgendwo fix an einem Spannungsteiler?

Ja genau das ist richtig für die 1,2V. Die 0.8V und 1.8V sollten auch so gehen, weil die hängen an den 3.3V

Markus W. schrieb:

Habe mich durchgebissen und konnte das Binery für den STM32 erzeugen, s.u.

Sehr gut, dann muss es nur noch "irgendwie" in den stm32.

Falls den CMSIS-DAP Adapter nachgebaut hast 1, reicht es, das "run.sh" script im firmware-Verzeichnis auszuführen.

Du kannst das Binary aber auch mit einem anderen SWD-fähigen Adapter flashen.

#7613509
Lesenswert?

Ich versuche den MC mit einer BMP (black magic probe) zu Programmieren. SWDIO und SWCLK sowie GND sind schon richtig verbunden.

Leider wird das STM32 Device noch nicht erkannt.

gdb> target extended-remote /dev/ttyACM0

monitor swdp_scan

Brauche ich noch andere Leitungen?

Der QAXE wird via 12V NT bestromt so dass ich kein Vcc über den BMP liefern muss. Ist der (N)RST Pin auch zu verbinden?

LG Markus

PS.:

Nachdem was unter https://github.com/shufps/raspi-pico-dap braucht man nur drei Leitungen.

Angehängte Dateien:
OP Persönliche Seite #7613538
Lesenswert?

Markus W. schrieb:

Nachdem was unter https://github.com/shufps/raspi-pico-dap braucht man nur drei Leitungen.

Ja genau, man braucht nur drei Leitungen.

Markus W. schrieb:

Der QAXE wird via 12V NT bestromt so dass ich kein Vcc über den BMP liefern muss. Ist der (N)RST Pin auch zu verbinden?

Mit meinem STLink V2 Klon hab ich Reset auch immer verwendet - dieser cmsis-dap Adapter scheint aber keinen Reset zu haben.

Falls du einen Reset-Pin an deinem Programmer hast, würde ich ihn verwenden 🤔

Ich kenne die Unterschiede zwischen normalem SWD und CMSIS-DAP nicht, vlt ist das ein anderes Protokoll, vlt ist das nur ein anderer Namen für das Selbe, idk 🙈

OP Persönliche Seite #7613553
Lesenswert?

Markus W. schrieb:

Wie sieht es aus, wenn der STM32 am Pin #44 (boot) auf 3.3V gehievt wird - kommuniziert er dann wie USB-C im RS232 Mode?

Ja, der Bootloader kann UART (die C8-Variante kann leider kein USB-Bootloader, die CC-Variante hätte ihn), allerdings glaub ich macht er das nur an USART1 und da hängen die Level-Shifter dran.

SWD sollte normalerweise schon gehen, ganz sicher 🤔

Also 3,3V hat er ja, right? Dann fehlt eigentlich wirklich nicht mehr viel

#7613581
Lesenswert?

3.3V am Regler habe ich gestern gemessen, allerdings nicht direkt am MC.

Schaue mir am Abend die Platine nochmals genauer an und werde versuchen auch den Takt am DSO darzustellen, denn nur dann kann der MC ja funktionieren, oder hat diese Variante auch einen internen RC-Taktgeber, der dann später den ext. Takt aktiviert?

Was muss man an den diversen TP sehen (TP14,15)? Die habe ich im Schema Versorgungsteil (v.0.2) nicht gefunden.

Markus

#7614600
Lesenswert?

Hallo Mampf und Forum,

will noch nicht recht klappen mit dem Flashen,

Habe es jetzt mit einem ST-Link V2 versucht.

Einmal mit angeschlossenem NT mit 12V und einmal ohne mit 3.3V an beiden externen LED-Pins, die jeweils über 560 Ohm auf die 3.3V vom MC gehen. NRST ist auch angeschlossen, hat aber nichts gebracht. Ob jetzt die 560 || 560,also 280 Ohm in der 3.3V Versorgung des MC's schon zu viel sind kann ich für die L-Variante des STM32L nicht sagen. Hat jemand da Infos.

Der Output vom ST-Link V2 ist unten gelistet.

Für sachdienliche Hinweise bin ich dankbar.

Markus

PS.: die Adapter-Platine auf den kleinen Stecker ist von 1-bitsquered.

1
Mar 01 19:55:28 linux-kwm1 kernel: usb 1-1: new full-speed USB device number 64 using xhci_hcd
2
Mar 01 19:55:28 linux-kwm1 kernel: usb 1-1: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
3
Mar 01 19:55:28 linux-kwm1 kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
4
Mar 01 19:55:28 linux-kwm1 kernel: usb 1-1: Product: STM32 STLink
5
Mar 01 19:55:28 linux-kwm1 kernel: usb 1-1: Manufacturer: STMicroelectronics
6
Mar 01 19:55:28 linux-kwm1 kernel: [37B blob data]
7

8
>st-info --probe
9
Found 1 stlink programmers
10
  version:    V2J17S4
11
  serial:     303030303030303030303031
12
  flash:      0 (pagesize: 0)
13
  sram:       0
14
  chipid:     0x000
15
  dev-type:   unknown
16

17
>st-info --chipid
18
Failed to enter SWD mode
19
0x0000
20

21
>st-info --descr
22
unknown
23

24
st-flash --connect-under-reset write /dev/shm/QAXE/FW/qaxe/firmware/fw-rev2/qaxe-rev2.bin 0x8000000
25
st-flash 1.8.0-13-g40ee5f4
26
2024-03-01T22:31:28 WARN common.c: NRST is not connected
27
2024-03-01T22:31:28 ERROR common.c: Soft reset failed: error write to AIRCR
28
2024-03-01T22:31:28 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again
29
Failed to connect to target
Angehängte Dateien:
OP Persönliche Seite #7614755
Lesenswert?

Markus W. schrieb:

WARN common.c: NRST is not connected

Hmm, das ist seltsam - kannst du nochmal den NRST prüfen, ob der wirklich richtig angeschlossen ist? 🤔

Und hast du zufällig einen Schaltplan deines Adapter-Moduls? Da kann ich schlecht prüfen, ob die richtigen Pins angeschlossen sind, weil das mehr als 2x5 ist.

Sorry, falls ich hier nicht so oft reinkucke, über Discord bin ich direkt zu erreichen.

#7614764
Lesenswert?

Hallo Thomas,

NRST steht doch für Low active Reset, also ein Reset, wen der Pin auf 0V Potential gezogen wird.

Da ich keinen Pin habe, an den ich direkt die 3.3V Versorgung des MC's vom ST-Link V2 anlegen kann, habe ich zwei Leitungen mit 3.3V vom ST-Link V2 zum Pin-Header der beiden externen LED's gelegt (über die zwei 560 Ohm) und hoffe so daß der MC STM32L genug Power erhält umprogrammiert werden zu können.

Ohne diese Versorgung habe ich auch die Platine via 12V vom NT versorgt, hatte aber auch kein Erfolg beim Programmieren.

Am Montag werde ich den MC, von dem ich noch einen übrig habe auf eine 48-Pin Adapterplatine löten um mal zu sehen, was ich an Leitungen wirklich brauche um den Chip zu identifizieren.

Auf dem Adapter kann ich alle Leitungen herausführen, was auf dem QAXE nicht so leicht geht.

Ich schreibe mit dem nächsten Post, wie ich die Verbindung von dem ST-Link zum MC gemacht habe.

LG Markus

OP Persönliche Seite #7614803
Lesenswert?

Markus W. schrieb:

NRST steht doch für Low active Reset, also ein Reset, wen der Pin auf 0V Potential gezogen wird.

Jup, das ist korrekt.

Markus W. schrieb:

Da ich keinen Pin habe, an den ich direkt die 3.3V Versorgung des MC's vom ST-Link V2 anlegen kann, habe ich zwei Leitungen mit 3.3V vom ST-Link V2 zum Pin-Header der beiden externen LED's gelegt (über die zwei 560 Ohm) und hoffe so daß der MC STM32L genug Power erhält umprogrammiert werden zu können.

Man braucht keine externen 3,3V.

Einfach das Board an den Strom hängen und SWDIO, SWCLK und GND verbinden und ggfls den NRST.

Markus W. schrieb:

Ohne diese Versorgung habe ich auch die Platine via 12V vom NT versorgt, hatte aber auch kein Erfolg beim Programmieren.

Okay verstehe, das ist seltsam.

Markus W. schrieb:

Ich schreibe mit dem nächsten Post, wie ich die Verbindung von dem ST-Link zum MC gemacht habe.

Ok, bin gespannt!

So einen STLinkV2 Klon hab ich jahrelang benutzt und nie damit Probleme gehabt.

Du könntest auch mal kucken, ob openocd den µC erkennt per

1
openocd -f qaxe.cfg

und das hier die config:

1
source [find interface/stlink-v2.cfg]
2

3
source [find target/stm32l0.cfg]
4

5
# use hardware reset, connect under reset
6
#reset_config srst_only srst_nogate
7
reset_config none separate

Du kannst beide reset-Konfigurationen mal ausprobieren, das was aktiv ist, ist das, was ich seit Jahren benutze.

Du hast auch mehrere Qaxe Boards, right? Machen alle das gleiche?

#7614843
Lesenswert?

Hallo Thomas,

So einen STLinkV2 Klon hab ich jahrelang benutzt und nie damit Probleme gehabt.

Im MCFH Projekt, steht auch im MC-Forum habe ich auch einige STM32F4xx geflashed und das ging immer ohne Probleme, allerdings habe ich noch andere Leitungen wie z.B. SWIM verwendet.

Danke für die openocd Konfiguration. Werde es damit auch mal versuchen.

Ich sehe den ST-Link während der Kommandierung blinken, aber er erkennt das Target nicht.

Wenn ich ausschließe, daß ich noch irgendwo einen Pin-Kurzschluß durch eine Lötzinn-Brücke habe, und eigentlich ist das der Fall, da ich und mein Kollege mit einem Stereo-Mikroskop nach dem Dampf-Phasen-Lötvorgang eine optische QA gemacht haben, kann es nur noch an der Konfiguration des Programmers liegen.

Deshalb die Idee mit dem Adapterboard und dem verfügbaren MC, der übrig geblieben ist, da man dann besser verschiedene Pins an den ST-Link anschließen kann.

Nächste Woche bin ich Unterwegs, so daß ich mich erst danach melde, sofern ich es bis Montag nicht geschafft habe den MC zu flashen.

LG+SWE

Markus

PS.: OpenOCD Zugriff, s.u.

1
Versorgung ST-Link 3.3V am Lüfter-Pin
2
=====================================
3

4
>openocd -f /dev/shm/QAXE/qaxe_openocd.cfg 
5
Open On-Chip Debugger 0.12.0
6
Licensed under GNU GPL v2
7
For bug reports, read
8
        http://openocd.org/doc/doxygen/bugs.html
9
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
10
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
11
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
12
none separate
13

14
Info : Listening on port 6666 for tcl connections
15
Info : Listening on port 4444 for telnet connections
16
Info : clock speed 300 kHz
17
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
18
Info : Target voltage: 6.246943
19
Error: init mode failed (unable to connect to the target)
20

21

22
Versorgung: 12V NT
23
===================
24
>openocd -f /dev/shm/QAXE/qaxe_openocd.cfg 
25
Open On-Chip Debugger 0.12.0
26
Licensed under GNU GPL v2
27
For bug reports, read
28
        http://openocd.org/doc/doxygen/bugs.html
29
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
30
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
31
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
32
none separate
33

34
Info : Listening on port 6666 for tcl connections
35
Info : Listening on port 4444 for telnet connections
36
Info : clock speed 300 kHz
37
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
38
Info : Target voltage: 6.182248
39
Error: init mode failed (unable to connect to the target)

Info : Target voltage: 6.182248 - verstehe ich nicht!

OP Persönliche Seite #7615084
Lesenswert?

Markus W. schrieb:

Noch einmal die Bilder zu meinem Prog-Adapter.

SWDIO: or SWCLK: ge NRST: gn GND: bl

Markus

Das kann ich leider nicht prüfen, weil ich nicht weiß, wie dein 1,27mm Adapter auf 2,54mm Adapter verdrahtet ist.

1-zu-1 kann es ja schlecht sein, der 2,54mm Pinheader hat deutlich mehr Pins.

Kann man das bitte irgendwie nachvollziehbar machen?

Mit Schaltplan oder soetwas?

edit: Das hier scheint es wohl zu sein: https://www.adafruit.com/product/2094

Ansonsten, hatte ich dich schon gefragt, ob du 3,3V am lm1117 misst, wenn er an 12V hängt?

Target voltage: 6.182248

Hmm, das ist wirklich sehr sonderbar

OP Persönliche Seite #7615093
Lesenswert?

Oh ah ich versteh jetzt, was du gemacht hast ...

Ups, es gibt keine Standard-10pol SWD Belegung 🙈

Das Adafruit Board hat den SWD Connector anders belegt.

Meine Belegung kam von einem STLink V2 Klon, die ich für quasi alles übernommen hatte. Die Belegung von deinem Klon ist wieder anders. Ich glaub bei den Klons gabs 2, soweit ich weiß.

Zum Glück sind rein zufällig die fest-kurzgeschlossenen Ground Pins 3, 5, 7 und 9 Ground oder nicht benutzt - dann kannst du prinzipiell den Adapter benutzen.

Musst nur kucken, wo welches Signal hingehört.

Angehängte Dateien:
#7615105
Lesenswert?

Hallo Thomas,

Ich habe es auch mit einem J-Link nach gleicher Methoden mittels des 1bitsquared Adapters versucht, aber irgendwie klappt die Kommunikation zum MC noch nicht.

Ich muss wohl mein DSO rauskramen und ein paar Drähte an den QAXE anlöten.

Trotzdem danke für Deine Mühe.

Markus

1
>JLinkSTM32
2
SEGGER J-Link Unlock tool for STM32 devices
3
Compiled Feb 29 2024 10:29:52
4
(c) 2009-2015 SEGGER Microcontroller GmbH, www.segger.com
5
              Solutions for real time microcontroller applications
6

7
This program is designed to reset the option bytes of a STM32 device to their factory settings. If read protection of the device is enabled, reset the option bytes will cause a mass erase.
8

9
Options:
10
  [0] Exit
11
  [1] STM32C0xxxx
12
  [2] STM32F0xxxx
13
  [3] STM32F1xxxx
14
  [4] STM32F2xxxx
15
  [5] STM32F3xxxx
16
  [6] STM32F4xxxx
17
  [7] STM32F72xxx, STM32F73xxx
18
  [8] STM32F74xxx, STM32F75xxx
19
  [9] STM32F76xxx, STM32F77xxx
20
  [10] STM32G0x0xx
21
  [11] STM32G0x1xx
22
  [12] STM32G4xxxx
23
  [13] STM32H743_53_50
24
  [14] STM32H745_47_55_57
25
  [15] STM32L0xxxx
26
  [16] STM32L1xxxx
27
  [17] STM32L4xxxx
28
  [18] STM32L5xxxx
29
  [19] STM32U5xxxx
30
  [20] STM32WBxxxx
31
  [21] STM32WLxxxx
32
Please select the correct device family: 16
33
Connecting to J-Link via USB...O.K.
34
Using SWD as target interface.
35
Target interface speed: 1000 kHz.
36
VTarget = 0.000V
37
Target voltage too low
38
Press any key to exit.
OP Persönliche Seite #7615286
Lesenswert?

Markus W. schrieb:

NRST -> 1 verstehe ich nicht. Da ist doch Vcc.

Nein, da ist der Silkscreen Aufdruck "VCC", das hat aber nichts mit dem eigentlichen Pinning zu tun.

Die Belegung des 1,27mm Pinheader wird nicht durch den Silkscreen auf dem Adapter festgelegt sondern durch die Platine vom QAxe.

Qaxe:

1
1: NRST
2
2: SWDIO
3
6: SWCLK
4
3: GND

Wenn du dir anschaust, wo die Leitungen vom 1,27mm Pinheader auf deinem Adapter zum 2,54mm Pinheader gehen, dann siehst du:

1
1,27mm | 2,54mm
2
---------------
3
1     -> 1
4
2     -> 7
5
6     -> 13
6
3     -> 4, 6, 8, ...

Dann müsste es passen, wenn du deine Kabel vom STLink kommend so anschließt:

1
NRST -> 1
2
SWDIO -> 7
3
SWCLK -> 13
4
GND -> 4

Aber du hast das, soweit ich das erkennen kann, schon korrekt verdrahtet.

Mein STLink Klon hat nie 3,3V benötigt ... Hmm, vlt ist deiner unterschiedlich, idk 🤔 Das könntest du gemeint haben mit, du musst ein Kabel ziehen.

Ausprobieren kann man es mal 🙈

edit: Oh gerade gesehen, Pin 2 geht auf Pin7!!! Bitte korrigieren, sorry hab das falsch auf dem Board gesehen

Das sollte richtig sein:

1
NRST -> 1
2
SWDIO -> 7
3
SWCLK -> 13
4
GND -> 4
#7616334
Lesenswert?

Hallo Thomas,

was lange währt, wird endlich gut.

Nachdem ich mit BMP, J-Link und ST-Link V2 diverse Versuche unternommen habe, die leider nicht gefruchtet haben, habe ich mit einem anderen älteren ST-Link V2 Platinchen Glück beim Flashen den MC's gehabt.

Deine vorgeschlagene PIN-Belegung war soweit korrekt.

Siehe Anhang - Verkabelung, Flash-Vorgang und die Antwort vom QAXE beim anstecken an den PC.

LG+Danke für Deine Hilfe und Mühe.

Hoffe meine Ausführungen können anderen Enthusiasten, die einen QAXE aufbauen weiter helfen.

Markus

PS.: Nächste Woche werden die ASIC's auf die erste PCB gelötet und die restlichen drei PCB's fertig bestückt.

Ich überlege, ob ich nicht gleich einen STM32F152 drauf löten soll, der via USB geflasht werden kann.

Was meinst Du?

Angehängte Dateien:
OP Persönliche Seite #7616362
Lesenswert?

Yay, super! Freut mich, dass es jetzt geklappt hat!

Markus W. schrieb:

Ich überlege, ob ich nicht gleich einen STM32F152 drauf löten soll, der via USB geflasht werden kann.

Das würde ich aus diversen Gründen nicht machen.

  1. Die Rust-Firmware müsste "portiert" werden. Embassy abstrahiert zwar viel, vieles müsste aber noch angepasst werden.

  2. Der STM32L151CC hat einen USB-Bootloader, dafür müsste man den Pin PB2 per Pull-Down nach GND ziehen, dann würde er starten, wenn man einen Reset bei gedrückten Boot-Knopf macht (den gibts auf rev3). Das müsste in rev3.1 funktionieren. (rev3 ist mit CC-Variante und boot-Button, rev3.1 hat den nötigen Pull-Down, der noch gefehlt hat 🙈).

#7616376
Lesenswert?

@Markus, habe dir eine PN geschrieben. Schön zu sehen wie das Projekt weitergeht, meine ASIC sind leider immer noch nicht da, Chinesisches Neujahr sei Dank.

Zu deiner Frage an Mampf:

install curl

sudo apt install curl

install rust

curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh

add to ~/.bash.rc (afterwards, opening a new terminal is needed)

echo 'source "$HOME/.cargo/env"' >> ~/.bashrc

clone repository

git clone https://github.com/shufps/qaxe

clone submodules

cd qaxe git submodule init git submodule update

add rust target for rev2/3

rustup target add thumbv7m-none-eabi

or add rust target for rev1

rustup target add thumbv6m-none-eabi

build firmware for rev2

cd firmware/fw-rev2

or

cd firmware/fw-rev3 ./build.sh

run firmware (this also flashes it to the stm32)

./run.sh

siehe hier: https://github.com/shufps/qaxe

EDIT: habe es gerade mal getestet, scheint zu funktionieren (2 Warnings) Bricht bei mir dann aber ab, habe die Hardware nicht angeschloßen: error: could not execute process probe-rs run --chip STM32L151C8xxA target/thumbv7m-none-eabi/release/qaxe (never executed)

#7616415
Lesenswert?

@Roland F.,

danke für die Zusammenfassung der Rust Kommandos. Habe ich schon gemacht. Unsere Postes haben sich wohl überschnitten. Ich habe ja des .bin bereits geflashed und auch eine Antwort vom MC an den PC bekommen. D.h. das USB Interface funktioniert schon mit der drauf gespielten FW.

Markus

PS.: Die PN schaue ich mir gleich an.

OP Persönliche Seite #7616549
Lesenswert?

So geht es dann weiter:

https://github.com/shufps/piaxe-miner/blob/master/README.md#installation

Man installiert dann die Python Dependencies und passt die config.yml an und startet den Miner. Es gibt auch ein Example-Start-Script, wo man nur noch seine BTC Adresse eintragen muss.

Du kannst den Pyminer ohne ASICs starten, dann schaltet er die 1,2V an, die du dann prüfen kannst, bevor du die ASICs montierst :)

OP Persönliche Seite #7617388
Lesenswert?

Kleines Update ... Hab jetzt ein modulare Design gebastelt und die ersten 4 Module funktionieren schon. (1-Modul-Testboard im 2ten Bild).

Das besondere ist, dass man die Module super-einfach sowohl serial- als auch voltage-chainen kann.

Nächster Schritt ist ein Carrier-Board für 4 dieser Module.

Falls es geht, ist es ein 16-ASIC Miner mit ca. 7.2TH/s und ~200W Leistung 😁

Angehängte Dateien:
OP Persönliche Seite #7621804
Lesenswert?

Be N. schrieb:

Das sieht sehr verlockend aus!

Bin bisher nicht mehr dazu gekommen meinen zu erweitern. Wie stellst du das voltage-chaining an? Bzw. Das Serielle?

Ich hab für das serielle Chaining ADUM Digitale Isolatoren benutzt. Dann kann man quasi für den Input der nächsten Voltage domain die 1,8V und Signale von der vorherigen Voltage domain verwenden und muss sich quasi um nichts kümmern.

Netter Nebeneffekt ist, dass man auch ein einziges Modul an einen 5V Arduino hängen könnte, wenn man wollte 🙈

Im zweiten Bild sieht man das Ding fertig und in Betrieb.

Schafft sowas 7.2TH/s mit 205W. Die Kühlung hat sich bisserl verändert, mit den kleinen Lüfterchen war das nicht kühl zu bekommen.

Gibt’s dazu ein Repo? Sieht echt sehr verlockend aus

Noch nicht, das ist alles Kraut und Rüben gerade 🙈

Angehängte Dateien:
#7621867
Lesenswert?

Gefällt mir sehr gut!

Würde mir persönlich nichts ausmachen ob Kraut und Rüben :-D

Das ist letztendlich genau das was ich auch realisieren wollte. Wäre also sehr interessiert an den Ressourcen sofern die wieder OpenSource sind :)

Seh ich das richtig, dass die ASICs auf den ASIC-Modulen parallel geschalten sind? Würde ja bedeuten, dass du in deinem Fall (Bild) eine Spannungsversorgung von 4V8 liefern musst damit du die Module in Reihe betreiben kannst? Bedeutet die PowerStage liefert 4V8 bei 50A...

Das mit ADUM ist genial... Letztendlich benötigst du hier nur die Referenzspannung (Potential) des ursprünglichen Signals! Geniale Lösung!

An sich ein extrem modulares System! Freu mich auf das Repo!!!

Übrigens hab ich gesehen, dass bei OSMU man gewisse ICs günstiger bekommen kann wenn man abonniert? Sind da auch die ASICs mit enthalten bzw. Rs als auch Cs?

Als Privatperson zahlt man sich bei DigiKey bzw. Mouser ja dumm und dämlich :-/

OP Persönliche Seite #7621927
Lesenswert?

Be N. schrieb:

Seh ich das richtig, dass die ASICs auf den ASIC-Modulen parallel geschalten sind?

Ja, pro Modul sind es immer 4 ASICs, die parallel sind. Und 4 Module in Reihe.

Würde ja bedeuten, dass du in deinem Fall (Bild) eine Spannungsversorgung von 4V8 liefern musst damit du die Module in Reihe betreiben kannst? Bedeutet die PowerStage liefert 4V8 bei 50A...

Viel einfacher! Ich hab das Board so dimensioniert, dass ich ein fettes 5V@40A Netzteil anschließen kann. Das Netzteil kann man in gewissen Grenzen nachjustieren - sowas 4.5V bis 5.5V oder so.

Das Board hat selbst keinen Buck mehr für die ASICs.

Man spart sich dann den ganzen Buck Converter auf dem PCB und eine dicke Power-Supply braucht man eh, statt 12V + Buck kann man dann gleich 5V benutzen 😁

Be N. schrieb:

Übrigens hab ich gesehen, dass bei OSMU man gewisse ICs günstiger bekommen kann wenn man abonniert? Sind da auch die ASICs mit enthalten bzw. Rs als auch Cs?

Das weiß ich leider nicht 🥺

Be N. schrieb:

Würde mir persönlich nichts ausmachen ob Kraut und Rüben :-D

Ich schau, dass ich das asap mal aufräume 🙈

Der nächste logische Schritt wäre dann 10 Voltage Domains an 12V lol 🥴

#7621943
Lesenswert?

Mampf F. schrieb:

Viel einfacher! Ich hab das Board so dimensioniert, dass ich ein fettes 5V@40A Netzteil anschließen kann. Das Netzteil kann man in gewissen Grenzen nachjustieren - sowas 4.5V bis 5.5V oder so.

Das Board hat selbst keinen Buck mehr für die ASICs.

Man spart sich dann den ganzen Buck Converter auf dem PCB und eine dicke Power-Supply braucht man eh, statt 12V + Buck kann man dann gleich 5V benutzen 😁

Klingt auch gut, für mich müsste ich dann dennoch den Buck vorsehen. Ich habe vor den Miner an einem Balkonkraftwerk mit MPPT für KFZ-Batterien zu betreiben. Natürlich wären dann 10 Module in Reihe möglich, dennoch müsste ich die Spannung auf 12V begrenzen. Fürs erste möchte ich das mal so belassen.

Sprich würde es deiner Meinung nach reichen eine PowerStage mit vielfachem von 1V2 mit 40A auszulegen? Ich war der Meinung die ASICs brauchen >10A :-/

Interessant... Ich habe erstmal mit 3 ASICs pro Modul bei mir kalkuliert. Letztendlich das selbe Prinzip aber 3 statt 4 ASICs aufgrund der 40A...

OP Persönliche Seite #7621999
Lesenswert?

Be N. schrieb:

Sprich würde es deiner Meinung nach reichen eine PowerStage mit vielfachem von 1V2 mit 40A auszulegen? Ich war der Meinung die ASICs brauchen >10A :-/

Interessant... Ich habe erstmal mit 3 ASICs pro Modul bei mir kalkuliert. Letztendlich das selbe Prinzip aber 3 statt 4 ASICs aufgrund der 40A...

hmm ja, rein rechnerisch habe ich 10,25A pro Modul Stromverbrauch.

205W benötigt der Miner insgesamt - gemessen direkt an den 230V.

Also 10A pro ASIC ist schon sehr knapp, sollte man wohl eher mit idk 12A rechnen.

Ah und ich hab mich vertan, mein 5V Netzteil liefert max 60A ... Also glaube schon, dass mehr als 40A gebraucht werden 🙈

#7622003
Lesenswert?

Mampf F. schrieb:

Ah und ich hab mich vertan, mein 5V Netzteil liefert max 60A ... Also glaube schon, dass mehr als 40A gebraucht werden 🙈

Denke ich mir, ich geh erstmal mit 3 parallel ins Rennen mit meiner jetztigen PowerStage oder mit Quaxe PowerStage auf 1,2V*X Module hochskaliert.

Ich denke das sollte passen. Bin mal gespannt auf deine Files :)

Werd mich heut Abend auch mal wieder mit der Thematik auseinandersetzen

#7646188
Lesenswert?

Hallo Mampf,

hat bischen gedauert, bis ich meinen eigenen Qaxe in den Händen halten kann.

Aufau ist soweit fertig, bis aufs Gehäuse, das in Arbeit ist.

MC ist geflashed und Kühler montiert.

Kein Rauch beim Anschließen ans NT.

Stromverbrauch beim starten des Miners vai Python-skript 1A.

python pyminer.py -o solo.ckpool.org:3333 stratum+tcp://solo.ckpool.org:3333 -u bc....q1 -p x

1
>cat config.yml
2
debug_bm1366: false
3
verify_solo: true
4
miner: qaxe
5
suggest_difficulty: 2048
6

7
qaxe:
8
  name: QAxe
9
  chips: 4
10
  fan_speed_1: 1.0
11
  fan_speed_2: 1.0
12
  asic_frequency: 485
13
  extranonce2_interval: 1.9
14
  serial_port_asic: "/dev/ttyACM0"
15
  serial_port_ctrl: "/dev/ttyACM1"
1
Journalctl -f output:
2
Apr 16 15:33:02 linux-kwm1 kernel: usb 1-1: Product: Qaxe
3
Apr 16 15:33:02 linux-kwm1 kernel: usb 1-1: Manufacturer: Microengineer
4
Apr 16 15:33:02 linux-kwm1 kernel: usb 1-1: SerialNumber: rev2
5
Apr 16 15:33:02 linux-kwm1 kernel: cdc_acm 1-1:1.0: ttyACM0: USB ACM device
6
Apr 16 15:33:02 linux-kwm1 kernel: cdc_acm 1-1:1.2: ttyACM1: USB ACM device

Leider bekomme ich die Fehlermeldung - Anzahl der ASICS 0.

1
4-16 17:12:02,234 - DEBUG - rx len: b'\x00'
2
2024-04-16 17:12:07,234 - INFO - Initializing BM1366
3
2024-04-16 17:12:07,235 - DEBUG - -> 0b080110031a050430783030
4
2024-04-16 17:12:07,236 - DEBUG - rx len: b'\x02'
5
2024-04-16 17:12:07,236 - DEBUG - <- 0801
6
2024-04-16 17:12:12,737 - DEBUG - -> 0b080210031a050430783030
7
2024-04-16 17:12:12,738 - DEBUG - rx len: b'\x02'
8
2024-04-16 17:12:12,739 - DEBUG - <- 0802
9
2024-04-16 17:12:19,259 - ERROR - Uncaught exception
10
Traceback (most recent call last):
11
  File "/dev/shm/piaxe-miner-master/./pyminer.py", line 566, in <module>
12
    piaxeMiner.init()
13
  File "/dev/shm/piaxe-miner-master/piaxe/miner.py", line 590, in init
14
    chip_counter = bm1366.init(self.hardware.get_asic_frequency(), self.hardware.get_chip_count(), chips_enabled)
15
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
16
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 310, in init
17
    return send_init(frequency, expected, chips_enabled)
18
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
19
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 257, in send_init
20
    raise Exception(f"chips mismatch. expected: {expected}, actual: {chip_counter}")
21
Exception: chips mismatch. expected: 4, actual: 0

Bevor ich ans Messen gehe, wollte ich Dich nach den sinnvollen Testpunkten fragen.

Offensichtlich klappt noch nicht die Kommunikation zu den ASICs.

Im Anhang einige Bilder zum Aufbau.

LG Markus

Angehängte Dateien:
#7646924
Lesenswert?

Noch etwas mehr debug Daten mit dem Switch in der config.yml

debug_bm1366: true

1
(piaxe-miner-master) mw@localhost:/dev/shm/piaxe-miner-master> ./start_mainnet_publicpool.sh
2
2024-04-17 19:12:03,597 - DEBUG - -> 0b10011a0706080110641864
3
2024-04-17 19:12:03,599 - DEBUG - rx len: b'\x00'
4
2024-04-17 19:12:08,599 - INFO - Initializing BM1366
5
2024-04-17 19:12:08,600 - DEBUG - -> 0b080110031a050430783030
6
2024-04-17 19:12:08,601 - DEBUG - rx len: b'\x02'
7
2024-04-17 19:12:08,601 - DEBUG - <- 0801
8
2024-04-17 19:12:14,102 - DEBUG - -> 0b080210031a050430783030
9
2024-04-17 19:12:14,104 - DEBUG - rx len: b'\x02'
10
2024-04-17 19:12:14,104 - DEBUG - <- 0802
11
2024-04-17 19:12:19,605 - DEBUG - -> 55aa510900a49000ffff1c
12
2024-04-17 19:12:19,606 - DEBUG - -> 55aa510900a49000ffff1c
13
2024-04-17 19:12:19,609 - DEBUG - -> 55aa510900a49000ffff1c
14
2024-04-17 19:12:19,611 - DEBUG - -> 55aa520500000a
15
2024-04-17 19:12:19,623 - DEBUG - serial_rx: 11
16
2024-04-17 19:12:19,623 - DEBUG - <- aa551300000055660000aa
17
2024-04-17 19:12:20,625 - DEBUG - -> 55aa5305000003
18
2024-04-17 19:12:20,626 - ERROR - Uncaught exception
19
Traceback (most recent call last):
20
  File "/dev/shm/piaxe-miner-master/./pyminer.py", line 566, in <module>
21
    piaxeMiner.init()
22
  File "/dev/shm/piaxe-miner-master/piaxe/miner.py", line 590, in init
23
    chip_counter = bm1366.init(self.hardware.get_asic_frequency(), self.hardware.get_chip_count(), chips_enabled)
24
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
25
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 310, in init
26
    return send_init(frequency, expected, chips_enabled)
27
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
28
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 257, in send_init
29
    raise Exception(f"chips mismatch. expected: {expected}, actual: {chip_counter}")
30
Exception: chips mismatch. expected: 4, actual: 0

Falls jemand noch diesen Thread mitlesen tut.

Markus

PS.:

Jetzt habe ich das Oszi rausgeholt und messe mal die Signale zu den ASICs.

Melde mich später.

#7647002
Lesenswert?

Die ersten Messungen zu meinem QAXE:

TP1: 5.088V TP14: 1.269V U30 3.3V

Unterseite bei den ASICs:

TP12: TP11: TP7: TP5: TP2: TP3: TP6: TP9: TP13:

siehe DSO Bilder.

Gruß Markus

OP Persönliche Seite #7647965
Lesenswert?

Oh sorry, hatte vergessen hier mal wieder reinzukucken 🙈

Markus W. schrieb:

2024-04-17 19:12:19,623 - DEBUG - serial_rx: 11 2024-04-17 19:12:19,623 - DEBUG - <- aa551300000055660000aa

Hmm, das ist seltsam ... da scheint irgendwas mit serial nicht zu passen 🤔

Das sollte sowas wie "aa55136600000000000005" sein und sich dann insgesamt 4 mal wiederholen 🤔

Muss mal nachdenken, wie das passieren kann 🤔 Eventuell hab ich eine Idee ... Die ASICs würde ich, wenn ich du wäre, nicht mehr anfassen. Das geht schon fast ...

Könntest du bitte den den commit-hash vom Stand des QAxe Repositories hier posten? Dann kann ich kucken, welchen Stand der Firmware du geflasht hast.

#7648047
Lesenswert?

Hallo Thomas,

danke fürs Reinschauen. Ich habe Deine QAXE githup Repos immer als zip-File heruntergeladen. Wenn Du aber den Verdacht hast, dass mein Problem in der FW und nicht HW liegt, kann ich auch gerne ein git clone machen um die FW herunter zu laden und dann neu flashen.

Im Augenblick kann ich kein "commit-hash" erstellen.

Melde mich wieder, wenn ich das REPO geklone habe und die FW neu aufgespielt habe.

Muss ich bei der FW was beachten? Habe die PCB Version 0.2, weshalb ich auch aus diesem Repo die FW gebaut habe. Sollte ich die V.3.2 nehmen?

LG Markus

PS.: habe gerade das neuste Repo vom QAXE geclont.

commit c2a55399750ce480e7872cc3ef803c5b26006bd7 (HEAD -> main, origin/main, origin/HEAD) Author: Thomas Shufps shufps80@gmail.com Date: Wed Apr 3 08:04:14 2024 +0200

git submodule update Cloning into '/dev/shm/qaxe/firmware/embassy'... Submodule path 'firmware/embassy': checked out '0549dd5fd7d874f4f071047db12702f58009931b' mw@linux-kwm1:/dev/shm/qaxe rustup target add thumbv7m-none-eabi info: component 'rust-std' for target 'thumbv7m-none-eabi' is up to date mw@linux-kwm1:/dev/shm/qaxe cd firmware/ embassy/ fw-L052K8/ fw-L072CB/ fw-L151C8/ fw-L151CC/

Welche FW ist zu nehmen (sind das die MC-Versionen?)

Bei mir wäre es der 151C8.

file qaxe-fw-L151C8.bin qaxe-fw-L151C8.bin: ARM Cortex-M firmware, initial SP at 0x20004000, reset at 0x080000f4, NMI at 0x0800a2a0, HardFault at 0x0800cdaa, SVCall at 0x0800a2a0, PendSV at 0x0800a2a0

#7648104
Lesenswert?

Leider klappt es immer noch nicht!

Habe gerade die FW direct aus dem Brunch V3.2 geclonet und gebaut.

1
mw@linux-kwm1:/dev/shm/qaxe/firmware/fw-L151C8
2
>cargo objcopy --release --bin qaxe -- -O binary qaxe-fw-L151C8.bin
3
   Compiling defmt-macros v0.3.6
4
   Compiling defmt v0.3.5
5
   Compiling embedded-io v0.6.1
6
   Compiling embassy-net-driver v0.2.0 (/dev/shm/qaxe/firmware/embassy/embassy-net-driver)
7
   Compiling embassy-usb-driver v0.1.0 (/dev/shm/qaxe/firmware/embassy/embassy-usb-driver)
8
   Compiling embassy-time v0.3.0 (/dev/shm/qaxe/firmware/embassy/embassy-time)
9
   Compiling embassy-hal-internal v0.1.0 (/dev/shm/qaxe/firmware/embassy/embassy-hal-internal)
10
   Compiling embassy-executor v0.5.0 (/dev/shm/qaxe/firmware/embassy/embassy-executor)
11
   Compiling panic-probe v0.3.1
12
   Compiling defmt-rtt v0.4.0
13
   Compiling embedded-io-async v0.6.1
14
   Compiling embassy-sync v0.5.0 (/dev/shm/qaxe/firmware/embassy/embassy-sync)
15
   Compiling embassy-embedded-hal v0.1.0 (/dev/shm/qaxe/firmware/embassy/embassy-embedded-hal)
16
   Compiling embassy-net-driver-channel v0.2.0 (/dev/shm/qaxe/firmware/embassy/embassy-net-driver-channel)
17
   Compiling embassy-usb v0.1.0 (/dev/shm/qaxe/firmware/embassy/embassy-usb)
18
   Compiling embassy-stm32 v0.1.0 (/dev/shm/qaxe/firmware/embassy/embassy-stm32)
19
   Compiling embassy-stm32l1-examples v0.1.0 (/dev/shm/qaxe/firmware/fw-L151C8)
20
    Finished release [optimized + debuginfo] target(s) in 5.84s
21

22

23
mw@linux-kwm1:/dev/shm/qaxe/firmware/fw-L151C8
24
>ls -l
25
total 104
26
-rw------- 1 mw users   171 Apr 19 09:18 build.rs
27
-rwx------ 1 mw users    60 Apr 19 09:18 build.sh
28
-rw------- 1 mw users 22397 Apr 19 09:18 Cargo.lock
29
-rw------- 1 mw users  1347 Apr 19 09:18 Cargo.toml
30
-rwx------ 1 mw users 61416 Apr 19 09:42 qaxe-fw-L151C8.bin
31
-rw------- 1 mw users    68 Apr 19 09:18 README.md
32
-rwx------ 1 mw users    58 Apr 19 09:18 run.sh
33
drwx------ 3 mw users    60 Apr 19 09:18 src
34
drwx------ 4 mw users   120 Apr 19 09:37 target
35

36
>file qaxe-fw-L151C8.bin
37
qaxe-fw-L151C8.bin: ARM Cortex-M firmware, initial SP at 0x20004000, reset at 0x080000f4, NMI at 0x0800a2a0, HardFault at 0x0800cdaa, SVCall at 0x0800a2a0, PendSV at 0x0800a2a0
38

39
>st-flash --connect-under-reset write /dev/shm/qaxe/firmware/fw-L151C8/qaxe-fw-L151C8.bin 0x8000000
40
st-flash 1.8.0-13-g40ee5f4
41
2024-04-19T10:02:26 WARN common.c: NRST is not connected
42
2024-04-19T10:02:26 ERROR common.c: Soft reset failed: error write to AIRCR
43
2024-04-19T10:02:26 INFO common.c: STM32L1xx_Cat_2: 32 KiB SRAM, 64 KiB flash in at least 256 byte pages.
44
file /dev/shm/qaxe/firmware/fw-L151C8/qaxe-fw-L151C8.bin md5 checksum: a6f2cc6014e7fce45c36346d29e959c, stlink checksum: 0x0061ae42
45
2024-04-19T10:02:26 INFO common_flash.c: Attempting to write 61416 (0xefe8) bytes to stm32 address: 134217728 (0x8000000)
46
-> Flash page at 0x8000000 erased (size: 0x100)
47
-> Flash page at 0x8000100 erased (size: 0x100)
48
-> Flash page at 0x8000200 erased (size: 0x100)
49
...
50
-> Flash page at 0x800ee00 erased (size: 0x100)
51
-> Flash page at 0x800ef00 erased (size: 0x100)
52

53
2024-04-19T10:02:27 INFO flash_loader.c: Starting Flash write for L0
54
2024-04-19T10:02:27 INFO flash_loader.c: Successfully loaded flash loader in sram
55
2024-04-19T10:02:27 INFO flash_loader.c: Clear DFSR
56
  1/479 halfpages written
57
  2/479 halfpages written
58
...
59
478/479 halfpages written
60
479/479 halfpages written
61

62
2024-04-19T10:02:36 INFO common_flash.c: Starting verification of write complete
63
2024-04-19T10:02:38 INFO common_flash.c: Flash written and verified! jolly good!
64

65

66
cat ./start_mainnet_publicpool.sh
67
python3 ./pyminer.py -o stratum+tcp://solo.ckpool.org:3333 -d -P -u bc1....q1 -p x
68

69
>./start_mainnet_publicpool.sh
70
2024-04-19 10:08:02,822 - DEBUG - -> 0b10011a0706080110641864
71
2024-04-19 10:08:02,823 - DEBUG - rx len: b'\x00'
72
2024-04-19 10:08:07,824 - INFO - Initializing BM1366
73
2024-04-19 10:08:07,824 - DEBUG - -> 0b080110031a050430783030
74
2024-04-19 10:08:07,825 - DEBUG - rx len: b'\x02'
75
2024-04-19 10:08:07,825 - DEBUG - <- 0801
76
2024-04-19 10:08:13,326 - DEBUG - -> 0b080210031a050430783030
77
2024-04-19 10:08:13,327 - DEBUG - rx len: b'\x02'
78
2024-04-19 10:08:13,328 - DEBUG - <- 0802
79
2024-04-19 10:08:19,848 - ERROR - Uncaught exception
80
Traceback (most recent call last):
81
  File "/dev/shm/piaxe-miner-master/./pyminer.py", line 566, in <module>
82
    piaxeMiner.init()
83
  File "/dev/shm/piaxe-miner-master/piaxe/miner.py", line 590, in init
84
    chip_counter = bm1366.init(self.hardware.get_asic_frequency(), self.hardware.get_chip_count(), chips_enabled)
85
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
86
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 310, in init
87
    return send_init(frequency, expected, chips_enabled)
88
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
89
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 257, in send_init
90
    raise Exception(f"chips mismatch. expected: {expected}, actual: {chip_counter}")
91
Exception: chips mismatch. expected: 4, actual: 0
92
(piaxe-miner-master) mw@linux-kwm1:/dev/shm/piaxe-miner-master

Hast Du noch eine Idee. Eventuell ist ja doch noch was auf dem PCB wie es nicht sein soll.

LG Markus

Ein erneuter Versuch mit dem BM1366 Debug Flag in der config.yml

1
>./start_mainnet_publicpool.sh
2
2024-04-19 10:23:08,389 - DEBUG - -> 0b10011a0706080110641864
3
2024-04-19 10:23:08,390 - DEBUG - rx len: b'\x00'
4
2024-04-19 10:23:13,391 - INFO - Initializing BM1366
5
2024-04-19 10:23:13,391 - DEBUG - -> 0b080110031a050430783030
6
2024-04-19 10:23:13,392 - DEBUG - rx len: b'\x02'
7
2024-04-19 10:23:13,392 - DEBUG - <- 0801
8
2024-04-19 10:23:18,893 - DEBUG - -> 0b080210031a050430783030
9
2024-04-19 10:23:18,895 - DEBUG - rx len: b'\x02'
10
2024-04-19 10:23:18,895 - DEBUG - <- 0802
11
2024-04-19 10:23:24,396 - DEBUG - -> 55aa510900a49000ffff1c
12
2024-04-19 10:23:24,397 - DEBUG - -> 55aa510900a49000ffff1c
13
2024-04-19 10:23:24,399 - DEBUG - -> 55aa510900a49000ffff1c
14
2024-04-19 10:23:24,402 - DEBUG - -> 55aa520500000a
15
2024-04-19 10:23:24,413 - DEBUG - serial_rx: 11
16
2024-04-19 10:23:24,414 - DEBUG - <- aa55660000051300000055
17
2024-04-19 10:23:25,415 - DEBUG - -> 55aa5305000003
18
2024-04-19 10:23:25,416 - ERROR - Uncaught exception
19
Traceback (most recent call last):
20
  File "/dev/shm/piaxe-miner-master/./pyminer.py", line 566, in <module>
21
    piaxeMiner.init()
22
  File "/dev/shm/piaxe-miner-master/piaxe/miner.py", line 590, in init
23
    chip_counter = bm1366.init(self.hardware.get_asic_frequency(), self.hardware.get_chip_count(), chips_enabled)
24
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
25
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 310, in init
26
    return send_init(frequency, expected, chips_enabled)
27
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
28
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 257, in send_init
29
    raise Exception(f"chips mismatch. expected: {expected}, actual: {chip_counter}")
30
Exception: chips mismatch. expected: 4, actual: 0
OP Persönliche Seite #7648140
Lesenswert?

Markus W. schrieb:

2024-04-19 10:23:24,414 - DEBUG - <- aa55660000051300000055

Die firmware die du geflasht hast, sollte funktionieren.

Ich frag mich gerade, was es für Gründe geben könnte, dass was über serial "verschluckt" wird.

Kannst du mal die temp-sensoren in der firmware tot legen?

Das wäre quasi: https://github.com/shufps/qaxe/blob/main/firmware/fw-L151C8/src/bin/qaxe.rs#L583

Kannst du da die for-schleife löschen / auskommentieren und es nochmal versuchen?

Die Temp-Sensoren arbeiten "blocking", evtl stimmt mit ihnen etwas nicht ...

#7648166
Lesenswert?

Hallo Thomas,

danke - werde ich machen und mich dann wieder melden.

1
       for i in 0..2 {
2
            continue;

Einfach gleich wieder raus zu gehen reicht doch auch?

LG Markus

1
#[embassy_executor::task]
2
async fn temp_manager(mut i2c: I2c<'static, I2C2>) {
3
    loop {
4
        Timer::after_millis(5000).await;
5

6
//       for i in 0..2 {
7
//          let mut data = [0u8; 2];
8
//          if let Err(e) = i2c.blocking_read(0x48 + i, &mut data) {
9
//              error!("i2c error: {:?}", e);
10
//              continue;
11
//          }
12
//
13
//          let mut temp_data = ((data[0] as u16) << 4) | ((data[1] as u16) >> 4);
14
//
15
//          if temp_data > 2047 {
16
//              temp_data -= 4096
17
//          }
18
//
19
//          info!("read temp{}: {}", i + 1, temp_data);
20
//
21
//          if i == 0 {
22
//              let mut temp1 = TEMP1.lock().await;
23
//              *temp1 = temp_data;
24
//          } else {
25
//              let mut temp2 = TEMP2.lock().await;
26
//              *temp2 = temp_data;
27
//          }
28
//      }
29

30
    }
31
}
32

33

34

35
>cargo objcopy --release --bin qaxe -- -O binary qaxe-fw-L151C8-notmps.bin
36
   Compiling embassy-stm32l1-examples v0.1.0 (/dev/shm/qaxe/firmware/fw-L151C8)
37
    Finished release [optimized + debuginfo] target(s) in 1.24s
38
warning: unused variable: `i2c`
39
   --> src/bin/qaxe.rs:579:27
40
    |
41
579 | async fn temp_manager(mut i2c: I2c<'static, I2C2>) {
42
    |                           ^^^ help: if this is intentional, prefix it with an underscore: `_i2c`
43
    |
44
    = note: `#[warn(unused_variables)]` on by default
45

46
warning: variable does not need to be mutable
47
   --> src/bin/qaxe.rs:579:23
48
    |
49
579 | async fn temp_manager(mut i2c: I2c<'static, I2C2>) {
50
    |                       ----^^^
51
    |                       |
52
    |                       help: remove this `mut`
53
    |
54
    = note: `#[warn(unused_mut)]` on by default
55

56
warning: 2 warnings emitted
57

58
>st-flash --connect-under-reset write /dev/shm/qaxe/firmware/fw-L151C8/qaxe-fw-L151C8-notmps.bin 0x8000000
59
st-flash 1.8.0-13-g40ee5f4
60
2024-04-19T11:30:23 WARN common.c: NRST is not connected
61
2024-04-19T11:30:23 ERROR common.c: Soft reset failed: timeout
62
2024-04-19T11:30:23 INFO common.c: STM32L1xx_Cat_2: 32 KiB SRAM, 64 KiB flash in at least 256 byte pages.
63
file /dev/shm/qaxe/firmware/fw-L151C8/qaxe-fw-L151C8-notmps.bin md5 checksum: 9ed16821d6a79af24b5aa5bd2bdd9758, stlink checksum: 0x005fad49
64
2024-04-19T11:30:23 INFO common_flash.c: Attempting to write 60264 (0xeb68) bytes to stm32 address: 134217728 (0x8000000)
65
-> Flash page at 0x8000000 erased (size: 0x100)
66
-> Flash page at 0x8000100 erased (size: 0x100)
67
...
68
-> Flash page at 0x800ea00 erased (size: 0x100)
69
-> Flash page at 0x800eb00 erased (size: 0x100)
70

71
2024-04-19T11:30:25 INFO flash_loader.c: Starting Flash write for L0
72
2024-04-19T11:30:25 INFO flash_loader.c: Successfully loaded flash loader in sram
73
2024-04-19T11:30:25 INFO flash_loader.c: Clear DFSR
74
  1/470 halfpages written
75
  2/470 halfpages written
76
...
77
469/470 halfpages written
78
470/470 halfpages written
79

80
2024-04-19T11:30:34 INFO common_flash.c: Starting verification of write complete
81
2024-04-19T11:30:35 INFO common_flash.c: Flash written and verified! jolly good!
82

83
(piaxe-miner-master) mw@linux-kwm1:/dev/shm/piaxe-miner-master
84
>./start_mainnet_publicpool.sh
85
2024-04-19 11:31:31,032 - DEBUG - -> 0b10011a0706080110641864
86
2024-04-19 11:31:31,033 - DEBUG - rx len: b'\x00'
87
2024-04-19 11:31:36,033 - INFO - Initializing BM1366
88
2024-04-19 11:31:36,034 - DEBUG - -> 0b080110031a050430783030
89
2024-04-19 11:31:36,035 - DEBUG - rx len: b'\x02'
90
2024-04-19 11:31:36,035 - DEBUG - <- 0801
91
2024-04-19 11:31:41,536 - DEBUG - -> 0b080210031a050430783030
92
2024-04-19 11:31:41,537 - DEBUG - rx len: b'\x02'
93
2024-04-19 11:31:41,537 - DEBUG - <- 0802
94
2024-04-19 11:31:47,038 - DEBUG - -> 55aa510900a49000ffff1c
95
2024-04-19 11:31:47,039 - DEBUG - -> 55aa510900a49000ffff1c
96
2024-04-19 11:31:47,041 - DEBUG - -> 55aa510900a49000ffff1c
97
2024-04-19 11:31:47,044 - DEBUG - -> 55aa520500000a
98
2024-04-19 11:31:47,055 - DEBUG - serial_rx: 11
99
2024-04-19 11:31:47,055 - DEBUG - <- aa55660000051300000055
100
2024-04-19 11:31:48,057 - DEBUG - -> 55aa5305000003
101
2024-04-19 11:31:48,058 - ERROR - Uncaught exception
102
Traceback (most recent call last):
103
  File "/dev/shm/piaxe-miner-master/./pyminer.py", line 566, in <module>
104
    piaxeMiner.init()
105
  File "/dev/shm/piaxe-miner-master/piaxe/miner.py", line 590, in init
106
    chip_counter = bm1366.init(self.hardware.get_asic_frequency(), self.hardware.get_chip_count(), chips_enabled)
107
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
108
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 310, in init
109
    return send_init(frequency, expected, chips_enabled)
110
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
111
  File "/dev/shm/piaxe-miner-master/piaxe/bm1366.py", line 257, in send_init
112
    raise Exception(f"chips mismatch. expected: {expected}, actual: {chip_counter}")
113
Exception: chips mismatch. expected: 4, actual: 0

Hat leider noch nicht geholfen.

#7648773
Lesenswert?

Danke für Deine Mühe.

Wie hast Du denn Deine QAXE in Betrieb genommen? Gibt es noch eine andere Variante das FW Binary zu erzeugen?

LG Markus

PS.: Hast Du einen kleinen FW-Code, mit dem man die Kommunikation zu den ASICs testen kann? Dann könnte ich am Montag die restlichen QAXE testen, ob sie richtig bestückt sind.

OP Persönliche Seite #7648790
Lesenswert?

Markus W. schrieb:

Wie hast Du denn Deine QAXE in Betrieb genommen?

per SWD.

Gibt es noch eine andere Variante das FW Binary zu erzeugen?

Jap, da scheint das richtige Binary rauszukommen:

1
# erst elf-file builden
2
./build.sh
3

4
# dann nach binary
5
arm-none-eabi-objcopy -O binary  -S ./target/thumbv7m-none-eabi/release/qaxe qaxe.bin

Und das geht dann ganz sicher auch mit dfu-util!

Ich weiß nicht, was cargo objcopy macht, aber es scheint es wohl nicht nur zu dumpen sondern anders zu kompilieren.

#7648833
Lesenswert?

;-))))))))))))))))))))

2024-04-19 22:46:28,253 - INFO - 4 chips were found! 2024-04-19 22:46:28,253 - INFO - Setting job ASIC mask to 511 2024-04-19 22:46:28,253 - DEBUG - -> 55aa51090014000080ff04 2024-04-19 22:46:28,254 - DEBUG - -> 0b080310021a050430783030 2024-04-19 22:46:28,255 - DEBUG - rx len: b'\r' 2024-04-19 22:46:28,255 - INFO - receiving thread started ...

Details im angehängtem Log.

Verstehe noch nicht alles, bin aber wohl Dank Mampf einen Schritt weiter und wohl möglich auch am Ziel.

LG+Besten Dank! Markus

Noch ein Nachtrag,

Komme zum Miningpool noch nicht hin - Muss der Port 3333 in dem Router freigeschaltet werden, oder habe ich eine Problem beim Rückkanal?

2024-04-19 23:17:21,290 - INFO - Starting server on solo.ckpool.org:3333 2024-04-19 23:17:21,519 - ERROR - Exception in RPC thread: tcp connection closed ... 2024-04-19 23:17:21,519 - ERROR - error flag set ... ending handle_incoming_rpc thread 2024-04-19 23:17:22,184 - INFO - temperature and voltage: {'temp': [29.75, 67.375, 0, 0], 'voltage': [0, 0, 0, 0]} 2024-04-19 23:17:23,165 - INFO - no job ...

Habe auch bei einem weiteren Pool die connection Errors.

2024-04-19 23:41:12,243 - INFO - Starting server on sha256.auto.nicehash.com:9200 2024-04-19 23:41:12,258 - DEBUG - send successful 2024-04-19 23:41:12,258 - DEBUG - JSON-RPC Server < {"id": 1, "method": "mining.suggest_difficulty", "params": [2048]} 2024-04-19 23:41:12,259 - DEBUG - send successful 2024-04-19 23:41:12,259 - DEBUG - JSON-RPC Server < {"id": 2, "method": "mining.subscribe", "params": ["QAxe/0.1"]} 2024-04-19 23:41:12,259 - DEBUG - waiting for error 2024-04-19 23:41:12,287 - ERROR - Exception in RPC thread: tcp connection closed ... 2024-04-19 23:41:12,287 - ERROR - error flag set ... ending handle_incoming_rpc thread 2024-04-19 23:41:12,288 - DEBUG - error received 2024-04-19 23:41:12,288 - DEBUG - joining rpc_thread 2024-04-19 23:41:12,288 - DEBUG - joining done

Angehängte Dateien:
OP Persönliche Seite #7649054
Lesenswert?

Markus W. schrieb:

2024-04-19 23:17:21,290 - INFO - Starting server on solo.ckpool.org:3333

Das sind zwei Sachen, zum einen die "solo-mining-verifikation", die reingrätscht, weil ckpool 2% abzweigt und zum anderen kennt ckpool das "suggest_difficulty" nicht.

Kannst du zB public-pool benutzen oder die solo-verifikation in der config.yml abschalten und "suggest_difficulty" in der config auskommentieren.

Ich würde Public-Pool empfehlen ...

Also:

1
verify_solo: false
2
#suggest_difficulty: 2048
#7649186
Lesenswert?

Hallo Mampf,

beim solo.ckpool.org bekomme ich noch keinen Durchbruch. Meine piaxe kann ich sehen aber nicht den qaxe.

Siehe auch Anhang.

1
2024-04-20 13:03:38,794 - DEBUG - work received 48
2
2024-04-20 13:03:38,794 - DEBUG - header: 00c0c921040ea97d8faa227247ba730e0ddc159cc5bbc5549828010000000000000000008300a59ef5c5e29f03c5d0546e427bf6bf6ac0f3b506a306b8ff5c726a5234b9ffa02366194203175602f317
3
2024-04-20 13:03:38,795 - DEBUG - network-target: 0000000000000000000342190000000000000000000000000000000000000000 (78)
4
2024-04-20 13:03:38,795 - DEBUG - pool-target:    0000000000068db22d0e56040000000000000000000000000000000000000000 (45)
5
2024-04-20 13:03:38,795 - DEBUG - found hash:     0000000000029fc15341355b99c908255031a4a4a2228f0c66da692ce6bb0770 (46)
6
2024-04-20 13:03:38,795 - DEBUG - mask_nonce:   0001 0111 1111 0011 0000 0010 0101 0110  (17f30256)
7
2024-04-20 13:03:38,795 - DEBUG - mask_version: 0000 1001 1100 0001 1100 0000 0000 0000  (09c1c000)
8
2024-04-20 13:03:38,795 - DEBUG - result from asic 0
9
2024-04-20 13:03:38,795 - DEBUG - hash rate: 71.582788 GH/s
10
2024-04-20 13:03:38,796 - INFO - valid result
11
2024-04-20 13:03:38,796 - ERROR - send failed: [Errno 9] Bad file descriptor
12
2024-04-20 13:03:38,797 - DEBUG - JSON-RPC Server < {"id": 3, "method": "mining.submit", "params": [null, "64851638000e8678", "000000005ee429ee", "6623a0ff", "17f30256", "01c9c000"]}
13
2024-04-20 13:03:39,086 - DEBUG - -> 0b083610021a050430783030

LG Markus

Angehängte Dateien:
OP Persönliche Seite #7649257
Lesenswert?

Markus W. schrieb:

2024-04-20 13:03:38,796 - ERROR - send failed: [Errno 9] Bad file descriptor

Ööööööh ... hmm ...

Was ist denn das für ein seltsamer Fehler ... 🤔

Versuch es bitte mal mit public pool:

1
python3 ./pyminer.py -o stratum+tcp://public-pool.io:21496 -d -P -u YOURBTCADDRESS.qaxe -p x -l mainnet.log

Aber aktivier das "suggest_difficulty" wieder dann, weil der fängt dann mit 10000000 oder so an, was totaler Blödsinn ist, imho.

#7649285
Lesenswert?

Hallo Mampf,

beim publoc-pool bekomme ich nach einer weile Shutdowns wegen Temperatur-Überschreitung, obwohl die Temp. auf dem PCB und dem Kühlerblech kaum wahrnehmbar ist.

1
2024-04-20 13:42:43,045 - INFO - Setting Frequency to 468.75MHz (468.75)
2
2024-04-20 13:42:43,146 - INFO - Setting Frequency to 475.00MHz (475.00)
3
2024-04-20 13:42:43,246 - INFO - 4 chips were found!
4
2024-04-20 13:42:43,246 - INFO - Setting job ASIC mask to 511
5
2024-04-20 13:42:43,247 - INFO - receiving thread started ...
6
2024-04-20 13:42:43,247 - INFO - job thread started ...
7
2024-04-20 13:42:43,248 - INFO - temperature and voltage: {'temp': [23.5, 36.1875, 0, 0], 'voltage': [0, 0, 0, 0]}
8
2024-04-20 13:42:43,248 - INFO - uptime counter thread started ...
9
2024-04-20 13:42:43,248 - INFO - LED thread started ...
10
2024-04-20 13:42:43,248 - INFO - Starting server on public-pool.io:21496
11
2024-04-20 13:42:43,699 - INFO - Setting job ASIC mask to 524287
12
2024-04-20 13:42:43,844 - INFO - starting new job 1971a13
13
2024-04-20 13:42:44,748 - INFO - temperature and voltage: {'temp': [24.4375, 40.25, 0, 0], 'voltage': [0, 0, 0, 0]}
14
2024-04-20 13:42:46,249 - INFO - temperature and voltage: {'temp': [24.4375, 40.25, 0, 0], 'voltage': [0, 0, 0, 0]}
15
2024-04-20 13:42:47,750 - INFO - temperature and voltage: {'temp': [24.4375, 40.25, 0, 0], 'voltage': [0, 0, 0, 0]}
16
2024-04-20 13:42:49,251 - INFO - temperature and voltage: {'temp': [25.8125, 46.6875, 0, 0], 'voltage': [0, 0, 0, 0]}
17
2024-04-20 13:42:50,751 - INFO - temperature and voltage: {'temp': [25.8125, 46.6875, 0, 0], 'voltage': [0, 0, 0, 0]}
18
2024-04-20 13:42:52,253 - INFO - temperature and voltage: {'temp': [25.8125, 46.6875, 0, 0], 'voltage': [0, 0, 0, 0]}
19
2024-04-20 13:42:53,753 - INFO - temperature and voltage: {'temp': [26.875, 52.5, 0, 0], 'voltage': [0, 0, 0, 0]}
20
2024-04-20 13:42:55,254 - INFO - temperature and voltage: {'temp': [26.875, 52.5, 0, 0], 'voltage': [0, 0, 0, 0]}
21
2024-04-20 13:42:56,755 - INFO - temperature and voltage: {'temp': [26.875, 52.5, 0, 0], 'voltage': [0, 0, 0, 0]}
22
2024-04-20 13:42:58,255 - INFO - temperature and voltage: {'temp': [26.875, 52.5, 0, 0], 'voltage': [0, 0, 0, 0]}
23
2024-04-20 13:42:59,756 - INFO - temperature and voltage: {'temp': [27.625, 54.9375, 0, 0], 'voltage': [0, 0, 0, 0]}
24
2024-04-20 13:43:01,257 - INFO - temperature and voltage: {'temp': [27.625, 54.9375, 0, 0], 'voltage': [0, 0, 0, 0]}
25
2024-04-20 13:43:02,758 - INFO - temperature and voltage: {'temp': [27.625, 54.9375, 0, 0], 'voltage': [0, 0, 0, 0]}
26
2024-04-20 13:43:04,258 - INFO - temperature and voltage: {'temp': [28.25, 56.1875, 0, 0], 'voltage': [0, 0, 0, 0]}
27
2024-04-20 13:43:05,759 - INFO - temperature and voltage: {'temp': [28.25, 56.1875, 0, 0], 'voltage': [0, 0, 0, 0]}
28
2024-04-20 13:43:07,260 - INFO - temperature and voltage: {'temp': [28.25, 56.1875, 0, 0], 'voltage': [0, 0, 0, 0]}
29
2024-04-20 13:43:08,760 - INFO - temperature and voltage: {'temp': [28.6875, 58.3125, 0, 0], 'voltage': [0, 0, 0, 0]}
30
2024-04-20 13:43:10,261 - INFO - temperature and voltage: {'temp': [28.6875, 58.3125, 0, 0], 'voltage': [0, 0, 0, 0]}
31
2024-04-20 13:43:11,762 - INFO - temperature and voltage: {'temp': [28.6875, 58.3125, 0, 0], 'voltage': [0, 0, 0, 0]}
32
2024-04-20 13:43:13,263 - INFO - temperature and voltage: {'temp': [28.6875, 58.3125, 0, 0], 'voltage': [0, 0, 0, 0]}
33
2024-04-20 13:43:14,764 - INFO - temperature and voltage: {'temp': [29.125, 60.5, 0, 0], 'voltage': [0, 0, 0, 0]}
34
2024-04-20 13:43:16,264 - INFO - temperature and voltage: {'temp': [29.125, 60.5, 0, 0], 'voltage': [0, 0, 0, 0]}
35
2024-04-20 13:43:17,765 - INFO - temperature and voltage: {'temp': [29.125, 60.5, 0, 0], 'voltage': [0, 0, 0, 0]}
36
2024-04-20 13:43:19,266 - INFO - temperature and voltage: {'temp': [29.4375, 62.625, 0, 0], 'voltage': [0, 0, 0, 0]}
37
2024-04-20 13:43:20,766 - INFO - temperature and voltage: {'temp': [29.4375, 62.625, 0, 0], 'voltage': [0, 0, 0, 0]}
38
2024-04-20 13:43:22,267 - INFO - temperature and voltage: {'temp': [29.4375, 62.625, 0, 0], 'voltage': [0, 0, 0, 0]}
39
2024-04-20 13:43:23,768 - INFO - temperature and voltage: {'temp': [29.6875, 64.3125, 0, 0], 'voltage': [0, 0, 0, 0]}
40
2024-04-20 13:43:25,269 - INFO - temperature and voltage: {'temp': [29.6875, 64.3125, 0, 0], 'voltage': [0, 0, 0, 0]}
41
2024-04-20 13:43:26,770 - INFO - temperature and voltage: {'temp': [29.6875, 64.3125, 0, 0], 'voltage': [0, 0, 0, 0]}
42
2024-04-20 13:43:28,270 - INFO - temperature and voltage: {'temp': [29.6875, 64.3125, 0, 0], 'voltage': [0, 0, 0, 0]}
43
2024-04-20 13:43:29,771 - INFO - temperature and voltage: {'temp': [30.0, 65.625, 0, 0], 'voltage': [0, 0, 0, 0]}
44
2024-04-20 13:43:31,272 - INFO - temperature and voltage: {'temp': [30.0, 65.625, 0, 0], 'voltage': [0, 0, 0, 0]}
45
2024-04-20 13:43:32,772 - INFO - temperature and voltage: {'temp': [30.0, 65.625, 0, 0], 'voltage': [0, 0, 0, 0]}
46
2024-04-20 13:43:34,273 - INFO - temperature and voltage: {'temp': [30.25, 66.6875, 0, 0], 'voltage': [0, 0, 0, 0]}
47
2024-04-20 13:43:35,775 - INFO - temperature and voltage: {'temp': [30.25, 66.6875, 0, 0], 'voltage': [0, 0, 0, 0]}
48
2024-04-20 13:43:37,275 - INFO - temperature and voltage: {'temp': [30.25, 66.6875, 0, 0], 'voltage': [0, 0, 0, 0]}
49
2024-04-20 13:43:38,776 - INFO - temperature and voltage: {'temp': [30.4375, 67.75, 0, 0], 'voltage': [0, 0, 0, 0]}
50
2024-04-20 13:43:40,277 - INFO - temperature and voltage: {'temp': [30.4375, 67.75, 0, 0], 'voltage': [0, 0, 0, 0]}
51
2024-04-20 13:43:40,394 - INFO - starting new job 1971a2c
52
2024-04-20 13:43:41,777 - INFO - temperature and voltage: {'temp': [30.4375, 67.75, 0, 0], 'voltage': [0, 0, 0, 0]}
53
2024-04-20 13:43:43,278 - INFO - temperature and voltage: {'temp': [30.4375, 67.75, 0, 0], 'voltage': [0, 0, 0, 0]}
54
2024-04-20 13:43:44,779 - INFO - temperature and voltage: {'temp': [30.625, 68.9375, 0, 0], 'voltage': [0, 0, 0, 0]}
55
2024-04-20 13:43:46,279 - INFO - temperature and voltage: {'temp': [30.625, 68.9375, 0, 0], 'voltage': [0, 0, 0, 0]}
56
2024-04-20 13:43:47,780 - INFO - temperature and voltage: {'temp': [30.625, 68.9375, 0, 0], 'voltage': [0, 0, 0, 0]}
57
2024-04-20 13:43:49,281 - INFO - temperature and voltage: {'temp': [30.75, 70.125, 0, 0], 'voltage': [0, 0, 0, 0]}
58
2024-04-20 13:43:49,281 - ERROR - too hot, shutting down ...
59
2024-04-20 13:43:49,281 - INFO - shutdown miner ...

Trotz verschiedener Abstands-Plätchen, um den Kontakt zum ASIC und KK zu verbessern, komme ich selbst mit nur 275MHz Takt an die 70°C, bei denen die FW/SW QAXE abschaltet.

Eventuell habe ich noch zu hohe Spannungen an den ASICs?

Markus

#7649314
Lesenswert?

Ei-ei,

und ich such mir den Wolf bei den ASICs.

Werde gleich einen KK draufkleben.

Gut auch der Hinweis mit dem -l Parameter fürs Logging, da brauche ich mich nicht mit tee und Co (2>&1) abkämpfen.

Danke für die sachdienlichen Hinweise ;-)

Langsam nimmt es Gestalt an und man lernt einiges dazu.

LG Markus

Ich lenke den Hauptlüfter-Luftstrom mittels einer 45° Klappe auf den Versorgungsteil der PCB. jetzt ist die Temp im grünen Bereich - Danke!

#7649391
Lesenswert?

Na endlich, nun hat das QAXE-Mining angefangen.

@Mampf Danke für Deine Hilfe und Geduld.

Stromaufnahme wie bei Dir 4A bei 12V.

Jetzt mache ich das 12V NT und den SBC (Radxa X2L) für's Mining fertig.

Die o.g. Versuche waren jetzt am NB und via 12V Akku um potentialfrei zu sein.

Ich dachte schon ich müsste HW Fehler suchen und den Logikanalyzer zur Hilfe nehmen. Bileb mit aber erspart ;-)

Markus

Angehängte Dateien:
OP Persönliche Seite #7649683
Lesenswert?

Markus W. schrieb:

hast Du eine Ahnung, wo ich im Code vom Miner oder der FW drehen müsste um den solo.ckpool.org zum Laufen zu bringen? Bei meinen beiden Bitaxe läuft die Kommunikation mit diesem Pool immer zuverlässig.

Ja das kuriose ist, dass einige Leute ckpool benutzen und eigentlich sollte es gehen (wenn man suggest_difficulty deaktiviert).

Ist das erste mal, dass es mit ckpool nicht gehen soll 🤔

Markus W. schrieb:

Wie sind die 8TH/s beim QAXE zu erklären? Public-Pool Dashboard Problem?

Jo, es kann natürlich zufällig passieren, dass man viele Hashes in sehr kurzer Zeit findet, aber ich würde eher davon ausgehen, dass Public-Pool einen Schluckauf hatte.

Beitrag #7649686 wurde von einem Moderator gelöscht.
#7649756
Lesenswert?

So mein Radxa X2L hat jetzt auch den python miner drauf und läuft mit dem qaxe soweit stabil. Als NT habe ich ein Meanwell 12V/12.5A (LRS-150) von Pollin, mit dem ich zwei qaxe betreiben werde also mit 8A Last.

Im web.public-pool.io werden z.Z. acht QAXE angezeigt mit einer gemeinsamen HR von knapp 13TH gelistet. Demnächst sollten noch mindestens drei dazu kommen.

@Mampf Danke nochmals für die Hilfe und das Projekt. Werde die Entwicklung vom 0xaxe im Forum verfolgen.

LG Markus

Angehängte Dateien:
OP Persönliche Seite #7649793
Lesenswert?

Markus W. schrieb:

Piaxe, Qaxe und jetzt 0xaxe. Und Deine programmierbare Load hier im Forum auch nicht ohne.

Nach jedem Projekt denke ich mir, das war jetzt das letzte ... aber glaub noch größer als den 0xAxe mach ich dann nicht mehr 😂

Hut ab vor Deinem Können.

Vielen Dank 🤗

Ich glaub das Hauptproblem ist, etwas fertig zu machen, was man angefangen hat, glaub daran scheitern viele 🙈

OP Persönliche Seite #7649796
Lesenswert?

Markus W. schrieb:

hast Du oder sonst jemand aus dem Forum eine Empfehlung, wo man sich in Bezug auf STM32 und Rust enlesen kann, um z.B. sowas 0xaxe/firmware/fw-L072KZ/src/bin/qaxe.rs zu prgrammieren?

Hmm ja, da gibt es eigentlich nur das github Repository von embassy-rs:

https://github.com/embassy-rs/embassy

Da gibts für verschiedene Microcontroller Familien auch Examples:

https://github.com/embassy-rs/embassy/tree/main/examples

Hab da selbst auch ein paar Examples beigesteuert, weil ich Support für den ADC der L0 Familie selbst hinzufügen musste. Und noch irgendwas mit dem L151, ich glaube da musste ich noch Code beitragen, damit der interne USB Pullup auch funktioniert.

#7649807
Lesenswert?

PS. ADC - Da ist mir aufgefallen, das die Spannungswerte 0V sind. Kann die Platine vom QAXE keine Spannungen messen, oder liegt es an dem Python Miner?

1
INFO - temperature and voltage: {'temp': [33.5625, 69.4375, 0, 0], 'voltage': [0, 0, 0, 0]}

Markus

Danke für die Links zu der MC Programmierung in Rust.

Der Link zur Embassy für MC's

https://embassy.dev/ und https://embassy.dev/book/dev/getting_started.html

OP Persönliche Seite #7649823
Lesenswert?

Markus W. schrieb:

PS. ADC - Da ist mir aufgefallen, das die Spannungswerte 0V sind. Kann die Platine vom QAXE keine Spannungen messen, oder liegt es an dem Python Miner?

Ja genau, der QAxe hat keine Spannungsmessung.

Das wurde erst mit den 4 Voltage-Domains auf dem 0xAxe interessant.

Hmm, vlt sollte ich das irgendwie anders machen, damit man durch die 0-Werte nicht verunsichert wird 🤔

#7649840
Lesenswert?

Verunsichert hat es mich nicht. Dachte schon sowas, da ja nur Temp.-Sensoren verbaut sind. War mir nicht klar, ob der MC eventuell via ADC was messen kann.

Da der Miner universell ist, kannst Du das aus meiner Sicht so lassen oder eventuell in der config.yml ein disable dafür vorsehen, wenn Dir der Aufwand nicht zu groß ist.

Markus

#7649912
Lesenswert?

Wie ist eigentlich so eine Meldung zu interpretieren. Spiele mich gerade mit unterschiedlichen Mining Pools. Muss man sich eventuell bei manche anmelden und die offentliche BTC Adr. registrieren, damit sie in der Miner API während des Verbindens erkannt und akzeptiert wird?

1
2024-04-21 12:27:30,268 - ERROR - Exception in RPC thread: script pubkey of our address not found
2
2024-04-21 12:27:30,268 - ERROR - error flag set ... ending handle_incoming_rpc thread
3
2024-04-21 12:27:30,268 - DEBUG - error received
4
2024-04-21 12:27:30,269 - DEBUG - joining rpc_thread
5
2024-04-21 12:27:30,269 - DEBUG - joining done

Markus

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren