HM-Sec-SCo - alternative Firmware mit AskSinPP

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

kafisc
Beiträge: 129
Registriert: 08.09.2015, 15:14
Hat sich bedankt: 18 Mal
Danksagung erhalten: 4 Mal

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von kafisc » 09.12.2022, 19:05

jp112sdl hat geschrieben:
08.12.2022, 20:33
kafisc hat geschrieben:
08.12.2022, 19:56
Es läuft die: "STLINK V2J24S4" auf meinem ST-Link V2.
Hmm, ok. Eigentlich sollte ab der 24 auch "dapdirect" unterstützt werden.
Ich hatte letztens erst Probleme mit einer zu neuen Firmware auf dem ST-Link.
Du kannst es ja mal mit der aus meinem Github Repo versuchen:
https://github.com/jp112sdl/HM-Sec-SCo- ... rmware-bug
Vielen Dank. Die Kombination aus der Firmware vom GitHub Repo und einem anderen Rechner mit ausschließlich USB 2.0 Schnittstellen führte zum Erfolg.

hurricane90
Beiträge: 2
Registriert: 30.12.2022, 10:45
System: CCU
Hat sich bedankt: 2 Mal

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von hurricane90 » 30.12.2022, 11:10

Hallo zusammen,

zunächst einmal finde ich das Thema super spannend, vielen Dank an alle Beteiligten, die das so fleißig mit der Community teilen!
Ich habe die Ensprerrung der SWD-Schnittstelle jetzt an 2 Geräten getestet und stoße dabei bei beiden auf das folgende Problem: nach der Entsperrung und dem Reset der MCU wird diese nicht erkannt.

Code: Alles auswählen

Open On-Chip Debugger 0.12.0-rc3+dev-01000-gdfe57baa1 (2022-12-27-08:53)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "dapdirect_swd". To override use 'transport select <transport>'.
cortex_m reset_config sysresetreq

Info : STLINK V2J37S0 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.898996
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x2ba01477
Error: [efm32.cpu] Cortex-M PARTNO 0x3 is unrecognized
Die Debug-Ausgabe liefert folgendes:

Code: Alles auswählen

Debug: 116 744 arm_dap.c:97 dap_init_all(): Initializing all DAPs ...
Debug: 117 744 arm_dap.c:121 dap_init_all(): DAP efm32.cpu configured by default to use ADIv5 protocol
Info : 118 744 stlink_usb.c:4158 stlink_dap_op_connect(): stlink_dap_op_connect(connect)
Debug: 119 744 arm_adi_v5.c:679 dap_dp_init(): efm32.dap
Debug: 120 744 arm_adi_v5.c:711 dap_dp_init(): DAP: wait CDBGPWRUPACK
Debug: 121 744 arm_adi_v5.h:638 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
Debug: 122 748 arm_adi_v5.c:719 dap_dp_init(): DAP: wait CSYSPWRUPACK
Debug: 123 748 arm_adi_v5.h:638 dap_dp_poll_register(): DAP: poll 4, mask 0x80000000, value 0x80000000
Debug: 124 753 stlink_usb.c:2020 stlink_usb_idcode(): IDCODE: 0x2BA01477
Info : 125 753 stlink_usb.c:4185 stlink_dap_op_connect(): SWD DPIDR 0x2ba01477
Debug: 126 753 openocd.c:151 handle_init_command(): Examining targets...
Debug: 127 753 target.c:1843 target_call_event_callbacks(): target event 19 (examine-start) for core efm32.cpu
Debug: 128 753 arm_adi_v5.c:1095 dap_get_ap(): refcount AP#0x0 get 1
Debug: 129 754 arm_adi_v5.c:1038 dap_find_get_ap():Found MEM-AP AHB3 at AP index: 0 (IDR=0x24770011)
Debug: 130 758 arm_adi_v5.c:825 mem_ap_init(): MEM_AP Packed Transfers: disabled
Debug: 131 758 arm_adi_v5.c:836 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
Debug: 132 760 target.c:2628 target_read_u32(): address:0xe000ed00, value: 0x02010030
Error: 133 760 cortex_m.c:2363 cortex_m_examine(): [efm32.cpu] Cortex-M PARTNO 0x3 is unrecognized
Debug: 134 760 target.c:1843 target_call_event_callbacks(): target event 20 (examine-fail) for core efm32.cpu
Warn : 135 760 target.c:802 target_examine(): target efm32.cpu examination failed
Debug: 136 760 openocd.c:153 handle_init_command(): target examination failed
Debug: 137 760 command.c:155 script_debug(): command - flash init
Debug: 138 760 tcl.c:1375 handle_flash_init_command(): Initializing flash devices...
Debug: 139 760 command.c:155 script_debug(): command - nand init
Debug: 140 760 tcl.c:487 handle_nand_init_command(): Initializing NAND devices...
Debug: 141 760 command.c:155 script_debug(): command - pld init
Debug: 142 760 pld.c:194 handle_pld_init_command(): Initializing PLDs...
Debug: 143 760 command.c:155 script_debug(): command - tpiu init
Info : 144 760 gdb_server.c:3791 gdb_target_start(): starting gdb server for efm32.cpu on 3333
Info : 145 760 server.c:297 add_service(): Listening on port 3333 for gdb connections
Debug: 146 760 command.c:155 script_debug(): command - reset init
Debug: 147 760 target.c:1862 target_call_reset_callbacks(): target reset 3 (init)
Debug: 148 761 command.c:155 script_debug(): command - expr [catch {ocd_process_reset_inner $MODE} result] == 0
Debug: 149 761 command.c:155 script_debug(): command - target names
Debug: 150 761 command.c:155 script_debug(): command - efm32.cpu invoke-event reset-start
Debug: 151 761 command.c:155 script_debug(): command - transport select
Debug: 152 761 command.c:155 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 153 761 command.c:155 script_debug(): command - transport select
Debug: 154 761 command.c:155 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 155 761 command.c:155 script_debug(): command - efm32.cpu invoke-event examine-start
Debug: 156 761 command.c:155 script_debug(): command - efm32.cpu arp_examine allow-defer
Debug: 157 765 arm_adi_v5.c:825 mem_ap_init(): MEM_AP Packed Transfers: disabled
Debug: 158 765 arm_adi_v5.c:836 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
Debug: 159 767 target.c:2628 target_read_u32(): address: 0xe000ed00, value: 0x02010030
Error: 160 767 cortex_m.c:2363 cortex_m_examine(): [efm32.cpu] Cortex-M PARTNO 0x3 is unrecognized
Debug: 161 767 command.c:155 script_debug(): command - efm32.cpu invoke-event examine-fail
Debug: 162 767 command.c:155 script_debug(): command - efm32.cpu invoke-event reset-assert-pre
Debug: 163 767 command.c:155 script_debug(): command - transport select
Debug: 164 767 command.c:155 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 165 767 command.c:155 script_debug(): command - efm32.cpu arp_reset assert 1
Debug: 166 767 target.c:2199 target_free_all_working_areas_restore(): freeing all working areas
Debug: 167 767 cortex_m.c:1401 cortex_m_assert_reset(): [efm32.cpu] target->state: unknown, not examined
Debug: 168 773 cortex_m.c:1516 cortex_m_assert_reset(): [efm32.cpu] Using Cortex-M SYSRESETREQ
Debug: 169 774 arm_adi_v5.c:754 dap_dp_init_or_reconnect(): efm32.dap
Debug: 170 774 arm_adi_v5.c:679 dap_dp_init(): efm32.dap
Debug: 171 774 arm_adi_v5.c:711 dap_dp_init(): DAP: wait CDBGPWRUPACK
Debug: 172 774 arm_adi_v5.h:638 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
Debug: 173 775 arm_adi_v5.c:719 dap_dp_init(): DAP: wait CSYSPWRUPACK
Debug: 174 775 arm_adi_v5.h:638 dap_dp_poll_register(): DAP: poll 4, mask 0x80000000, value 0x80000000
Debug: 175 827 command.c:155 script_debug(): command - efm32.cpu invoke-event reset-assert-post
Debug: 176 827 command.c:155 script_debug(): command - efm32.cpu invoke-event reset-deassert-pre
Debug: 177 827 command.c:155 script_debug(): command - transport select
Debug: 178 827 command.c:155 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 179 827 command.c:155 script_debug(): command - efm32.cpu arp_reset deassert 1
Debug: 180 827 target.c:2199 target_free_all_working_areas_restore(): freeing all working areas
Debug: 181 827 cortex_m.c:1569 cortex_m_deassert_reset(): [efm32.cpu] target->state: reset, not examined
Debug: 182 827 command.c:155 script_debug(): command - efm32.cpu invoke-event reset-deassert-post
Debug: 183 827 command.c:155 script_debug(): command - transport select
Debug: 184 827 command.c:155 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 185 827 command.c:155 script_debug(): command - efm32.cpu was_examined
Debug: 186 827 command.c:155 script_debug(): command - efm32.cpu examine_deferred
Debug: 187 827 command.c:155 script_debug(): command - efm32.cpu invoke-event examine-start
Debug: 188 827 command.c:155 script_debug(): command - efm32.cpu arp_examine allow-defer
Debug: 189 829 arm_adi_v5.c:825 mem_ap_init(): MEM_AP Packed Transfers: disabled
Debug: 190 829 arm_adi_v5.c:836 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
Debug: 191 830 target.c:2628 target_read_u32(): address:[color=#BF0040] 0xe000ed00, value: 0x05fa0030[/color]
Error: 192 830 cortex_m.c:2363 cortex_m_examine(): [efm32.cpu] Cortex-M PARTNO 0x3 is unrecognized
Debug: 193 830 command.c:155 script_debug(): command - efm32.cpu invoke-event examine-fail
Debug: 194 830 command.c:544 run_command(): Command 'reset' failed with error code -4
Im Logic Analyzer habe ich dann nachvollzogen, was von der Adresse 0xe000ed00, wo die CPUID liegt, geliefert wird. In der Ausgabe findet man zwei Mal die Anfrage wieder, mit unterschiedlichen Werten:

Code: Alles auswählen

Debug: 132 760 target.c:2628 target_read_u32(): address:0xe000ed00, value: 0x02010030
Error: 133 760 cortex_m.c:2363 cortex_m_examine(): [efm32.cpu] Cortex-M PARTNO 0x3 is unrecognized
und

Code: Alles auswählen

Debug: 191 830 target.c:2628 target_read_u32(): address: 0xe000ed00, value: 0x05fa0030
Error: 192 830 cortex_m.c:2363 cortex_m_examine(): [efm32.cpu] Cortex-M PARTNO 0x3 is unrecognized
Das verwundert mich schon mal, da laut TRM das Register Read-Only sein soll, also eigentlich den gleichen Wert liefern.
Spannenderweise finde ich im LA allerdings die folgenden Sequenzen in der Reihenfolge wieder:
seq1.png
seq2.png
seq3.png
seq4.png
Wie man sieht, wird zu Beginn eine CPUID aufgezeichnet, die laut dem TRM auch dem ARM Cortex-M3 r2p0 entspricht (0x412FC230). Das scheint aber nicht die Abfrage zu sein, die für den Debugger essenziell ist, wiel die nachfolgenden Requests an die Adresse Müll zurückliefern. Ich stecke jetzt nicht sonderlich tief in dem Thema drin, also vielleicht könnt ihr mir helfen und ein Paar Tipps geben, an welcher Stelle etwas schiefgelaufen ist. Hat schon jemand ein solches Verhalten beobachten können? Wie gesagt, das trat bei mir jetzt schon bei 2 Geräten auf, dass nach dem Unlock die CPUID 0x02010030 zurückkommt, die falsch ist. Meine letzte Annahme ist, dass die MCUs einfach flöten gegangen sind während des Unlocks. Aber woher kommt dann in der Anfangssequenz die korrekte CPUID einmalig her? Ich nutze das SMT32F4-Discovery-Board als externen ST-Link V2. Kann es sein, dass die ID von dem internen Cortex-M3 des Boards kommt und gar nicht von meinem Türkontakt?

teH_wHoly
Beiträge: 4
Registriert: 09.11.2022, 12:05
System: Alternative CCU (auf Basis OCCU)

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von teH_wHoly » 09.01.2023, 10:34

kafisc hat geschrieben:
09.12.2022, 19:05
jp112sdl hat geschrieben:
08.12.2022, 20:33
kafisc hat geschrieben:
08.12.2022, 19:56
Es läuft die: "STLINK V2J24S4" auf meinem ST-Link V2.
Hmm, ok. Eigentlich sollte ab der 24 auch "dapdirect" unterstützt werden.
Ich hatte letztens erst Probleme mit einer zu neuen Firmware auf dem ST-Link.
Du kannst es ja mal mit der aus meinem Github Repo versuchen:
https://github.com/jp112sdl/HM-Sec-SCo- ... rmware-bug
Vielen Dank. Die Kombination aus der Firmware vom GitHub Repo und einem anderen Rechner mit ausschließlich USB 2.0 Schnittstellen führte zum Erfolg.
Danke für die Info! Damit klappt es jetzt auch bei mir den Schreibschutz aufzuheben. Lag wohl an der Firmware Version des Sticks.

jp112sdl
Beiträge: 11916
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 828 Mal
Danksagung erhalten: 2080 Mal
Kontaktdaten:

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von jp112sdl » 09.01.2023, 13:18

hurricane90 hat geschrieben:
30.12.2022, 11:10
Ich nutze das SMT32F4-Discovery-Board als externen ST-Link V2. Kann es sein, dass die ID von dem internen Cortex-M3 des Boards kommt und gar nicht von meinem Türkontakt?
Möglich. Ich hab ein EFM32-G8XX-STK Board mit J-Link. Da muss man auch erst explizit konfigurieren, ob man die aufgelötete MCU oder eine externe ansprechen möchte.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

hurricane90
Beiträge: 2
Registriert: 30.12.2022, 10:45
System: CCU
Hat sich bedankt: 2 Mal

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von hurricane90 » 09.01.2023, 15:53

jp112sdl hat geschrieben:
09.01.2023, 13:18
hurricane90 hat geschrieben:
30.12.2022, 11:10
Ich nutze das SMT32F4-Discovery-Board als externen ST-Link V2. Kann es sein, dass die ID von dem internen Cortex-M3 des Boards kommt und gar nicht von meinem Türkontakt?
Möglich. Ich hab ein EFM32-G8XX-STK Board mit J-Link. Da muss man auch erst explizit konfigurieren, ob man die aufgelötete MCU oder eine externe ansprechen möchte.
Das ist beim Discovery ähnlich, allerdings wird die Umkonfigurierung zum externen Debugger durch Entfernung von 2 Jumpern vorgenommen. Die Konfiguration an sich sollte also passen, da optisch einfach zu unterscheiden...

Habe jetzt auch noch mal verglichen, die (Cortex-M3) ID wird im LA bei gesperrter MCU so auch gar nicht aufgezeichnet.

teH_wHoly
Beiträge: 4
Registriert: 09.11.2022, 12:05
System: Alternative CCU (auf Basis OCCU)

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von teH_wHoly » 10.01.2023, 12:06

Nachdem ich jetzt den Sensor am Homematic angelernt und die Verschlüsselung deaktiviert habe scheint alles prima zu funktionieren mit dem Arduino Sketch! Ich habe mal versucht den Stromverbrauch zu messen, da ich einige Energiesparfunktionen im Sketch sehen konnte, aber leider war der Verbrauch immer im OL-Bereich bei meinem Multimeter im uA Bereich. Gibt es hier noch Aktivitäten bei der Integration des STM32 im allgemeinen / ist das im Sketch noch nicht final, oder entspricht das einem Wert, der mit dem STM32 erwartet wird? Es könnte auch sein, dass der Shunt meines Multimeters einfach zu viel war für die Versorgung, aber ich hatte extra beim Hochlauf das Multimeter überbrückt und erst im Standby dann die Brücke entfernt.

jp112sdl
Beiträge: 11916
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 828 Mal
Danksagung erhalten: 2080 Mal
Kontaktdaten:

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von jp112sdl » 10.01.2023, 12:45

teH_wHoly hat geschrieben:
10.01.2023, 12:06
aber leider war der Verbrauch immer im OL-Bereich bei meinem Multimeter im uA Bereich. Gibt es hier noch Aktivitäten bei der Integration des STM32 im allgemeinen / ist das im Sketch noch nicht final, oder entspricht das einem Wert, der mit dem STM32 erwartet wird?
viewtopic.php?f=76&t=74413&start=30#p724426
Zuletzt geändert von jp112sdl am 10.01.2023, 12:46, insgesamt 1-mal geändert.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
stan23
Beiträge: 1997
Registriert: 13.12.2016, 21:14
System: Alternative CCU (auf Basis OCCU)
Wohnort: Altmühltal
Hat sich bedankt: 554 Mal
Danksagung erhalten: 320 Mal
Kontaktdaten:

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von stan23 » 10.01.2023, 12:45

Der Prozessor wacht alle 500 ms auf um die "Lichtschranke" zu messen.
So schnell kannst du dein Multimeter nicht umschalten :)

Mit 5000 in dieser Zeile könnte es klappen:
https://github.com/jp112sdl/HM-Sec-SCo- ... 2.ino#L182
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

daskorn
Beiträge: 1
Registriert: 30.06.2023, 22:50
System: Alternative CCU (auf Basis OCCU)

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von daskorn » 30.06.2023, 22:53

Hallo,

ist mit einer solchen Firmware auch eine direkte Verknüpfung z.B. mit einem HM-CC-RT-DN Thermostat möglich?

Viele Grüße
DasKorn

Carlos74
Beiträge: 10
Registriert: 11.09.2022, 09:21
System: CCU
Hat sich bedankt: 1 Mal

Re: HM-Sec-SCo - alternative Firmware mit AskSinPP

Beitrag von Carlos74 » 20.10.2023, 16:21

Hallo zusammen,

das Thema finde ich super spannend und habe eine Frage dazu.
Ich habe mir kürzlich 3x HM-Sec-SCo gekauft aber leider nicht auf dem Schirm gehabt dass eine Direktverküpfung mit HMIP nicht möglich ist.
Bevor ich jetzt mir die Arbeit mache und diese neu flashe würde ich gerne wissen mit welchem System sind die anschließend kompatibel?
Bleiben sie HM geräte, oder wären sie anschließend auch mit HMIP zu verwenden? Also nicht über die Zentrale sondern per Direktverknüpfung. Oder geht das alles dann nur über die Zentrale?

VG

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“