Jump to content

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


Recommended Posts

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?

 

 

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

image.thumb.png.ff7b48ced6de406426b311d922456d5d.png

Meine Ausprägung

image.png.fe1c1cb92e3184152f69762d2c545e45.png

 

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

 

Link to comment
Share on other sites

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:

Link to comment
Share on other sites

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?

 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...