Pages: 1 [2] 3
|
|
|
|
Author
|
Topic: Bootloader mcHF_boot_0.0.0.14 (Read 5079 times)
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #15 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
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #16 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 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
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen... qrz.com-Seite von DF8OE
----------------------------------------------------- >>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #17 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.
|
« Last Edit: 13. September 2015, 12:20:03 by hbtron » |
Logged
|
|
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #19 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.
|
« Last Edit: 13. September 2015, 12:35:01 by hbtron » |
Logged
|
|
|
|
|
hbtron
Neuling
Offline
Posts: 22
Ich liebe dieses Forum!
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #21 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
|
|
Logged
|
|
|
|
|
DC3AX
Interessent noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #23 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
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
DC3AX
Interessent noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #25 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
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DC3AX
Interessent noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #26 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
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
DC3AX
Interessent noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Bootloader mcHF_boot_0.0.0.14
« Reply #28 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
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
Pages: 1 [2] 3
|
|
|
|
|
|
|