Selbstbau CUN (MapleCUN)

[PeMue]

Hallo Ranseyer,

-ggf. funktioniert mySensors (Arduino-Pro mini oder Einzelteile)
  -NRF* Funkmodul

warum hast Du die LED an PD4 gehängt (siehe Schaltplan: https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=73243;image)?
Welches Signal willst Du anzeigen? Laut MySensors sollte Rx doch an Pin 6 = PD6 hängen?
Ich frage mich, was mit der LED angezeigt werden soll, wenn die doch im Gehäuse ist. Ggf. ist die nur für die Inbetriebnahme gut.

Danke + Gruß

PeMue

[juergs]

Hallo Zusammen,
dann fasse ich mal zusammen:

• Mit dem Demonstrator wird entweder der Bootloader oder MapleCULx4.bin geflasht.
• MapleCUNx4_W5500_BL.bin wird mit dem dfu-util geflasht.
• Die Einsprungadresse für den Bootloader ist 0x800200
• Für die Bootloader Variante ist es einfacher, Bootloader und dfu-util direkt über USB zu benutzen.(Wenn vorher ein passender DFU-Bootloader geflasht wurde)

dfu-util hab ich bei mir hier entdeckt:

Code Auswählen Erweitern

C:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\tools\win
Dort befinden sich auch die Tools für Linux etc.
Dort befindet sich die dfu-util.exe und auch Uploader über Serial und ST-Link.

Das Flashen mittels dfu-util kann auch wie unter Arduino erfolgen (Windows) :

Code Auswählen Erweitern

C:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM4 1 1EAF:0003 C:\Users\<user>\AppData\Local\Temp\arduino_build_660111/Blink.ino.bin

Code Auswählen Erweitern


REM
REM maple_upload.bat COM4 1 1EAF:0003 <pfad>/xxx.bin
REM
@echo off
rem: Note %~dp0 get path of this batch file
rem: Need to change drive if My Documents is on a drive other than C:
set driverLetter=%~dp0
set driverLetter=%driverLetter:~0,2%
%driverLetter%
cd %~dp0
java -jar maple_loader.jar %1 %2 %3 %4 %5 %6 %7 %8 %9

for /l %%x in (1, 1, 40) do (
  ping -w 50 -n 1 192.0.2.1 > nul
  mode %1 > nul
  if ERRORLEVEL 0 goto comPortFound
)

echo timeout waiting for %1 serial

:comPortFound


Die STMFlashLoader Demo.exe bietet die  0x800200 nicht als Adresslage an ...

@locutus:
hier eine Beispiel-USB-Switch-Schaltung: Beispiel-USB-Switch-Schaltung

[locutus]

Die USB DISC Schaltung ist mir bekannt. Auf meinem MapleCUL USB-Stick ist diese Schaltung nicht vorhanden.
Fakt ist, der generic_boot20_pb1.bin Bootloader erfüllt seinen Zweck. Ich sehe nach dem DFU Flashvorgang das typische Blinken der CUL-LED.
Mich interessiert der Trick, mit der Arduino IDE. Wie versetzt die Software PA12 von GPIO in den USB D+ Mode zurück?

[Ranseyer]

warum hast Du die LED an PD4 gehängt (siehe Schaltplan: https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=73243;image)?
Welches Signal willst Du anzeigen? Laut MySensors sollte Rx doch an Pin 6 = PD6 hängen?
Ich frage mich, was mit der LED angezeigt werden soll, wenn die doch im Gehäuse ist. Ggf. ist die nur für die Inbetriebnahme gut.

Die kann m.E. entfallen. Wie du schreibst sieht man die LED nur selten...

[juergs]

Roger Clark antwortet darauf mit "Magic Sequence":
http://www.stm32duino.com/viewtopic.php?f=27&t=1133&sid=fe1129a80b86d714f050752f620918b2&start=10#p14201

The bootloader and the sketches are standalone.
The bootloader is loaded into the base of the flash, (which is some strange location like 0x800000) (I think this is also mapped to 0x0000000 but most places refer to 0x800000 as the start of flash)
When the MCU starts it runs the bootloader.
The bootloader code implements the USB DFU device, so that when you plug the board in, it will initially appear as the DFU device under libusb as Maple DFU
The bootloader waits about 1 second as the DFU device, but if the IDE doesn't connect and start uploading in this time, the bootloader checks if there is a valid sketch at 0x8005000 and if there is, the bootloader just jumps to that address and the sketch starts to run.
The Sketch has the USB serial code in it. So what is supposed to happen is that the PC notices that there is a different USB device (Maple Serial) when the sketch runs.
But to tell the PC that something has changed on the USB bus, the Maple mini uses the 2 transistors under the board, (under the USB connector) to toggle the USB DM line - in accordance with the USB spec related to device connection
Normally the PC will notice that the usb device has changed, and you will see the Maple Serial device (which is allocated a COM port)
In the IDE, when you select that COM port. - When you press upload, the IDE compiles, and then calls the Maple_upload.jar file
The jar file sends a magic sequence of chars via the COM port to the board (and toggled DTR)
The sketch code constantly listens for the magic sequence, and when that sequence is received, the sketch forces a reboot of the MCU, so that it runs the bootloader again, which appears as the DFU device (after first resetting the USB bus), so that dfu_util (which is called my maple_upload.jar), can send the sketch to the board
But, precisely why this sequence is not happening for you, I really don't know
It is possible for the sketch to over write the bootloader, but not just running normal code, you'd need to use the EEPROM library to specifically erase the pages of flash for the bootloader
(Note the new bootloader is smaller than the original one that comes pre-flashed on the boards from China. So the start address of the sketch for the old bootloader is 0x8005000 where as if the new bootloader is installed, the sketch is flashed into 0x8002000)
However these addresses are hard coded into the bootloader, so I don't think its possible to overwrite the bootloader with sketch code

Bootloader Sketch:
http://stm32duino.com/viewtopic.php?f=21&t=257&p=3229&hilit=updater#p3241

http://www.davidpilling.net/wiki/index.php/STM32

[juergs]

DFU-Upload:
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/tools/linux/src/maple_loader/src/CliTemplate/DFUUploader.java

Code Auswählen Erweitern

/* we need to ensure both RTS and DTR are low to start,
     then pulse DTR on its own. This is the reset signal
     maple responds to
  */

Code Auswählen Erweitern

// try magic number
      serialPort.setRTS(true);
      serialPort.setDTR(true);
      try {
            Thread.sleep(50);
      } catch (InterruptedException e) {}
      serialPort.setDTR(false);
      try {
            Thread.sleep(50);
      } catch (InterruptedException e) {}
           serialPort.write("1EAF");
      try {
            Thread.sleep(50);
      } catch (InterruptedException e) {}
serialPort.dispose();

Magc Number:  serialPort.write("1EAF");

simple auto downloader

[PeMue]

Hallo Jürgen,

so ganz kann ich Dir nicht folgen, aber ich sage mal, was ich meine, verstanden zu haben:
- man kann die Firmware per serieller Schnittstelle flashen (so wie den Bootloader),
  das bedeutet aber, dass man das Gerät zum Flashen öffnen muss oder
- man kann über USB flashen, dann braucht man aber die USB disconnect Schaltung (diese Schaltung
  hat locutus' USB Stick nicht) oder die Schaltung mit dem DTR/RTS Pin aus dem letzten Link

Soweit korrekt?
Bezüglich der zu verwendenden Software muss ich mich noch einlesen, aber bei mir funktioniert dfu-utils unter Windows 7. Ich will das Ganze aber noch auf einem Raspberry Pi testen.

Danke + Gruß

Peter

[Ranseyer]

man kann die Firmware per serieller Schnittstelle flashen (so wie den Bootloader)

Genau. Aber die Firmware muss passend ((für mit/ohne/welcher Bootloader)) compiliert worden sein!

An einem Linux Gerät sieht man beim USB Bootloader folgenden Ablauf:
-Für kurze Zeit gibt das Leaf-Labs Device
-Dann startet die "Applikation" und es erfolgt der USB-Disconnect, ohne den Disconnect wäre keine Kommunikation mit der Applikation möglich...

Fazit: Man kann an der HW etwas sparen, kann dann aber nicht per USB flashen. Natürlich könnte man die drei-4 Pins +einen Button zum Flashen nach außen legen, aber da würde ich lieber das USB Flashen ermöglichen... (Oder halt davon ausgehen dass das Gerät selten aktualisiert wird) 

[juergs]

Hallo Peter + Ranseyer,
ich glaube es gibt verschiedene Sichtweisen auf die Thematik,
je nach dem, von wo man kommt:

1. Man hat ein Maple-Clone vorliegen, dann ist es einfach, der Bootloader (z.B Maple) ist schon drauf -> DFU - USB Load  möglich.

2. Man baut ein Board selbst auf und benutzt einen fabrikfrischen Chip.
Hier fehlt ja der DFU-Bootloader noch. Der Chip besitzt, so wie ich es verstanden habe, nur einen eingebauten Bootloader der es nur über die Serielle-Verbindung ermöglicht,
die Vorraussetzungen zum weiteren USB-Flashen zu schaffen.

Ich versuche das heute Abend mal exakter aufzudröseln.
Trotzdem ist das Thema gerade als Neueinsteiger ziemlich verwirrend, insbesondere diese Mehrstufigkeit und der Variantereichtum der Infos, die im Internet herumgeisterten.

Was mich interessiert ist, wie man nach dem ersten Schritt nach dem seriellem Flashen des DFU-Bootloaders (MAPLE-DFU-Device)  und dem Flashen der Apllikation (Serielle Schnittstellen des Maples entstehen ... MAPLE-SERIAL-Device) 
programmatisch Zugriff auf das Device bekommt (libusb). (Also die Mischung zwischen dfu-util und MapleLoader/Demonstrator) ....

Grüße,
Jürgen

[Ranseyer]

Hallo Jürgen,

ich bin mir nicht sicher ob du dir selbst das Leben schwer machst...

Zwei Varianten gibt es laut dir+mir:
-MAPLE: Genau an die Beschreibung von Telekatz halten ((kann man evt noch leicht verbessern)). Wer es anders machen will muss sich wohl selbst helfen
-Nackter Chip:
   -Wer das machen will muss sich einlesen und erst mal den USBBootloader draufbringen. Hat aber mit diesem Thread relativ wenig zu tun.
   -oder selbst kompilieren "ohne Bootloader"

Was ich damit sagen will: Denke es wäre besser einen neuen Thread aufzumachen um "andere STM32 Themen abseits des Maple zu diskutieren"

Was auch gut wäre wenn sich im Wiki noch mehr Leute einbringen würden. Ich habe z.B. den Input von Arnd noch nicht verarbeitet...

[juergs]

Hallo Ranseyer,

ich bin mir nicht sicher ob du dir selbst das Leben schwer machst...

Nein ganz sicher nicht, habe es ja "intuitiv" zu Laufen gebracht. Was mich stutzig macht ist, dass es z.B. bei Locutus in der gleichen Konstellation nicht
so läuft wie bei mir.

Zum Thread selbst:

Selbstbau CUN (MapleCUN)

Also alles was mit Selbstbau + Maple zu tun hat... oder liege ich mit meinem  Thema hier so daneben?
Es gibt ja wahrscheinlich mehr Leute, die auch mal mit dem Thema bei "0" , also auch mit den gleichen Hürden, anfangen werden ....

-MAPLE: Genau an die Beschreibung von Telekatz (und an Deine ge-) halten

Es hat bei mir nicht funktioniert, siehe auch umgekehrt Locutus und Peter.
Ich habe bis jetzt noch keine "_BL.bin" zum Laufen bringen können ....
Also gibt es schon Klärungsbedarf oder sagen wir mal Präzisierungsbedarf. 

Grüße,
Jürgen

[PeMue]

Hallo zusammen,

hat schon jemand mal die Stromaufnahme eines 4-fach mapleCUNs gemessen?
Hintergrund: Ich überlege mir, ob ich bei meiner Platine einen Schaltregler draufmachen soll, dazu bräuchte ich aber eine einigermaßen verlässliche Angabe.
lofutus' 1-fach mapleCUN (mit Netzwerk) braucht zwischen 170 ... 180 mA.

Danke + Gruß

Peter

[RaspiLED]

Ja Martin, steht doch auch im Wiki.
Gruß Arnd


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

[PeMue]

Ja Martin, steht doch auch im Wiki.

Danke, habe das leider nicht gesehen.

Gruß PeMue

[RaspiLED]

Hi,
kein Problem PeMue. Bin unterwegs gewesen, sonst hättest Du auch einen Link bekommen
Gruß Arnd


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