Raspberry Pi 4 hängt wenn Brick Deamon läuft und HAT Brick ist gesteckt

[R_Gerald]

Habe seit kurzen eine HAT Brick + ein paar Bricks.

Habe brickd und brickv laut Anleitung auf meinem Raspberry Pi 4 Modell installiert, und den HAT Brick 1.6 angesteckt.

Es hat den Anschein nachdem der brickd ausgeführt wird der Pi komplett ausgelastet und ist nicht mehr ansprechbar (ping zum PI funktioniert nicht mehr). Nach einem Neustart mit gestecktem HAT Brick ist der Pi kurz nach dem Hochlauf bedienbar, dann aber nicht mehr.

Wird der HAT Brick abgesteckt und neu gestartet funktioniert der Pi wieder und ich konnte das Log auslesen.

2021-09-20 13:30:12.653002 <I> <main_linux.c:367> Brick Daemon 2.4.3 started (pid: 543, daemonized: 1)
2021-09-20 13:30:18.918088 <I> <network.c:304> Added new client (N: 127.0.0.1:53614, T: plain-socket, H: 18/18, B: 0, P: 0, A: disabled)
2021-09-20 13:39:15.234342 <I> <network.c:304> Added new client (N: 127.0.0.1:53678, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled)
2021-09-20 13:40:36.183747 <I> <client.c:252> Client (N: 127.0.0.1:53678, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer
2021-09-20 13:40:37.240314 <I> <network.c:304> Added new client (N: 127.0.0.1:53700, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled)
2021-09-20 13:40:42.227717 <I> <client.c:252> Client (N: 127.0.0.1:53700, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer
2021-09-20 13:40:43.062705 <I> <network.c:304> Added new client (N: 127.0.0.1:53702, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled)
2021-09-20 13:40:43.853351 <I> <client.c:252> Client (N: 127.0.0.1:53702, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer
2021-09-20 13:40:44.597336 <I> <network.c:304> Added new client (N: 127.0.0.1:53704, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled)
2021-09-20 13:40:45.367081 <I> <client.c:252> Client (N: 127.0.0.1:53704, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer
2021-09-20 13:40:46.003491 <I> <network.c:304> Added new client (N: 127.0.0.1:53706, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled)
2021-09-20 13:40:46.661200 <I> <client.c:252> Client (N: 127.0.0.1:53706, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer
2021-09-20 13:40:47.536743 <I> <network.c:304> Added new client (N: 127.0.0.1:53710, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled)
2021-09-20 13:40:48.196749 <I> <client.c:252> Client (N: 127.0.0.1:53710, T: plain-socket, H: 19/19, B: 0, P: 0, A: disabled) disconnected by peer
2021-09-20 13:40:54.998926 <I> <signal.c:55> Received SIGTERM
2021-09-20 13:40:55.007573 <I> <main_linux.c:571> Brick Daemon 2.4.3 stopped
2021-09-20 13:40:58.554272 <I> <main_linux.c:367> Brick Daemon 2.4.3 started (pid: 534, daemonized: 1)
2021-09-20 13:40:58.660610 <I> <bricklet.c:270> Found supported HAT product_id 0x084e in device tree, using default HAT Brick config
2021-09-20 13:40:58.660728 <I> <bricklet.c:311> Found Bricklet port A (spidev: /dev/spidev0.0, driver: gpio, name: gpio23, num: 23)
2021-09-20 13:40:58.661002 <I> <bricklet_stack_linux.c:129> Using BCM2835 backend for Bricklets (Raspberry Pi detected)
2021-09-20 13:40:58.665155 <W> <bricklet_stack_linux_bcm2835.c:129> Raspberry Pi core frequency (core_freq: 500, core_freq_min: 200) is unstable, SPI throughput will be unstable too
2021-09-20 13:40:58.665256 <I> <bricklet_stack_linux_bcm2835.c:133> Using 500 MHz Raspberry Pi core frequency (core_freq: 500, core_freq_min: 200) for BCM2835 backend
2021-09-20 13:40:58.666350 <I> <bricklet.c:311> Found Bricklet port B (spidev: /dev/spidev0.0, driver: gpio, name: gpio22, num: 22)
2021-09-20 13:40:58.666683 <I> <bricklet.c:311> Found Bricklet port C (spidev: /dev/spidev0.0, driver: gpio, name: gpio25, num: 25)
2021-09-20 13:40:58.666957 <I> <bricklet.c:311> Found Bricklet port D (spidev: /dev/spidev0.0, driver: gpio, name: gpio26, num: 26)
2021-09-20 13:40:58.667342 <I> <bricklet.c:311> Found Bricklet port E (spidev: /dev/spidev0.0, driver: gpio, name: gpio27, num: 27)
2021-09-20 13:40:58.667650 <I> <bricklet.c:311> Found Bricklet port F (spidev: /dev/spidev0.0, driver: gpio, name: gpio24, num: 24)
2021-09-20 13:40:58.667950 <I> <bricklet.c:311> Found Bricklet port G (spidev: /dev/spidev0.0, driver: gpio, name: gpio7, num: 7)
2021-09-20 13:40:58.668207 <I> <bricklet.c:311> Found Bricklet port H (spidev: /dev/spidev0.0, driver: gpio, name: gpio6, num: 6)
2021-09-20 13:40:58.668484 <I> <bricklet.c:311> Found Bricklet port I (spidev: /dev/spidev0.0, driver: gpio, name: gpio5, num: 5)
hwclock: Timed out waiting for time change.
2021-09-20 13:41:00.287786 <I> <bricklet.c:358> Updated system time from RTC time using '/sbin/hwclock --hctosys'
2021-09-20 13:41:04.858382 <I> <network.c:304> Added new client (N: 127.0.0.1:53792, T: plain-socket, H: 27/27, B: 0, P: 0, A: disabled)
2021-09-20 13:42:15.613951 <E> <bricklet_stack.c:478> Message checksum error (port: A, count: 1)
2021-09-20 13:42:22.832849 <E> <bricklet_stack.c:478> Message checksum error (port: A, count: 2)
2021-09-20 13:42:11.298809 <I> <main_linux.c:367> Brick Daemon 2.4.3 started (pid: 532, daemonized: 1)
2021-09-20 13:42:18.245951 <I> <network.c:304> Added new client (N: 127.0.0.1:45096, T: plain-socket, H: 18/18, B: 0, P: 0, A: disabled)

 

Scheinbar wird der HAT Brick und das erste Bricklet gefunden. Gibt es ein Problem mit der core Frequenz?

 

 

 

[photron]

Hast du am HAT Brick noch Bricklets angeschlossen, oder ist das HAT Brick alleine? Falls Bricklets angeschlossen sind, macht es dann einen Unterschied, wenn du diese absteckst?

Welche Kernel Version läuft auf dem Raspberry Pi? Das kannst du mit folgenden Kommando abfragen:

uname -a

Brick Daemon kann auf zwei verschiedene Arten mit dem HAT Brick kommunizieren. Standardmäßig wird auf dem Raspberry Pi der BCM2835 Backend verwendet. Das kannst du an dieser Zeile sehen:

2021-09-20 13:40:58.661002 <I> <bricklet_stack_linux.c:129> Using BCM2835 backend for Bricklets (Raspberry Pi detected)

Du kannst brickd aber zwingen den spidev Backend zu verwenden. Dazu musst du die Datei /etc/brickd.conf bearbeiten und folgende Zeile anhängen:

bricklet.spi.driver = spidev

Um die Änderung zu übernehmen musst du dann brickd neustarten, oder das ganze Raspberry Pi neustarten. Das Kommando für den brickd Neustart ist:

sudo systemctl restart brickd

Wenn die Änderung geklappt hat sollte folgende Zeile im Log stehen:

Using spidev backend for Bricklets (forced by config)

Macht es dann einen Unterschied, wenn du auf das spidev Backend wechselst?

[R_Gerald]

Danke, jetzt kann läuft der Raspberry wenigsten auch mit der HAT Brick

 

Kernel

Linux raspberrypi 5.10.60-v7l+ #1449 SMP Wed Aug 25 15:00:44 BST 2021 armv7l GNU/Linux

 

Nach einiger Zeit erscheint sogar der Brick und die Bricklets im brick viewer, jedoch scheint es ein Problem mit der Kommunikation zu geben. Sie logs im Anhang
 

brickv_error_report_2021-09-20_16-13-53.txt brickd.log

[photron]

Laut Log treten da massive Kommunikationsprobleme zwischen Raspberry Pi und HAT Brick auf.

Wie kommst du auf Kernel 5.10.60? Wenn ich ein frisches Raspberry Pi OS Image mit dem Image Tool auf eine SD Karte dann bekomme ich Kernel 5.10.17. Hast du den Kernel mit rpi-update aktualisiert?

Bei mir tritt das Problem nicht auf. Weder mit Kernel 5.10.17 noch mit 5.10.60.

Hast du eine weitere SD Karte zur Hand auf der du ein frisches Raspberry Pi OS aufsetzen kannst? Oder hast du ein anderes Raspberry Pi zur Hand mit dem du testen kannst?

[R_Gerald]

JA habe den Raspberry schon eine weile in Betrieb und hab dann ein Update gemacht. Muss mir noch eine SD Karte besorgen, 2. Raspberry hab ich nicht zur Hand.

 

Schaut es eher nach einem SW oder HW Problem aus?  

[Backdraft007]

Hast Du Bricklets am HAT angeschlossen? Wie sieht es aus, wenn keine Bricklets angeschlossen sind?

[R_Gerald]

Hab nur den HAT auch versucht, macht aber keinen Unterschied. Bekomme morgen ein paar SD Karten und einen 2. Raspberry.....

[photron]

2 hours ago, R_Gerald said:

Schaut es eher nach einem SW oder HW Problem aus?

Kann beides sein. Daher die Fragen ob du mit frischer SD Karte oder anderem Raspberry Pi testen kannst. Es kann auch sein, dass der HAT Brick selbst einen Schaden hat.

Hast du die /etc/brickd.conf Änderung auf spidev gemacht? Laut Log wird immer noch der BCM2835 Treiber verwendet.

[R_Gerald]

Hab die config auf spidev geändert.

Schaffe jetzt auch eine Kommunikation zum Brick und den Bricklets. Möglicherweise ist der Kühlkörper vom Raspberry ein wenig im Weg, hab ihn mal ein wenig isoliert vom HAT.  Laut Health Monitor gibt es aber schon noch viele Checksum und Frame Erros. Morgen versuch ich das ganze nochmals auf einem anderen Raspberry PI.

Wenn ich spidev wieder auskommentiere ist der Raspbarry wieder nicht mehr ansprechbar. Woran liegt das?

 

Mein Ziel ist es eigentlich die Daten in die Cumulocity IoT Plattform zu übertragen.

Haben den Cumulocity Agent bereits eingerichtet und auch bereits in der Plattform registriert.

https://cumulocity.com/guides/device-tutorials/raspberry-pi-4/

 

Die Sensordaten der Child devices werden aber nicht übertragen es kommen diese Fehlermeldung am Raspberry PI

Sep 21 15:10:31 raspberrypi root: 15:10:31.161 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 111
Sep 21 15:10:31 raspberrypi root: 15:10:31.195 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 111
Sep 21 15:10:31 raspberrypi root: 15:10:31.230 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 290
Sep 21 15:10:31 raspberrypi root: 15:10:31.274 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 297
Sep 21 15:10:31 raspberrypi root: 15:10:31.309 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 292
Sep 21 15:10:31 raspberrypi root: 15:10:31.345 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 292
Sep 21 15:10:31 raspberrypi root: 15:10:31.377 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 290
Sep 21 15:10:31 raspberrypi root: 15:10:31.409 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 292
Sep 21 15:10:31 raspberrypi root: 15:10:31.443 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 297
Sep 21 15:10:31 raspberrypi root: 15:10:31.477 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 290
Sep 21 15:10:31 raspberrypi root: 15:10:31.518 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 292
Sep 21 15:10:31 raspberrypi root: 15:10:31.559 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 297
Sep 21 15:10:31 raspberrypi root: 15:10:31.595 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 111
Sep 21 15:10:31 raspberrypi root: 15:10:31.630 [Callback-Processor] WARN  c8y.tinkerforge.Discoverer - Unsuported device identifier: 111
 

Und in der Cumulocity Plattform sehe ich folgende Events

Meine Ausprägung

 

Liegt dies daran, dass spidev anstelle vom BCM2835 Treiber verwendt wird?

 

[photron]

1 hour ago, R_Gerald said:

Wenn ich spidev wieder auskommentiere ist der Raspbarry wieder nicht mehr ansprechbar. Woran liegt das?

Das ist die Frage hier! Wenn du in der Config nicht die spidev Zeile drin hast, dann verwendet Brick Daemon den BCM2835 Treiber um mit dem HAT Brick und den Bricklets zu kommunizieren. Wenn du die spidev Zeile drin hast, dann verwendet Brick Daemon stattdessen den spidev Treiber. Warum das jetzt einen Unterschied macht ist mir gerade unklar. Eigentlich ist der BCM2835 Treiber besser, da mit diesem der Durchsatz höher ist.

Das ist alles mit Kernel 5.10.60, oder? Interessant wäre zu sehen ob das mit 5.10.17 besser wird. Es kann sein, dass eine Kernel Änderungen das Problem auslöst, muss aber nicht.

1 hour ago, R_Gerald said:

Laut Health Monitor gibt es aber schon noch viele Checksum und Frame Erros.

Bleiben die Fehlerzähler gleich, oder steigen die kontinuierlich? Im Health Monitor kannst du die Werte auch in einer Datei speichern. Mach das bitte mal und häng die Datei hier an.

1 hour ago, R_Gerald said:

Die Sensordaten der Child devices werden aber nicht übertragen es kommen diese Fehlermeldung am Raspberry PI

Wir pflegen den Tinkerforge Support in Cumulocity nicht, sondern das macht Cumulocity selbst. Cumulocity scheint einfach alle deine Bricks und Bricklets nicht zu unterstützen:

• Device Identifier 111 ist der HAT Brick
• Device Identifier 290 ist das Sound Pressure Level Bricklet
• Device Identifier 292 ist das Motion Detector Bricklet 2.0
• Device Identifier 297 ist das Air Quality Bricklet

Das hat also nichts mit dem HAT Brick Problem zu tun, sondern einfach damit, dass der Cumulocity Support für Tinkerforge unvollständig ist. Das ist hier auch nachzulesen:

• https://cumulocity.com/tinkerforge/ (in der Fussnote)
• https://cumulocity.com/guides/device-tutorials/tinkerforge/

[R_Gerald]

So nun hab ich das ganze nochmals mit einem neuen Raspberry Pi 4B versucht. Obwohl nach dem Update der Kernel wieder bei 5.10.60 war hat der Brick Daemon mit Brick Viewer und Standard settings ohne Probleme funktioniert.

 

Danach hab ich wieder den Cumulocity agent installiert anfänglich haben sich beide Komponenten gut vertragen aber nach öfteren Start Stop vom Brick Daemon und Cumulocity agent, war der Raspberry mit HAT Brick nicht mehr ansprechbar, erst nach deinstallation des Brick Deamon konnte ich den Raspberry mit gestecktem HAT Brick wieder starten.

Ist es auch möglich über Modbus TCP die Bricklets auszulesen?

 

 

 

[photron]

Also ist das eine Wechselwirkung zwischen Cumulocity Agent und Brick Daemon? Wenn du also den Cumulocity Agent deinstallierst anstelle von Brick Daemon dann läuft es auch it HAT Brick?

1 hour ago, R_Gerald said:

Ist es auch möglich über Modbus TCP die Bricklets auszulesen?

Nein, dazu kannst du aber irgendeine Modbus TCP Bibliothek verwenden z.B. PyModbus. Für Modbus TCP brauchst du keine extra Hardware, da das einfach über die normale Netzwerkschnittstelle geht.