3. Is MySensors RPI GW 32bit only?

Is MySensors RPI GW 32bit only?

  • joaoabs

    Apologies if this is a repeated thread.
    I've been trying to compile a MQTT GW for my 64bit RPI4 but I'm getting some errors that seem to be related with the 64bit arch I'm using.

    I'm currently preparing a RPI4 for a IOT stack with docker containers and I believe using the RPI4 64bit capability would be useful to have a performant system.
    (by the way, it would be great to have a forum topic teaching how to create a docker container with the MySensors GW, but that would be for another time).

    Anyway, back to my issue, below the steps I've taken. I've tried master and development branches. Is there any way of making this work in 64bits or am I doing something wrong?

    Cheers,

    pi@raspberrypi:~ $ git clone https://github.com/mysensors/MySensors.git --branch development
Cloning into 'MySensors'...
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 17996 (delta 0), reused 2 (delta 0), pack-reused 17988
Receiving objects: 100% (17996/17996), 28.13 MiB | 5.28 MiB/s, done.
Resolving deltas: 100% (11015/11015), done.
pi@raspberrypi:~ $ cd MySensors/
pi@raspberrypi:~/MySensors $ ./configure --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=MySensorsGW --my-transport=rfm69 --my-rfm69-cs-pin=24 --my-signing=software --my-signing-request-signatures --my-rfm69-frequency=868 --my-is-rfm69hw
[SECTION] Detecting target machine.
  [OK] machine detected: SoC=BCM2711, Type=rpi4, CPU=aarch64.
[SECTION] Detecting SPI driver.
  [OK] SPI driver detected:BCM.
[SECTION] Gateway configuration.
  [OK] Type: mqtt.
  [OK] Transport: rfm69.
  [OK] Signing: Enabled - Using key from config file.
  [OK] Encryption: Disabled.
  [OK] CPPFLAGS: -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -DMY_SIGNING_REQUEST_SIGNATURES -DMY_SIGNING_SOFT -DMY_RADIO_RFM69 -DMY_RFM69_NEW_DRIVER -DMY_GATEWAY_LINUX -DMY_GATEWAY_MQTT_CLIENT -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_IS_RFM69HW -DMY_RFM69_FREQUENCY=RFM69_868MHZ -DMY_RFM69_CS_PIN=24 -DMY_MQTT_CLIENT_ID="MySensorsGW" -DMY_MQTT_SUBSCRIBE_TOPIC_PREFIX="mysensors-in" -DMY_MQTT_PUBLISH_TOPIC_PREFIX="mysensors-out" -DMY_CONTROLLER_IP_ADDRESS=127,0,0,1
  [OK] CXXFLAGS:  -std=c++11
[SECTION] Detecting init system.
  [OK] Init system detected: systemd.
[SECTION] Saving configuration.
  [OK] Saved.
[SECTION] Cleaning previous builds.
  [OK] Finished.
pi@raspberrypi:~/MySensors $ make
gcc -MT build/hal/architecture/Linux/drivers/core/log.o -MMD -MP -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -DMY_SIGNING_REQUEST_SIGNATURES -DMY_SIGNING_SOFT -DMY_RADIO_RFM69 -DMY_RFM69_NEW_DRIVER -DMY_GATEWAY_LINUX -DMY_GATEWAY_MQTT_CLIENT -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_IS_RFM69HW -DMY_RFM69_FREQUENCY=RFM69_868MHZ -DMY_RFM69_CS_PIN=24 -DMY_MQTT_CLIENT_ID=\"MySensorsGW\" -DMY_MQTT_SUBSCRIBE_TOPIC_PREFIX=\"mysensors-in\" -DMY_MQTT_PUBLISH_TOPIC_PREFIX=\"mysensors-out\" -DMY_CONTROLLER_IP_ADDRESS=127,0,0,1  -Ofast -g -Wall -Wextra  -I. -I./core -I./hal/architecture/Linux/drivers/core -I./hal/architecture/Linux/drivers/BCM -c hal/architecture/Linux/drivers/core/log.c -o build/hal/architecture/Linux/drivers/core/log.o
gcc: error: unrecognized command line option ‘-mfpu=neon-fp-armv8’
gcc: error: unrecognized command line option ‘-mfloat-abi=hard’
make: *** [Makefile:103: build/hal/architecture/Linux/drivers/core/log.o] Error 1
pi@raspberrypi:~/MySensors $ uname -a
Linux raspberrypi 5.4.79-v8+ #1373 SMP PREEMPT Mon Nov 23 13:32:41 GMT 2020 aarch64 GNU/Linux
    0 joaoabs 1 Reply
  • joaoabs

    Answering my own post with info from this post from 2018 and adjusting to my chipset (BCM2711), I commented the flags. Not sure what I'm doing, but at least the error is not the same anymore.

    function gcc_cpu_flags {
    local soc=$1
    case $soc in
    BCM2835)
        flags="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"
        ;;
    BCM2836)
        flags="-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"
        ;;
    BCM2837)
        flags="-march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard"
        ;;
    BCM2711)
        flags=""
        #flags="-march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard"
        ;;

    Moving on to the next error.

    Cheers,
    Joaoabs

    0
  • mfalkvidd
    Mod

    The gateway is not intentionally 32-bit only. You're probably just the first person who tries to make it work on 64-bit.

    2 joaoabs 1 Reply
  • joaoabs

    I admit I'm not a programmer neither a computing expert.

    But this article here says that "Generally speaking, 32-bit programs can run on a 64-bit system, but 64-bit programs will not run on a 32-bit system."

    My understanding is that if I compile MySensors GW in a 32bit RasPI OS and copy & run it on RasPI 64bit OS it will likely work (I'm guessing I'll also have to copy some libraries, so not so simple as copying the binary).
    This can be the option for those who want to use MySensors in 64bit RPIs like myself. I'll be using IoTStack on a RPI4 4GB 64bit with zigbee2MQTT and honestly wasn't happy with the idea of having a second RPI just for MySensors GW.

    I'll try it during the weekend and share results here.

    0
  • joaoabs

    So I managed to successfully run MySensorsGW in a RPI4 with 64bit OS, based on the theoretical premise that a 32bit binary can run in a 64bit system.

    My project idea is to have a central device running my house automation. For that, I use and RPI4 4GB with IoT stack witch is a set of docker images each one with a specific function. This way, I'll be running MQTT Mosquito, NodeRed, zigbee2MQTT, inFluxDB and Graphana, each one in its own docker container. IoT stack also includes other images like transmission torrent, nextcloud, PiHole, etc. I might also use some of it later on.
    Anyway, all of this requires a lot of effort from the little RPI4 so it is important to be able to use all of its resources. Using a 64bit OS is one way to have a more performant system and to be able to address all the RAM (4GB in my case).

    So, having mysgw in this RPI was crucial to maintain a small footprint. It would be great to have the MySensors GW as a docker container as well, but for now this workaround would have to sufice.

    Compiling mswg in RPI 64bit OS is not working (as per the above), but compiling it in a 32bit RPI OS and then copying a couple of files to the RPI 64bit OS it works, at least in my case. My msgw is configured as a MQTT GW, so if yours is different, your millenage may vary.

    ./configure --my-gateway=mqtt --my-controller-ip-address=192.168.2.180 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=MySensorsGW --my-transport=rfm69 --my-signing=software --my-signing-request-signatures --my-rfm69-frequency=433 --my-is-rfm69hw --my-signing-debug --my-rfm69-encryption-enabled --my-mqtt-user=mysensorsuser --my-mqtt-password=mysensorspassword

    (Now I can change the --my-controller-ip-address to 127.0.0.1. This way, if for some reason I want to change the controller IP address, I'll not need to re-compile)

    Anyway, so the process is basically compiling everything in the 32bit RPI OS, (configure, make, sudo make install), configure the /etc/sensors.conf accordingly and then coping these files to the same path in the 64bit RPI OS:

    /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
/etc/mysensors.conf
/etc/systemd/system/mysgw.service
/usr/local/bin/mysgw

    Run it as normal:

    sudo systemctl start mysgw.service

    Enjoy 🙂

    Dec 04 12:34:57 INFO  Starting gateway...
Dec 04 12:34:57 INFO  Protocol version - 2.3.2
Dec 04 12:34:57 DEBUG MCO:BGN:INIT GW,CP=RPNGLS-X,FQ=NA,REL=255,VER=2.3.2
Dec 04 12:34:57 DEBUG SGN:PER:OK
Dec 04 12:34:57 DEBUG SGN:INI:BND OK
Dec 04 12:34:57 DEBUG TSF:LRT:OK
Dec 04 12:34:57 DEBUG TSM:INIT
Dec 04 12:34:57 DEBUG TSF:WUR:MS=0
Dec 04 12:34:57 DEBUG TSM:INIT:TSP OK
Dec 04 12:34:57 DEBUG TSM:INIT:GW MODE
Dec 04 12:34:57 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Dec 04 12:34:57 DEBUG MCO:REG:NOT NEEDED
Dec 04 12:34:57 DEBUG MCO:BGN:STP
Dec 04 12:34:57 DEBUG MCO:BGN:INIT OK,TSP=1
Dec 04 12:34:57 DEBUG GWT:RMQ:CONNECTING...
Dec 04 12:34:57 DEBUG connected to 192.168.2.180
Dec 04 12:34:57 DEBUG GWT:RMQ:OK
Dec 04 12:34:57 DEBUG GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT
Dec 04 12:34:57 DEBUG TSM:READY:NWD REQ
Dec 04 12:34:57 DEBUG SGN:SGN:NREQ=255
Dec 04 12:34:57 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
Dec 04 12:44:37 DEBUG TSF:MSG:READ,80-80-255,s=255,c=3,t=7,pt=0,l=0,sg=1:
Dec 04 12:44:37 DEBUG TSF:MSG:BC
Dec 04 12:44:37 DEBUG TSF:MSG:FPAR REQ,ID=80
Dec 04 12:44:37 DEBUG TSF:PNG:SEND,TO=0
Dec 04 12:44:37 DEBUG TSF:CKU:OK
Dec 04 12:44:37 DEBUG TSF:MSG:GWL OK
Dec 04 12:44:37 DEBUG SGN:SKP:MSG CMD=3,TYPE=8
Dec 04 12:44:38 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
Dec 04 12:44:41 DEBUG TSF:MSG:READ,80-80-0,s=255,c=3,t=24,pt=1,l=1,sg=1:1
Dec 04 12:44:41 DEBUG SGN:SKP:MSG CMD=3,TYPE=24
Dec 04 12:44:41 DEBUG TSF:MSG:PINGED,ID=80,HP=1
Dec 04 12:44:41 DEBUG SGN:SKP:MSG CMD=3,TYPE=25
Dec 04 12:44:41 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
Dec 04 12:45:40 DEBUG TSF:MSG:READ,80-80-0,s=20,c=3,t=16,pt=0,l=0,sg=1:
Dec 04 12:45:40 DEBUG SGN:SKP:MSG CMD=3,TYPE=16
Dec 04 12:45:40 DEBUG SGN:SKP:MSG CMD=3,TYPE=17
Dec 04 12:45:41 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
Dec 04 12:45:41 DEBUG SGN:NCE:XMT,TO=0
Dec 04 12:45:41 DEBUG TSF:MSG:READ,80-80-0,s=20,c=1,t=0,pt=7,l=5,sg=1:14.0
Dec 04 12:45:41 DEBUG SGN:BND:NONCE=607CD378A13D593F9957DAC6077B64FEDC18063A8A3FC7EA50AAAAAAAAAAAAAA
Dec 04 12:45:41 DEBUG SGN:BND:HMAC=F0DA2FBCD8AED09526D29E9C6AF7873076303A8E6F6F0FAB258BE29031DA29EB
Dec 04 12:45:41 DEBUG SGN:VER:OK
Dec 04 12:45:41 DEBUG GWT:TPS:TOPIC=mysensors-out/80/20/1/0/0,MSG SENT
Dec 04 12:45:42 DEBUG TSF:MSG:READ,80-80-0,s=40,c=3,t=16,pt=0,l=0,sg=1:
Dec 04 12:45:42 DEBUG SGN:SKP:MSG CMD=3,TYPE=16
Dec 04 12:45:42 DEBUG SGN:SKP:MSG CMD=3,TYPE=17
Dec 04 12:45:42 DEBUG TSF:MSG:SEND,0-0-80-80,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
Dec 04 12:45:42 DEBUG SGN:NCE:XMT,TO=0
Dec 04 12:45:43 DEBUG TSF:MSG:READ,80-80-0,s=40,c=1,t=1,pt=7,l=5,sg=1:64.0
Dec 04 12:45:43 DEBUG SGN:BND:NONCE=AB465A4A24BDDF89CC30C3F30F4F4B519ECDDC2843FF725874AAAAAAAAAAAAAA
Dec 04 12:45:43 DEBUG SGN:BND:HMAC=62C90515061BA556B4CF4F7ECB3FE224E54BE1ED8A2522AB8E8A1FA192B738C4
Dec 04 12:45:43 DEBUG SGN:VER:OK
Dec 04 12:45:43 DEBUG GWT:TPS:TOPIC=mysensors-out/80/40/1/0/1,MSG SENT

    pi@raspberrypi:~/MySensors $ uname -a
Linux raspberrypi 5.4.79-v8+ #1373 SMP PREEMPT Mon Nov 23 13:32:41 GMT 2020 aarch64 GNU/Linux

    Cheers

    1 fixjunk 1 Reply
  • fixjunk

    FYI I was able to get the gateway to work properly on a 64 bit Raspberry pi 400 machine.

    pi@sixfour:~ $ cat /proc/cpuinfo | grep Model && uname -a
Model		: Raspberry Pi 400 Rev 1.0
Linux sixfour 5.10.5-v8+ #1392 SMP PREEMPT Sat Jan 9 18:56:30 GMT 2021 aarch64 GNU/Linux

    I'm not sure if it's required, but installing the bcm2835 v 1.68 (that includes an earlier patch for pi 4) may have helped along with removing the bcm2711 flags from the configure file.

    pi@sixfour:~/MySensors $ ./configure  --my-gateway=serial --my-serial-is-pty --my-serial-pty=/dev/ttymysgw --my-rf24-ce-pin=22 --my-rf24-cs-pin=24 --my-rf24-irq-pin=15 --my-serial-groupname=dialout --soc=BCM2711
Warning: --my-serial-pty is deprecated, please use --my-serial-port
[SECTION] Detecting SPI driver.
  [OK] SPI driver detected:BCM.
[SECTION] Gateway configuration.
  [OK] Type: serial.
  [OK] Transport: rf24.
  [OK] Signing: Disabled.
  [OK] Encryption: Disabled.
  [OK] CPPFLAGS:  -DMY_RADIO_RF24 -DMY_GATEWAY_SERIAL -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_LINUX_SERIAL_GROUPNAME="dialout" -DMY_RX_MESSAGE_BUFFER_FEATURE -DMY_RF24_IRQ_PIN=15 -DMY_RF24_CS_PIN=24 -DMY_RF24_CE_PIN=22 -DMY_LINUX_SERIAL_PORT="/dev/ttymysgw" -DMY_LINUX_SERIAL_IS_PTY 
  [OK] CXXFLAGS:  -std=c++11
[SECTION] Detecting init system.
  [OK] Init system detected: systemd.
[SECTION] Saving configuration.
  [OK] Saved.
[SECTION] Cleaning previous builds.
  [OK] Finished.

    granted I have not fully tested this since I do not yet have a radio connected, but I think it went ok.

    Jan 28 15:08:50 INFO  Starting gateway...
Jan 28 15:08:50 INFO  Protocol version - 2.3.2
Jan 28 15:08:50 DEBUG Serial port /dev/ttymysgw (115200 baud) created
Jan 28 15:08:50 DEBUG MCO:BGN:INIT GW,CP=RNNGL-Q-,FQ=NA,REL=255,VER=2.3.2
Jan 28 15:08:50 DEBUG TSF:LRT:OK
Jan 28 15:08:50 DEBUG TSM:INIT
Jan 28 15:08:50 DEBUG TSF:WUR:MS=0
Jan 28 15:08:50 DEBUG !TSM:INIT:TSP FAIL
Jan 28 15:08:50 DEBUG TSM:FAIL:CNT=1
Jan 28 15:08:50 DEBUG TSM:FAIL:DIS
Jan 28 15:08:50 DEBUG TSF:TDI:TSL
Jan 28 15:09:00 DEBUG TSM:FAIL:RE-INIT
Jan 28 15:09:00 DEBUG TSM:INIT
Jan 28 15:09:00 DEBUG !TSM:INIT:TSP FAIL

    I will plop a radio in this weekend and see if it still works.

    2
  • fixjunk

    Just a small addendum...

    I tried swapping my Pi3B+ install into a Pi 400 with the BCM2711 and it did not work.

    I needed both the BCM2835 v 1.68 and to remove the flags from the "configure" script BCM2711 section.

    2
  • Dmitry Cherkas

    To anyone, who will come here searching for a way to compile MySensors Gateway on 64bit OS, here is how I managed to do that on Ubuntu Server 20.04:

    ubuntu@ubuntu:~ $ cat /proc/cpuinfo | grep Model && uname -a
Model           : Raspberry Pi 4 Model B Rev 1.4
Linux rpi-ubuntu-server 5.4.0-1034-raspi #37-Ubuntu SMP PREEMPT Mon Apr 12 23:14:49 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
    1. Make sure to use development branch(git clone https://github.com/mysensors/MySensors.git --branch development), otherwise you may face fatal error: stropts.h: No such file or directory [1], which is not fixed in master branch.
    2. As I understood from [2] and [3], unrecognized command line options (-mfpu=neon-fp-armv8 -mfloat-abi=hard) are not valid for ARMv8 AArch64 targets, so it's safe to remove them. I did that by updating ./configure as follows (in my case soc=BCM2711, so I left others intact):
    function gcc_cpu_flags {
    local soc=$1
    case $soc in
// ...
    BCM2711)
        flags="-march=armv8-a+crc -mtune=cortex-a72"
        ;;
// ...
}
    1. With above setup I was able to build Ethernet Gateway:
    /configure --my-gateway=ethernet --my-port=5003 --my-transport=rf24 --my-rf24-irq-pin=15 --soc=BCM2711

    [1] https://github.com/mysensors/MySensors/issues/1431
    [2] https://developer.arm.com/documentation/dui0774/b/compiler-command-line-options/-mfloat-abi
    [3] https://lists.linaro.org/pipermail/linaro-toolchain/2016-July/005815.html

    3
  • Dragos Pascale

    in hal/transport/RFM69/driver/new/RFM69_new.h you must also replace
    #define RFM69_MAX_PACKET_LEN (0x40u) with
    #define RFM69_MAX_PACKET_LEN (0x40ul)
    if you are using RFM69 radio

    1 joaoabs 1 Reply
  • joaoabs

    @Dragos-Pascale said in Is MySensors RPI GW 32bit only?:

    in hal/transport/RFM69/driver/new/RFM69_new.h you must also replace
    #define RFM69_MAX_PACKET_LEN (0x40u) with
    #define RFM69_MAX_PACKET_LEN (0x40ul)
    if you are using RFM69 radio

    @Dragos-Pascale Why that change? What is the behavior if you don't do it?

    0 joaoabs 1 Reply
  • joaoabs

    @joaoabs Got it. It doesn't compile if we don't replace the RFM69_MAX_PACKET_LEN (0x40ul) 🙂

    And I can confirm that the procedure above worked. Compiled directly in a RPI4 with 64bit OS.

    pi@raspberrypi:~ $ file /usr/local/bin/mysgw
/usr/local/bin/mysgw: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=beb479db20a0f93b0fc004832e06c8213d779bb6, for GNU/Linux 3.7.0, with debug_info, not stripped
    1
  • suspendfunction

    Anyone tried this with RFM69HCW?

    I got it compiled on Arch Linux ARM with the aarch64 linux-rpi kernel after editing ./configure and hal/transport/RFM69/driver/new/RFM69_new.h as described above.

    [root@alarm git]# cat /proc/cpuinfo | grep Model && uname -a
Model           : Raspberry Pi 4 Model B Rev 1.4
Linux netberry 6.1.11-2-rpi-ARCH #1 SMP PREEMPT Tue Feb 14 06:34:59 MST 2023 aarch64 GNU/Linux

    It runs, but doesn't communicate with the radio properly:

    [root@alarm MySensors]# ./bin/mysgw
Feb 16 13:20:45 INFO  Starting gateway...
Feb 16 13:20:45 INFO  Protocol version - 2.4.0-alpha
Feb 16 13:20:45 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=1,VER=2.4.0-alpha
Feb 16 13:20:45 DEBUG TSF:LRT:OK
Feb 16 13:20:45 DEBUG TSM:INIT
Feb 16 13:20:45 DEBUG TSF:WUR:MS=0
Feb 16 13:20:45 DEBUG RFM69:INIT
Feb 16 13:20:45 DEBUG RFM69:INIT:PIN,CS=24,IQP=22,IQN=25
Feb 16 13:20:45 DEBUG RFM69:PTX:LEVEL=5 dBm
Feb 16 13:20:45 DEBUG RFM69:DUMP:Registers Address | HEX value
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x01 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x02 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x03 Value=0x1a
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x04 Value=0x0b
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x05 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x06 Value=0x52
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x07 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x08 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x09 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0a Value=0x01
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0b Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0c Value=0x02
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0d Value=0x92
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0e Value=0xf5
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x0f Value=0x20
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x10 Value=0x24
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x11 Value=0x9f
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x12 Value=0x09
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x13 Value=0x1a
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x14 Value=0x40
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x15 Value=0xb0
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x16 Value=0x7b
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x17 Value=0x9b
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x18 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x19 Value=0x86
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1a Value=0x8a
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1b Value=0x40
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1c Value=0x80
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1d Value=0x06
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1e Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x1f Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x20 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x21 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x22 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x23 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x24 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x25 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x26 Value=0x05
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x27 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x28 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x29 Value=0xff
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2a Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2b Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2c Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2d Value=0x03
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2e Value=0x98
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x2f Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x30 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x31 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x32 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x33 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x34 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x35 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x36 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x37 Value=0x10
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x38 Value=0x40
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x39 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3a Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3b Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3c Value=0x0f
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3d Value=0x02
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3e Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x3f Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x40 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x41 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x42 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x43 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x44 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x45 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x46 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x47 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x48 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x49 Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4a Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4b Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4c Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4d Value=0x00
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4e Value=0x01
Feb 16 13:20:45 DEBUG RFM69:DUMP:REG=0x4f Value=0x00
Feb 16 13:20:45 DEBUG !RFM69:INIT:SANCHK FAIL
Feb 16 13:20:45 DEBUG !TSM:INIT:TSP FAIL
Feb 16 13:20:45 DEBUG TSM:FAIL:CNT=1
Feb 16 13:20:45 DEBUG TSM:FAIL:DIS
Feb 16 13:20:45 DEBUG TSF:TDI:TSL
Feb 16 13:20:45 DEBUG RFM69:RSL

    I have built commit aa520cea, the latest from the development branch, using this config:
    ./configure --my-gateway=ethernet --my-transport=rfm69 --my-is-rfm69hw --my-rfm69-frequency=868 --extra-cxxflags="-DMY_DEBUG_VERBOSE_RFM69 -DMY_DEBUG_VERBOSE_RFM69_REGISTERS"

    My hardware should be fine, i didn't change anything and it was working with the 32-bit kernel before.

    0
Log in to reply
 

Suggested Topics

  • hek


    Announcements •  

    3
  • DIY89


    Troubleshooting •  

    6
  • Gibber


    Troubleshooting •  

    8
  • se-O-matic


    Troubleshooting •  

    5
  • kamilb85


    Troubleshooting •  

    2

0
Online

11.4k
Users

11.1k
Topics

112.7k
Posts



Copyright 2019 Sensnology   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service