Title: Bootloader mcHF_boot_0.0.0.14
Post by: DO5SMC on 05. September 2015, 04:28:12
Hallo mcHF Interessierte,
Ich habe folgendes Phänomen wenn Ich den neuen Bootloader mcHF_boot_0.0.0.14 Installiere
dann kann Ich das Gerät nicht mehr einschalten LCD Hintergrung leuchtet aber mehr passiert nicht
nach einigen mal schalten 10-30 mal startet er dann danach geht er immer wieder an nach einer Ausschaltzeit von ~30min geht das selbe wieder los. ???
Nun habe Ich bei dem Fehler den alten Bootloader mcHF_boot_0.0.0.9 Installiert Und er startet auf
Anhieb. :)
Es deutet auf jedenfall hin das meine CPU laüft und nichts fehlt sonst wäre ja ein Update nicht möglich.
Wäre toll wenn da jemand eine Idee zu hatt......
73
Stefan |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 05. September 2015, 06:21:57
Ich würde aus dem Bauch raus sagen:
"Das kann nicht sein" - wenn die Schaltung so aufgebaut ist wie vom Schaltplan vorgegeben.
Das einzige, was im Einschaltvorgang geändert wurde, ist die Tatsache, dass der Power-On-Knopf nun länger gedrückt werden muß, bis die CPU die Routine zum runterziehen von (15) vom Header erreicht. Dadurch kann der von Dir beschriebene Effekt aber nicht auftreten!
Entweder ein Aufbaufehler (irgenein Schluss oder eine Unterbrechung im Power-On Zweig oder die 3.3V für den Prozessor sind instabil oder zu niedrig.
Selbst das Flashen des neuen Bootloaders ohne Neuflashen der eigentlichen Firmware hat bei mir einwandfrei geklappt, und mit dem neuen Bootloader sind die sporadischen Neustarts komplett verschwunden...
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DO5SMC on 05. September 2015, 14:40:32
Hallo Andreas ,
Hatest Recht irgendwie waren nur 1,9Volt an der CPU konnte es so nicht finden
aber nachdem Ich nochmal mit Flußmittel die CPU Nachgefönt hatte ging es
Ich hoffe das bleibt auch so. 8)
.... Nach 1h aus geht das Ko.... Tei, wieder nich Ich dreh ab :'(
73
Stefan |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DO5SMC on 06. September 2015, 03:50:43
Neues....
Also Irgendwo ist wo ne kalte Lötstelle oder sowas (warscheinlich schon immer da)
Dadurch das es bei im Haus kälter wird geht es nicht mehr. Lege Ich den mchf nu erst mal auf die Heizung geht er an. Also jetzt kältesray besorgen ud vesuchen den Fehler wieder anzuschalten. |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 06. September 2015, 08:00:21
Wenn die CPU im Fehlerfall nur 1.9V Ub bekommt, müsste sich das doch mit dem DVM einkreisen lassen...
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DO5SMC on 06. September 2015, 08:43:16
Ja genau Kann es so provozieren. U6 Kalt geht nicht warm geht er an... (Habe mal komplett neu eingelötet)
ABER die Spannung ist dann trozdem zu gering Ich werde mal einen neuen Regler testen.
Mal ne andere Frage wozu sind eigendlich die Widerstände R45 und R46 vor dem Eingang des U6 dadurch
sind die 5V dann ja schon auf 3,9Volt gesunken. |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 06. September 2015, 09:37:44
Du hast eine wichtige Mod nicht gemacht!
Die beiden Rs dienen zur zusätzlichen Siebung. Und damit der Spannungsabfall dann nicht zu groß wird (wie bei Dir), schiebst Du in den ersten Widerstand nicht 5V, sondern 8V. Liegen auch auf der ui-Platine.
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DO5SMC on 07. September 2015, 13:45:42
Oh wo war der mod den Dukumentiert hatte das nach deinem Eintrag nochmal nachgesehen um ihn zu finden. Habe nun den R45 Hochkant und dort dann die 8V aus der Steckleiste angelötet.
Und nu will er auch immer an :D .
Also nochmal Danke für deine Geduld und Info´s
73
Stefan |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 07. September 2015, 14:52:13
In diesem Thread (http://www.amateurfunk-sulingen.de/forum/index.php?board=15;action=display;threadid=178) Schritt 5...
Aber ich gebe zu:
Das Ganze schreit nach einer Neuordnung. Werde ich vor dem Start der 2. Projektgruppe auch machen. Wir waren damals sozusagen die "Betatester" und vieles kam erst während des Aufbaus zu Tage :-\
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DO5SMC on 07. September 2015, 15:38:26
Zu deiner Entlastung Ich habe nur Hier nachgesehen:
http://www.amateurfunk-sulingen.de/mchf-projekt/modifikationen#start |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 07. September 2015, 16:00:18
Nix "Entlastung":
da hätte das auch reingehört :/
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: hbtron on 12. September 2015, 18:26:33
Hallo Andreas,
der Bootloader ist mir ein Rätsel. Für was ist der wirklich gut ?
Auch wenn er gebraucht werden sollte, es geht auch ohne Windoof und sogar auf dem MAC !
Zur Info:
Ich habe dfu-utils von http://dfu-util.sourceforge.net geholt und mein Discovery-Board damit 'geflasht'.
Dfu-utils gibt es für Win/Lin/Osx (Im Quelltext).
Dann muss man nur den Jumper (bzw. Vpp ) an VDD legen und PB2 (Band+) auf GND und Reset auslösen. Danach meldet sich USB-OTG immer mit 0x0483:DF11, das ist der DFU-Mode.
Mit 'sudo dfu-util -a 0 -s 0x08000000:leave -D binfile.bin' kann man alles flashen, auch Mist. Ich habe es mal mit 8000 Nullen versucht. Hinterher geht es trotzdem weiter.
Wer unbedingt den Bootloader damit flashen will, lässt die Option -s mit Startadresse weg (:leave ist zum direkten Starten der Applikation) und gibt das .dfu-File an. dfu-utils fischt sich dann das Binary samt Startadresse heraus.
Auch eine falsche Startadresse kann bei einem STM32F4 keinen Schaden anrichten.
(sudo sollte nach Eintrag einer udev-Regel überflüssig sein, ich müsste aber dafür meinen PC neu booten :-\)
Wer bei -a 1 angibt (das ist der Options-Block) ist selber schuld, allerdings hat derjenige trotzdem sehr gute Karten, dass nichts passiert. Für den Schreib/Lese-Schutz muss man exakt das "Richtige" hintereinander schreiben, damit es wirkt.
Wenn man mcHF direkt booten will, muss man natürlich in arm-gcc-link.ld die Flash-Adresse anstelle 0x08010000 auf 0x08000000 setzen (die Größe kann man dann um 0x10000 höher setzen) und neu linken. Das habe ich -mangels mcHF - noch nicht ausprobiert.
Der Stackbereich vom Bootloader (am RAM-Beginn) wird hinterher sowieso übergebügelt (siehe .map).
Zur Sicherheit habe ich bei Chris per mail mal nachgefragt. Wenn eine Antwort kommt, lasse ich es dich wissen.
vy 73,
Harald DL4SAI
|
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DL2JWL on 12. September 2015, 20:41:02
Hallo Harald,
nur wer nicht mit mit den Kenntnissen wie du ausgerüstet ist , der braucht Windows, wie ich.
Ich habe mich ca. 2 Stunden damit beschäftigt , um den Bootloader zu installieren.
Aber ich muss hier gleich dazu schreiben, mein USB-Kabel hatte ich an eine USB-Hub
angesteckt. Da wurde zwar der USB erkannt ,leider konnte nicht darauf zugegiffen werden.
Danach habe ich das USB-Kabel direkt auf den USB-Board gesteckt und siehe da, dann ging es reibungslos.
Danach die Firmware installiert und schon lief das UI-Board.
72 Wolfgang DL2JWL |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 13. September 2015, 06:44:30
Im Bootloader steckt zum Beispiel die Routine, die das Drücken des Power-Buttons bemerkt und danach über einen GPIO den Spannungsregler "dauerhaft" einschaltet. Kein Bootloader == kein Einschalten.
Sicher könnte man das auch in die Firmware einbauen - aber da ist es nun mal nicht drin.
vy 73
Andreas
PS:
Chris hat keine Ahnung von Linux und wird nicht so richtig nachvollziehen können, was Du mit der Kommandozeile gemacht hast.
Aber ich finde deine Idee sehr gut und würde sagen, wir programmieren mal eine kleine Schleife, mit der das Gerät eingeschaltet wird...
Meine Vorstellung:
Wenn der Resetvektor angesprungen wurde, folgt eine Zeitschleife von 500ms (um Glitches beim ausschalten abzufangen. Geschichte mit Bart - glaub mir, die muss da rein). Nach diesen 500mx wird gepfüt, ob der Netztaster gedrückt ist. Wenn ja, wird der betreffende GPIO auf L gezogen und die Starteinsprungstelle der Firmware wird angesprungen. dürften weniger als 10 Zeilen C sein...
EDIT - NEUE IDEE:
Ich kenne mich mi dem STM noch zu wenig aus um sagen zu können, ob das was ich jetzt gleich schreibe Dümmpfiff ist...
Kann man den DFU-Mode auch aus der Firmware heraus "aufrufen"? |
Title: Die besten Fragen sind die, die man sich selbst beantwortet...
Post by: DF8OE on 13. September 2015, 07:37:57
so geht es (http://stackoverflow.com/questions/26891432/jump-to-bootloader-in-stm32-through-appliction-i-e-using-boot-0-and-boot-1-pins).
Per "Affengriff" kann man so im User-mode in den System-mode mit Softreset wechseln....
Geeeeiiil..... 8) Firmwareupgrade ohne Windows-Kiste - das war es noch, was mir gefehlt hat!
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: hbtron on 13. September 2015, 08:05:06
Hallo Andreas,
das mit den 500 mSek. glaube ich dir - das baue ich schon deshalb auch in meinen Projekten ein, weil oft der JTAG durch den CPU-Reset zurückgesetzt wird. Da können dann auch die besten Tools über JTAG/SWDBG während Reset keinen Breakpoint setzen und die CPU läuft ungehemmt los.
Ob das beim STM32F4 auch der Fall ist, weiß ich nicht. Bei anderen ARM's ist das teilweise so - was war doch mein 68000 schön ;)
Das mit dem Schalter verstehe ich nicht ganz, es sei denn, in der mcHF-Firmware wird der Ausgangs-Port zum 'Überbrücken' nicht initilisiert und nur zum Abschalten wieder auf 1 gesetzt.
Man spart sich mit dem Bootloader also nur das Überbrücken des Power-Buttons beim FW-Update.
Dafür sind 64 kByte verschenktes Flash eindeutig zuviel. Die Möglichkeit des originalen Bootloaders von ST, einen USB-Stick mit 'image.bin' zu erkennen und zu flashen, wäre natürlich Luxus hoch drei.
Auch ohne dieses Feature ist es mit 10 Zeilen nicht getan, da die Vektortabelle vollständig enthalten sein sollte und die Firmware mit Setzen von Stackpointer und PC ja gestartet werden muss. Aber, wie auch ich meine, ist das überflüssig, es gehört alles in die Firmware.
Dass man zum Flashen den Power-Button überbrücken muss, ist zwar unschön, aber mit etwas Nachdenken gibt es dafür sicher eine andere Lösung. Das Problem entsteht beim Herunterfahren und Abspeichern der letzten Einstellungen. Man kann nicht einfach ausschalten.
Z.B. könnte man (ins Unreine gesprochen) die Spannung am USB zusätzlich dazu nutzen, Power aufrecht zu erhalten. Dieser Mechanismus müsste in der Firmware beim Abschalten ausser Kraft gesetzt werden und nur durch den Taster wieder aktiviert werden. Das benötigt natürlich etwas Hardware, die sich auch
'etwas merken' muss.
Ich habe sowieso vor, mir die Firmware mal genauer anzuschauen, schon als Lehrstück zur DSP-Programmierung.
Zu deiner Frage nach der Performance (aus deiner mail): Da die DSP-Funktionen ja in einem strengen Takt durchgeführt werden, müsste man bei Eintritt in die Rechenfunktionen einen Testport setzen und beim Austritt zurück setzen. Dann kann man mit dem Oszilloskop beurteilen, inwieweit die restlichen Funktionen Zeit haben.
Wenn die Pulsbreite dabei von 90% auf 80% zurückgehen würde, würde der Rest dann doppelt so schnell laufen.
vy 73,
Harald
|
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 13. September 2015, 11:42:58
Hört sich alles sehr gut an - ich bin hellauf begeistert.
Also kurze Erläuterung, was der Bootloader "bbeim normalen Betrieb" macht:
Nach Drücken des On-Tasters legt dieser hardwarebegründet Betriebsspannung an den STM. Dieser läuft los - in den Bootloader von Chris. Dort wird nach 500ms getestet, ob der On_taster noch gedrückt ist. Wenn ja ==> wird über PC8 die Betriebsspannung nun dauerhafr aktiviert (== man kann den On-Taster nun loslassen. Jetzt springt der Bootloader an den Starteinsprungpunkt der eigentlichen Firmware. Damit ist der Bootloader für die weitere Funktion abgeschaltet.
Wenn man den Bootloader weglassen will, dann muß man einige GPIOs initialisieren (ich müsste in der FW nachsehen, ob das vielleicht. nicht nur PC ist), bestimmt sind da noch andere Initialisierungen. Bekommt man alles raus, da man das, was die FW ja macht, sehen kann. Dann müsste man auf den Resetvektor folgend die Auswertung des On-Tasters mit Zeitschleife etc. wie oben beschrieben. Damit würde das Gerät dann auf jeden Fall schon mal laufen. Aber man könnte keine neue FW einspielen...
Jetzt kommt mein Link aus dem letzten Beitrag zum Tragen 8)
Neuer Menüpunkt "Firmware-Update". Ist dieser angewählt und man drückt z.B. die "Band-Taste", dann wird der STM in den System-Bootloader-Modus "soft-resettet". Das heisst, dass der STM neu startet und ohne gesetzte Brücke (!!) und ohne gedrückte Band- Taste (!!) im DFuSe-Mode ist (siehe Link letzter Beitrag von mir). Man muss nur den Power-Button die ganze Zeit drücken - das kann man aber durch einen einzigen "neuen Transistor" auch automatisieren. An dieser Stelle kann man dann mit dem DFuSe-Tool oder auf der Kommandozeile einfach die neue FW einspielen. Man müsste natürlich die "geänderte Version" von oben nehmen und im .ld die Startadresse verändern.
Ich hoffe, jetzt ist klar, an was ich denke...
Im Ergebnis eine leicht veränderte Vorgehensweise beim FW-Update, keine Veränderung in der "normalen Bedienung". Dafür keine Abhängigkeit von einem closed-Source-Bootloader und FW-Programmiertool mehr, jetzt ist alles Open-Source.
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: hbtron on 13. September 2015, 11:54:45
Hallo Andreas,
Die Idee ist genial ! Das heißt wohl für den mcHF: PB2 muss auf dauerhaft auf GND, Jumper P6 bekommt einen 100 nF und dieser wird mit einem parallel geschalteten MOSFET mit Gate am Taster Band+ beim Betätigen über den internen CPU-pullup geladen. R40 wird deutlich verkleinert, bleibt aber sicherheitshalber drin.
Fehlt nur noch eine Lösung für Power-On während System-Boot. Mir fällt da nur eine Thyristor-Ersatzschaltung am LP2914 am Pin 2 ein. Diese müsste man per Power-Taster zünden (und für den CPU-Sense schmackhaft machen).
Zum Ausschalten müsste in der Firmware ein positiver Impuls erzeugt werden, d.h. der Port müsste per externem pull-down inaktiv gesteuert werden. Dieser Impuls müsste den Thyristor über einen MOSFET kurz sperren.
Dann kann man in der Firmware entscheiden, ob mcHF ausgeschaltet oder - bei gleichzeitiger Betätigung von Band+ in den System-Bootloader springen soll.
Siehst du das auch so ?
vy 73,
Harald
EDIT: sorry, die mails haben sich überschnitten. Zur Erläuterung: ich suche eine Lösung ohne Bootloader, ohne Jumper und ohne dauerhaftes Betätigen von Power ON. So eine Lösung habe ich hier versucht, anzudeuten
EDIT2: Noch etwas: die Lösung sollte auch funktionieren, wenn man 500 kByte Mist geflasht hat und der Power-OFF nicht mehr funktionert.
Hierzu müsste bei erneuten Anstecken der 12 V mcHF sofort Power bekommen.
Wenn währenddessen Band+ gedrückt ist, ist der System-Loader wieder da.
Das macht jeder PDA uns jedes Handy so... Dann geht das auch bei einem leeren STM32.
|
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 13. September 2015, 12:19:25
Ja - so ähnlich sehe ich das auch.
Ich denke, man käme ohne Thyristor-Ersatzschaltung aus, weil man mit einem einfachen FET und ein paar Widerständen / einer Diode sowas auch "ranfrickeln" kann. Fliegender Aufbau kein Problem.
Wir müssen nur herausfinden:
- wieviel der Initialisierung der Ports etc. findet im Bootloader und nicht in der Firmware statt --> das entsprechend in die Firmware reinprogrammieren
- sich schlau experimentieren, wie man mit dem "Trick" aus dem Link in den System-Mode kommt und ob man nach Abschluss des Flashens vielleicht auch irgendwie wieder rauskommt ohne die Betriebsspannung stumpf abzunehmen.
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: hbtron on 13. September 2015, 12:29:17
Hallo Andreas,
ich denke, die einzige Möglichkeit, den Systemloader aus allen Situationen (falsche Firmware, keine
Firmware usw) zu verwenden, ist den Power ON/OFF-Speicher aus der CPU herauszuverlagern.
das gelingt nur mit selbsthaltenden Schaltungen. Und das lässt sich wegen des Umfangs wahrscheinlich
nicht 'hinein pfriemeln'. Auch muss eine Notlösung muss es geben, wenn der Power-OFF-Button nicht
mehr erkannt wird (z.B. 12V erneut einstecken). PC8 könnte man aber als pos. Power-Off umgestalten.
Mein Vorschlag ändert auch die Bedienung etwas: Band+ müsste über den Reset hinweg aktiv sein,
da dieser im Stystemloader abgefragt wird. In meinem Vorschlag liegt die Unterscheidung nur
am JP6: Kondensator entladen -> Firmware starten, Kondensator geladen -> System-Loader starten
Ich gehe, wenn ich etwas Zeit habe, auch mal durch die Firmware. Mit grep und find habe ich auf die
Schnelle noch nicht viel gefunden.
vy 73,
Harald
Nachtrag: Den Systemloader kann man mit dfu-utils direkt verlassen (:leave) und die Firmware starten, beim ST-Tool weiß ich das nicht. Das würde mit meiner Lösung (externer On/Off-Speicher) funktionieren. |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 13. September 2015, 12:42:15
Du kannst Dir die ganzen Sachen mit Kondensator, gedrücktem Band- Knopf etc schenken - es geht auch ohne...
[youtube cvKC-4tCRgw]
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: hbtron on 13. September 2015, 13:00:06
Hallo Andreas,
das ist alles richtig, wenn bereits eine 'vernünftige' Software läuft, aber nicht mehr, wenn ich 500 kByte
Nullen ge-'flashed' habe.
Klar, man könnte wieder einen eigenen Bootloader schreiben, der das ausnutzt. Der hätte als Vorteil nur die Anpassung an die jetzige Bedienung.
Der System-loader funktioniert aber immer, auch ab Reset. Ganz abgesehen davon finde ich die Verwendung
von USB Vendor/product 0x0483:0xDf11 in einem eigenen Bootloader problematisch.
Ich denke, die Idee mit dem Kondensator ist genial, und wenn Dir etwas Besseres als die Thyristor-Ersatzschaltung für Power ON/OFF einfällt, soll es mir recht sein. Letzteres geht m.E. nicht anders, da
das alleinige Herunterziehen von PC8 eben eine 'vernünftige' Software voraussetzt.
Ich werde in den nächsten Tagen das mal am Discovery-Board ausprobieren. Wenn es zuverlässig funktioniert, kann ich die Schaltung mal zur Diskussion stellen.
vy 73,
Harald
|
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 13. September 2015, 15:14:18
OK - lass uns das starten. Im Moment fällt mir dazu nichts vernünftigeres ein. Ich arbeite gerade daran, das HY28B im SPI-Mode zu betreiben, um feie GPIOs zu bekommen (funktioniert schon). Nun verdrahte ich gerade die SPI-Anschlüsse des Touchpads und "besorge" mir einen Interrupt auf einem der nun frei gewordenen GPIOs. Die erste Funktion, die ich der Tocuhfunktion geben will, ist ein "Umschalten Wasserfall / Scope mit Berührung des Bildschirms :)
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DC3AX on 16. September 2015, 13:28:24
Ähem... Reusper...
Also wenn man den Bootloader loswerden will, dann muss man doch nur die GPIO-Selbst-Haltefunktion in der main() des normalen Codes implementieren.
Das Ganze sehe ich vor allem dann als nützlich, wenn man viel Software testet und deswegen dauern flashen und neu starten muss.
Ständiges Programmieren, Flashen, Testen, Debuggen macht aber nur Sinn, wenn man sich für 39,- einen ST-Link kauft und diesen hinten auf dem UI-Board anklemmt. Und da der ST-Link hin und wieder über JTAG einen Reset auslöst, muss man den Power-Taster kurzschließen, egal was man sich sonst so alles vorstellt.
Daher ist es in meinen Augen sinnvoller:
1) Für unbedarfte User den USB-Download über gehaltene Tasten ermöglichen
2) Für Experten einen Jumper hinzuzufügen, der die Powertaste klemmt.
2a) Den ST-Link unter dem Display etwas anders belegen.
An Chris habe ich bereits gemailt, dass er die Jumperleiste für den ST-Link in einem Redesign etwas anders belegt und den C62 oder C64, der da im Weg ist, beideite schafft. Dann kann man eine mehrpolige 90° Pinleiste dort einlöten und den ST-Link von unten in das zusammen gebaute Gerät einstecken. Ich habe mir das mit etwas Fädeldraht inzwischen parat gemacht.
Auf dem ST-Link Stecker liegen TX vom UART, was nicht nötig ist, wenn man Semihosting verwendet für debug printf, dafür fehlen aber leider GND und Vcc, was der ST-Link Adapter benötigt...
73!
Ulrich |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 16. September 2015, 15:17:14
Soweit ich weiß, arbeitet Chris schon an einem "neuen mcHF" mit M7 Prozessor. Es ist fraglich, ob er noch ein Redesign machen wird. Aber vielleicht veröffentlicht er dann ja seine Gerber-Dateien...
Die Geschichte mit USB-Stick-Update finde ich immer noch genial, weil man die Routine zum Lesen (Schreiben) des Sticks auch anderweitig gut gebrauchen könnte...
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DC3AX on 16. September 2015, 15:45:01
Ob Chris nun mit M7 oder A17 weiter macht ist ja egal, meine recht lange eMail mit Verbesserungsvorschlägen lässt sich auch bei einem komplett neuen Design berücksichtigen.
Das USB-Stick Update ist Bestandteil des ROM-Loaders, den man zwar insgesammt aus dem eigenen Code heraus anspringen kann, ich bin mir aber nicht sicher, ob man dessen Routinen zweckentfremden kann... Aber USB Host mit Dateisystem gibt es eigentlich in den verschiedenen O/S-en, die im Netz existieren.
73!
Ulrich
|
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DC3AX on 18. September 2015, 14:10:43
Hi!
Ich bin noch Hardware am testen und benötige deshalb am einfachsten mal eine verifizierte funktionierende Software mit SI Autodetect. Ist das mchf-eclipse.bin auf github funktionsfähig und wohin muss es geladen werden? Bootloader oder direkt?
73! Astralix |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 18. September 2015, 14:16:15
Es ist funktionsfähig und muß auf dem einzigen Weg geladen werden, den es offiziell im Moment gibt: mit installiertem Bootloader von Chris und dem "Affengriff" BAND- und Power_On gleichzeitig und der Win-Software mchf-manager.
Alle anderen Wege im Moment ganz schnell raus aus allen Diskussionen, das verwirrt nur die, die sich mit dem Thema STM32F4 noch nie beschäftigt haben ;D - diese Wege existierne im Moment erst in unseren Köpfen...
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DC3AX on 18. September 2015, 15:17:46
Ok, dann also auf die harte Tour :)
Ich habe kein Windows und seid ich kernel 4.2-unstable nutze, geht auch die Windows VM nicht mehr. Wer braucht das schon...
Also habe ich den ST-Link an die entsprechende Schnittstelle verdrahtet und openocd zum Flashen genutzt:
Firmware für Bootloader kompiliert von github geladen und im projektordner abgelegt, dann 2 Konsolen öffnen...
~/Projects/mcHF$ openocd -f board/stm32f4discovery.cfg
~/Projects/mcHF$ telnet localhost 4444
Im Terminal:
> reset init
> flash write_image erase mchf-eclipse.bin 0x8010000 bin
Leider fliegt einem der mcHF gerne mal weg, weil die Selbsthaltung versagt, nach dem "reset init" aber ein "halt" funktioniert ebenfalls nicht zuverlässig. Das ist aber kein Problem, denn die telnet Console von openocd verfügt über einen Zeilen-Puffer.
Also Power Taste halten, 2x nach oben und "reset init" wiederholen, dann 2x nach oben und die "flash write_image..." Zeile wiederholen. Keine 10s später ist die Firmware da, wo sie hin gehört.
Und nun habe ich auch ein Signal auf dem Sprektrum-Analyzer und ich werde mich mal mit dem ausgeworfenen Dipol auf die Suche nach einer der Baken aus dem Bakenprojekt machen.
Andreas, wenn das hier klappt, mache ich mal ein paar Bilder zu der ST-Link Modifikation, die maile ich Dir zur freien Verfügung. Vieleicht kannst Du dich mal mit einem Schaltbild für die MOS FET Schaltung bzgl. Punkt 9 der Modifikationen an mir rächen?
73!
Ulrich
Astralix |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 18. September 2015, 15:27:15
Gerne!
Du hast bei mir mit dieser Beschreibung ein unhaltbares Tor geschossen 8) Und ich ddenke viele andere Linuxianer sehen das auch so.
Ich besitze auch nur noch ein einziges Laptop mit Win-XP. Und wenn das abgeschossen ist, dann war es das auch für mich endgültig mit Windows.
Ich finde es genial!
Eins kann ich schon mal sagen:
Für die Mod nach Punkt 9 musst Du das Display abziehen und eine Leiterbahn darunter auftrennen und ein SMD-Diödchen drauflöten...
vy 73
Andreas |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DC3AX on 18. September 2015, 15:35:44
Gern geschehen,
... Punkt 9 lass ich dann erst mal weg. Mein LCD ist fest drinne und ich möchte es nicht heiß auslöten, noch bevor ich wenigstens eine einzige Station gehört habe. Abgesehen davon würde ich wohl auch die Drehgeber und die Tasten tauschen wollen, wenn der mcHF gut läuft. Da ist es einfacher, den UI Bausatz noch einmal zu bestellen und dann mit alternativen Knöppen und den Modifikationen aufzuwerten.
73!
Ulrich |
Title: Re:Bootloader mcHF_boot_0.0.0.14
Post by: DF8OE on 18. September 2015, 15:45:54
Punkt 9 reduziert die Stromaufnahme im abgeschalteten Zustand von ca. 4mA auf unter 1uA. Das ist alles.
vy 73
Andreas |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|