Hauptmenü

culfw@ARM

Begonnen von Telekatz, 22 Juni 2015, 22:42:29

Vorheriges Thema - Nächstes Thema

Telekatz

Die Datei ist zwar etwas größer als bei mir aber immernoch klein genug.
Ich denke, es könnte daran liegen, dass du eine andere GCC Version benutzt. Für die ARM Versionen sollte die GCC Version 5.4.1 verwendet werden.

mahowi

Ich habe einfach das entsprechende Paket installiert. Die GCC Version ist 7.3.1:
dietpi@fhem:~$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]


Woran könnte es denn liegen, daß die bootloader_CUBE.bin zwar erstellt wird, es beim make direkt im CUBe-Verzeichnis beim Linken von CUBE_BL.bin zum Fehler kommt?
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Telekatz

Es liegt an der GCC Version, ich habe es ausprobiert. Mit Version 6.2.1 läuft es durch und mit Version 7.3.1 habe ich auch einen Fehler.
Die bootloader_CUBE.bin wird deshalb ohne Fehler erstellt, weil dort der Teil des Codes, der den Fehler verursacht, nicht enthalten ist.

Du kannst entweder eine ältere GCC Version verwenden oder folgende Änderung im Linkerscript versuchen:

SECTIONS

    .ARM.exidx : {
      . = ALIGN(4);
        __exidx_start = .;
        *(.ARM.exidx*)
        __exidx_end = .;
    } > flash
   
    .fixed :
    {
        . = ALIGN(4);
        _sfixed = .;
        *(.text*)
        *(.rodata*)
        *(.data.__malloc_av_)
        *(.data.__malloc_trim_threshold)
        *(.data.__malloc_sbrk_base)
        *(.data.__ctype_ptr__)
        *(.data.__global_locale)
        . = ALIGN(4);
        _efixed = .;
    } >flash
der Linker läuft damit durch. Ich habe aber nicht ausprobiert, ob der Code damit auch lauffähig ist.

mahowi

Danke! Jetzt lässt sich die Firmware kompilieren. Das Aufspielen des neuen Bootloader mit bossa hat auch geklappt.

Wenn ich das richtig verstehe, wird die neue Firmware nicht mehr mit einem Terminal Emulator wie minicom übertragen, sondern soll auf das neu angelegte Laufwerk kopiert werden.

Bei aktiviertem Bootloader wird jetzt ein Laufwerk erkannt:
[Di Jul  9 21:45:07 2019] usb 1-1.5: new full-speed USB device number 60 using dwc_otg
[Di Jul  9 21:45:07 2019] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=6129, bcdDevice= 1.00
[Di Jul  9 21:45:07 2019] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Di Jul  9 21:45:07 2019] usb 1-1.5: Product: ATMEL AT91 MSD
[Di Jul  9 21:45:07 2019] usb 1-1.5: Manufacturer: ATMEL
[Di Jul  9 21:45:07 2019] usb 1-1.5: SerialNumber: 0123456789AB
[Di Jul  9 21:45:07 2019] usb-storage 1-1.5:1.0: USB Mass Storage device detected
[Di Jul  9 21:45:07 2019] scsi host0: usb-storage 1-1.5:1.0
[Di Jul  9 21:45:08 2019] scsi 0:0:0:0: Direct-Access     ATMEL    Mass Storage MSD 0.01 PQ: 0 ANSI: 6
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: Attached scsi generic sg0 type 0
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] 8000 512-byte logical blocks: (4.10 MB/3.91 MiB)
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] Write Protect is off
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] No Caching mode page found
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] Assuming drive cache: write through
[Di Jul  9 21:45:08 2019]  sda:
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] Attached SCSI removable disk


Jetzt habe ich /dev/sda gemountet und CUBE_BL.bin darauf kopiert. Nach einem umount bekomme ich mit dmesg einen Fehler angezeigt:
[Di Jul  9 21:57:42 2019] FAT-fs (sda): FAT read failed (blocknr 1)
[Di Jul  9 21:57:42 2019] FAT-fs (sda): unable to read boot sector to mark fs as dirty


Nach erneutem Anschliessen wird der CUBe nicht mehr erkannt:
[Di Jul  9 22:03:19 2019] usb 1-1.5: new full-speed USB device number 87 using dwc_otg
[Di Jul  9 22:03:19 2019] usb 1-1.5: device descriptor read/64, error -32
[Di Jul  9 22:03:19 2019] usb 1-1.5: device descriptor read/64, error -32
[Di Jul  9 22:03:19 2019] usb 1-1-port5: attempt power cycle
[Di Jul  9 22:03:20 2019] usb 1-1.5: new full-speed USB device number 88 using dwc_otg
[Di Jul  9 22:03:21 2019] usb 1-1.5: device not accepting address 88, error -32
[Di Jul  9 22:03:21 2019] usb 1-1.5: new full-speed USB device number 89 using dwc_otg
[Di Jul  9 22:03:21 2019] usb 1-1.5: device not accepting address 89, error -32
[Di Jul  9 22:03:21 2019] usb 1-1-port5: unable to enumerate USB device


Ist meine Vorgehensweise beim Installieren der Firmware falsch oder doch die kompilierte Firmware defekt?
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Telekatz

Teste es einfach mit der fertig compilierten Firmwaredatei aus dem a-culfw Archiv.

mahowi

Ok, so wie es aussieht muß ich wohl erst eine ältere Version der Toolchain installieren. Mal sehen, wo ich was für den Pi finde.

Die von Dir kompilierte Version lässt sich installieren. Da ich aber 2 Cubes angeschlossen habe, muß ich die Firmware selbst kompilieren mit unterschiedlichen IDs. Der selbst kompilierte Bootloader funktioniert auf jeden Fall auch mit neuerer GCC Version.

Vielen Dank für die Hilfe!
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

mahowi

Zur Info: Mit der Version 6.3.1 von arm-none-eabi-gcc kommt es auch zum Linker-Fehler:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: section .ARM.exidx LMA [0011cf54,0011cf5b] overlaps section .relocate LMA [0011cf54,0011d4c3]
collect2: error: ld returned 1 exit status


Leider finde ich keine Version 6.2.1 für den Pi. Für die 6.3.1 musste ich mir schon extra aus den Debian-Sourcen ein Paket bauen. Für Buster gibt es nur die 7.3.1.

Wäre es vielleicht möglich,  mir die Firmware einmal mit USB_DESCRIPTOR_SN "0" zu kompilieren, damit ich beide Cubes betreiben kann?
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

mahowi

Ich weiß zwar immer noch nicht, warum das Kompilieren auf dem Pi nicht mehr funktioniert,  aber auf meinem Laptop unter Ubuntu Bionic lässt sich eine  funktionierende Firmware auch mit v6.3.1 erstellen.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

petjek

Hi,

ich wollte gerade meinem bereits geflashten Max!Cube eine aktuelle Firmware verpassen. Ich hatte den Cube vor ein paar Tagen bereits nach dieser Anleitung erfolgreich geflasht, dann aber festgestellt, dass ich eine uralte Version runtergeladen hatte. Also bin ich mit dem Cube wieder an den Rechner, habe bei gedrückter Resettaste die Verbindung hergestellt und dachte nun geht das ganz simpel weiter. Tut's aber nicht.
Im Gerätemanager erscheint ein neues Gerät wie erwartet. Nennt sich Bossa Program Port (COM8). Scheint mir ein Treiber zu sein, den SAM-BA (v2.18) gleich mit installiert. Damit hat es beim ersten mal aber auch geklappt, den Bootloader zu installieren.
Ich bin davon ausgegangen, dass ich den Cube nicht wieder löschen muss, also habe ich Tera Term gestartet. Dort wird mir der Port auch angeboten, ich kann mich aber nicht dahin verbinden weil Tera Term "Cannot open COM8. Access denied." ausgibt. Auch wenn ich Tera Term als Administrator starte.
Ich hab dann über J1 die Firmware wieder gelöscht, um von Vorne zu beginnen. Wenn ich nun SAM-BA starte kann ich zwar einen Port auswählen (seltsamerweise werden mit dort sowohl \USBserial\COM8 als auch COM8 angeboten. Bei ersterem kommt eine Verbindung zustande, SAM-BA startet danach aber nicht. Im Taskmanager sehe ich einen Prozess laufen.
Gibt es noch andere Möglichkeiten, den Bootloader zu installieren? Irgendwie muss das Teil doch wieder zum fliegen kommen.

LG petjek
Die Möglichkeiten der deutschen Grammatik können einen, wenn man sich darauf, was man ruhig, wenn man möchte, sollte, einlässt, überraschen.

Telekatz

Man kann den Bootloader entweder mit SAM-BA oder mit einem JTAG Interface flashen.
Und wenn du den Bootloader neu flashst würde ich empfehlen, den neuen MSC Bootloader aus dem letzten Release 1.26.07 zu verwenden.

petjek

Ein JTAG Interface habe ich nicht. Und SAM-BA macht eben nicht das was es soll. Um genau zu sein macht SAM-BA eben nichts mehr nach der Auswahl des COM-Ports.


Gesendet von iPhone mit Tapatalk
Die Möglichkeiten der deutschen Grammatik können einen, wenn man sich darauf, was man ruhig, wenn man möchte, sollte, einlässt, überraschen.

mahowi

Wenn Du die Möglichkeit hast, einen Linux Rechner zu nutzen, geht es mit bossa. Mit Sam-ba unter Windows hatte ich auch dasselbe Problem wie Du.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Mihca

BOSSA unter Windows 10 64 funktioniert bei mir prima. SAM-BA funktioniert bei mir ebenfalls nicht.

http://www.shumatech.com/web/products/bossa
Viele Grüße
Achim
__________
Kein Fehler ist so dumm, dass man ihn nicht machen könnte.
Raspi Ubuntu 22.04 Perl 5.34, Rollo-, Sonnen-, Licht-, Heizungs-, Poolsteuerung, Energiebilanzen -- HomeMatic, FS20, ESP/Tasmota/ESPEasy, CUL868v3 USB, MAX! Cube LAN mit CUL-Firmware HomeMatic

petjek

Hab's nach einenm Neustart des Rechners hin bekommen. Danke.
Die Möglichkeiten der deutschen Grammatik können einen, wenn man sich darauf, was man ruhig, wenn man möchte, sollte, einlässt, überraschen.

Wzut

Wie  werden mit der aktuellen FW eigentlich inzwischen die beiden Schnittstellen ST1 & ST2 genutzt ?
Ich habe hier Antworten von 2015 gefunden das dort Debug Meldungen ausgegeben werden, trifft das noch so zu  ?
Bzw. gäbe es vllt auch beim Cube eine Möglichkeit wie beim Maple eine der beiden Schnittstellen transparent auf einem TCP Port durchzureichen ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher