Selbstbau CUN (MapleCUN)

[RaspiLED]

Ja läuft und der Vorteil sind andere CULs wie Zwave CUL Habe ich aber noch nicht.


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[A.Harrenberg]

Richtig,

Rudi hatte das ja extra "für mich" (wegen 4xfach Maple CUL mit ZWave) angepasst und daraus was generisches gemacht das mit eigentlich alles CUL varianten funktionieren sollte.
Ansonsten sollte es da ja keine weiteren Unterschiede geben bis auf die Tatsache das "Umsteiger" diese "Zwischendevice" weglassen...

Gruß,
Andreas.

[locutus]

Ich habe diesen Bootloader hier für Locutus-Board  verwendet:

https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin

Zusammen mit dieser Binary von hier:
https://forum.fhem.de/index.php/topic,60458.msg638507.html#msg638507

Boot1 muss mit GND verbunden sein, ist die Lötbrücke auf der Unterseite der Platine, neben TX1 und RX1.
Beides mit FTDI-USB-Seriell-Wandler geflasht.
Diese Versionen  haben eine Abhängigkeit mit der Zuordnung der User-LED zum verwendeten I/O-Pin. 

Hallo Jürgen,
ich habe Roger Clarks Bootloader für den MapleCUL USB-Stick modifiziert:

Code Auswählen Erweitern

#elif defined TARGET_GENERIC_F103_PC13

#define LED_BANK GPIOB
#define LED_PIN 1
#define LED_ON_STATE 0

// Button (if you have one)
#define BUTTON_BANK GPIOB
#define BUTTON_PIN 8
#define BUTTON_PRESSED_STATE 1

Entstanden ist die generic_boot20_pb1.bin Datei.
Um den Perpetual Bootloader Mode zu verwenden, muss man eine winzige Modifikation am MapleCUL durchführen, nähmlich die Ports PB8 und BOOT0 (Pin 44 und 45) mit Lötzinn verbinden.
Magst Du bitte testen und Feedback geben?
Ich stehe nach wie vor auf Kriegsfuß mit diesem Bootloader. Es spielt keine Rolle, ob ich eine _BL.bin oder .bin Datei flashe, das System enumeriert kein neues USB-Gerät.

[juergs]

Hallo locutus,

Magst Du bitte testen und Feedback geben?

Ja, gerne.

Ich stehe nach wie vor auf Kriegsfuß mit diesem Bootloader. Es spielt keine Rolle, ob ich eine _BL.bin oder .bin Datei flashe, das System enumeriert kein neues USB-Gerät.

Also bei mir gingen die "xxx_BL.bin" - Binaries gar nicht -> gleiches Symptom: keine Enumeration der USB-COM-Ports beim Einstecken.

Der Bootloader von Roger Clark ermöglicht ja ein Programmieren aus der Arduino IDE. Deshalb kommt sofort nach dem Flashen des BLs und einem Reset
die Enumeration der USBs.

Bei mir gab es auch einen anderen Grund, warum es nicht direkt ging: eine unbeabsichtigte Brücke bei den Ports.
Das kann man nur mit sehr guter Lupe oder Mikroskop entdecken. Brücke weggekratzt -> Enumeration geht.

Ok, das LQFP48-Gehäuse ist nichts für Lötanfänger, das anfängliche genaueste Ausrichten der 4 äußeren Pins  entscheidet über die Qualität der Lötung mit Heißluft
der restlichen Pins. Ich verzinne die Pins der Platine vorher mit Lötzinn und ziehe es mit guter Entlötlitze wieder ab. Dann die 4 äußersten Pins  exakt ausrichten, dann anlöten.
Danach mit viel Flußmittel-Paste und Reflow-Heißluft die Pins des Chip anziehen lassen. Das überflüssige Flussmittel kann man hinterher wieder leicht
mit Leiterplatten-Reiniger entfernen.

Aber, wem sag ich das 

Jürgen

[juergs]

Hallo Locutus,

habe bei meinem Board den Speicher vorsorglich gelöscht.
Vorher überzeugt, daß enumeriert wird ...
Dann Dein Bin-File geflasht: Ergebnis leider negativ. /edit: Das ist ok so, da ja der DFU-Boot-Modus aktiv ist!
Die Leuchtdiode blinkt im 0.5 s Takt. Beim Drücken des Reset-Buttons kurz etwas  schneller.
Sonst keine weitere Reaktion.

/edit: Das ist ok so, da ja der DFU-Boot-Modus aktiv ist! Der Bootloader generiert keine seriellen  COM-Ports.
Programmieren wäre nur mittels dfu-util-tool oder seriell über den Demonstrator möglich.

[juergs]

Hallo Locutus,

nach dem Flashen des Bootloaders "generic_boot20_pc13.bin" kommt entgegen meiner Annahme
keine Reaktion der Seriellen. Dann einfach die "MapleCULx4.bin" hinzugeflasht ... und geht.
Nach Reset blinkt die blaue LED im bekannten Sekunden-Takt .... und die Ports erscheinen ...

Was ich nachher noch prüfen kann, ob beide BLs "standalone" wenigstens mit dfu-util / Arduino-IDE ansprechbar sind.

Grüße,
Jürgen

[juergs]

1.) generic_boot20_pb1.bin

-> Blink geht über die IDE zu flashen, ohne ein Button drücken zu müssen!

COM-Ports kommen, diesmal anders enumeriert ..... COM12/13/14

Code Auswählen Erweitern

Archiving built core (caching) in: C:\Users\jschw\AppData\Local\Temp\arduino_cache_578362\core\core_Arduino_STM32_STM32F1_mapleMini_bootloader_version_original,cpu_speed_speed_72mhz_203eb828a61a67ce703c3870ede5d634.a
Sketch uses 12956 bytes (11%) of program storage space. Maximum is 110592 bytes.
Global variables use 2816 bytes of dynamic memory.
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...

Found it!

Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=259
Starting download: [##################################################] finished!
error resetting after download: usb_reset: could not reset device, win error: Das System kann die angegebene Datei nicht finden.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present

Done!

Resetting USB to switch back to runtime mode
timeout waiting for COM4 serial


Und die Led blinkt im Sketch vorgegebenen Takt...

"could not reset device" ist klar ... Die Schaltung dazu fehlt.
"COM4 serial" ist eine Dummy-Port-Angabe, die nicht existiert, aber zum Betrieb der IDE erforderlich zu sein scheint.Oder einfach die letzte Einstellung.

[juergs]

Hallo Locutus,

wegen aud Deinem Board nicht belegtem PC13 blinkt der Bootloader nicht beim "generic_boot20_pc13.bin".
Deshalb die Änderung für  "generic_boot20_pb1.bin".

Ist mir so nicht direkt aufgefallen, weil ja die aculfw korrekt blinkt und
ich zuerst den Bootloader und sofort danach die "MapleCULx4.bin" geflasht habe.

Die PB1_Version wird hier leider  nicht vorgefertigt mit angeboten:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/STM32F1/binaries

Allerdings funktioniert bei mir die Kombi: generic_boot20_pb1.bin + MapleCULx4.bin nicht.

Dann bleibt ja nur noch: "generic_boot20_pb1.bin" + "MapleCUNx4_W5500_BL.bin" ?

[juergs]

Code Auswählen Erweitern

Dann bleibt ja nur noch: "generic_boot20_pb1.bin" + "MapleCUNx4_W5500_BL.bin" ?

Nein, geht auch nicht...
Nach Aus -und wieder Einstecken ....

/Edit: Evtl. verstrubelt sich das USB-Subsystem auch,  hätte noch klären sollen, ob es nach einem Reboot des Rechners funktioniert...
/Edit2: Der Bootloader wäre in diese Variante auch nicht erfoderlich, da er in der Binary schon enthalten ist.
/Edit3: "MapleCUNx4_W5100_BL.bin" alleine => Usb-Gerät wurde nicht erkannt. Mehrfach probiert...

[juergs]

Deshalb bleibe ich bei meiner Kombi 
... und verzichte auf das Blinken des Bootloaders, PC13 ist eh nicht verdrahtet.

Grüße,
Jürgen

[locutus]

Danke! Deine Kombi funktioniert leider bei mir nicht.

Der Bootloader von Roger Clark ermöglicht ja ein Programmieren aus der Arduino IDE. Deshalb kommt sofort nach dem Flashen des BLs und einem Reset die Enumeration der USBs.

Damit wäre geklärt, warum die Enumeration nach dem flashen der a-culfw nicht klappt.

Die Funktionsweise ist in der README beschrieben ...

On "generic" boards, the USB reset (to force re-enumeration by the host), is triggered by reconfiguring USB line D+ (PA12) into GPIO mode, and driving PA12 low for a short period, before setting the pin back to its USB operational mode.

[juergs]

Der Bootloader von Roger Clark ermöglicht ja ein Programmieren aus der Arduino IDE. Deshalb kommt sofort nach dem Flashen des BLs und einem Reset die Enumeration der USBs.

Nachdem der  Blink-Sketch geflasht wurde! Das Flashen des Bootloaders alleine bewirkt keine Einrichtung der Seriellen.



Ich habe beide Binaries einfach nacheinander geflasht, einfach mit "Back" wieder zurück in den Auswahl-Dialog.
Ein Reset hat dann ebenfalls "USB-Gerät nicht erkannt" - Meldung geliefert.
Vom USB-Bus getrennt wieder verbunden, geht .... (Evtl. nach einem Reboot?)

Vielleicht Windows Zeit geben den Maple-Clone zu erkennen...?

Diesmal wieder das Phänomen:
Ports COM 6,7,8 werden erzeugt und "V" reagiert auf Port COM7:

V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_00 (F-Band: 868MHz)

Deine Kombi funktioniert leider bei mir nicht.

Ich habe jetzt 6..7 mal diese Versionen dieser Kombi geflasht, bei mir geht es!

Machen wir da doch noch etwas systematisch falsch?  Demonstrator?
Oder doch eher ein Hardware-Problem? USB-Kabel? Anderer Rechner?

Funktioniert BL + Arduino Blink-Sketch?

Grüße,
Jürgen

[Telekatz]

Ist mir so nicht direkt aufgefallen, weil ja die aculfw korrekt blinkt und
ich zuerst den Bootloader und sofort danach die "MapleCULx4.bin" geflasht habe.

Ich habe beide Binaries einfach nacheinander geflasht, einfach mit "Back" wieder zurück in den Auswahl-Dialog.

Wenn du das machst, kannst du dir das flashen vom Bootloader sparen, da du den mit MapleCULx4.bin sofort wieder überschreibst. Und wenn du so auch mit MapleCUNx4_W5500_BL.bin probiert hast, kann das nicht funktionieren, da die Firmware dann an die falsche Adresse im Flash geladen wird.

Mit dem Demonstrator wird entweder der Bootloader oder MapleCULx4.bin geflasht.

MapleCUNx4_W5500_BL.bin wird mit dem dfu-util geflasht.

[juergs]

MapleCUNx4_W5500_BL.bin wird mit dem dfu-util geflasht.

Hallo Telekatz,
jetzt kommen wir der Sache näher. Meine Befürchtung mit den falschen Einsprungadressen  über den Demostrator
ist also bestätigt. (War der Meinung, das managed die Binary etwa wie bei IntelHex) ...

Dann wäre eigentlich nur die richtige Start-/Einsprungadresse zu bestimmen um es auch mit dem Demonstrator zum Laufen zu bringen?

Jürgen

[Telekatz]

Dann wäre eigentlich nur die richtige Start-/Einsprungadresse zu bestimmen um es auch mit dem Demonstrator zum Laufen zu bringen?

Die Einsprungadresse für den Bootloader ist 0x8002000, aber wozu sollte das gut sein? Es ist nicht sinnvoll, die Bootloader Variante mit dem Demonstrator zu laden. Dafür nimmt man die Variante ohne "_BL".

Für die Bootloader Variante ist es einfacher, Bootloader und dfu-util direkt über USB zu benutzen.