Hi Community,

This week I got my new HAT zero for Raspberry Pi.
Same setup is working since ca 3 years in another room.

Now I do not get it running a second time because of excessive CPU consumption by brickd process (roughly 100 per cent).
I must have missed something too obvious. I'd be happy for some advice where to look next.

Thanks a lot, cheers
Michael

 

Hundreds of these messages found in /var/log/brickd.log for ports B, C and D:

2022-09-03 09:38:34.584241 <E> <bricklet_stack.c:478> Message checksum error (port: D, count: 177)
2022-09-03 09:38:34.585903 <E> <bricklet_stack.c:396> Frame error (port: B, count: 675)
2022-09-03 09:38:34.586180 <E> <bricklet_stack.c:396> Frame error (port: C, count: 678)
2022-09-03 09:38:34.597130 <E> <bricklet_stack.c:396> Frame error (port: D, count: 45)

port A connected with an Industrial Digital In 4 Bricklet 2.0 works flawless, no messages related to port A in brickd.log.

 

brickd --version shows 2.4.3

Connection by Brick Viewer (level 2.4.22) from Windows works fine.
Everything as expected (some slow, but I guess this is because lack of CPU in raspberry).
According to "Search for Updates" function, firmware levels are current (HAT=2.0.1 ; bricklet=2.0.2).

 

similar observation found in topic 
https://www.tinkerunity.org/topic/5985-brickd-liefert-fehlermeldungen-am-laufenden-band/?do=findComment&comment=32509
However, I am not really convinced it is same problem for me. 
I have brand new HAT and brick, no soldering myself.
 

So you have an old setup that is working and an identical new setup that is not working right.

You could try swapping the SD cards between the Raspberry Pis. If the problem moves with the SD card then its a software problem.

If the problem doesn't move with the SD card, then it has to be a difference in hardware.

You could try swapping the HAT Zero Bricks between the Raspberry Pis. If the problem moves with the HAT Zero Brick then its a problem with the HAT Zero Brick.

Thank you for your answer.
The cause for the irritation still is unknown to me.
No recent updates, no change in configuration. I simply postponed further investigation for some days and let the raspberry run as usual.
Lately there had been a nightly backup process (rsync command scheduled by cron) followed by a weekly re-start (shutdown -r now command scheduled by cron).
Since then, the HAT was alright.

I am sure that I switched off the raspberry pi and removed power supply during installation of the HAT and cabling of the bricklet.
Also, I am sure that I did a couple of re-starts (reboot command) over the days.

The setup of HAT together with bricklet seems working as intended now.
But it is somewhat unsatisfying because a cure out of the sudden by itself is not what I was expecting.
Maybe there is a subtle difference between commands shutdown -r now and reboot.
One more difference: The commands scheduled by cron are run by plain shell /bin/sh (symlink link to /bin/dash). For manual re-start I was using default /bin/bash .
Who knows, this is kind of forensic...

For now, I leave it as it is. It's just hobby, no production.
Once more thank you for your support.
Cheers
Michael

Hi,

 

try to add

bricklet.portA.sleep_between_reads = 5000
bricklet.portB.sleep_between_reads = 5000
bricklet.portC.sleep_between_reads = 5000
bricklet.portD.sleep_between_reads = 5000
bricklet.portE.sleep_between_reads = 5000
bricklet.portF.sleep_between_reads = 5000
bricklet.portG.sleep_between_reads = 5000
bricklet.portH.sleep_between_reads = 5000
bricklet.portHAT.sleep_between_reads = 5000

 

to /etc/brickd.conf. Should bring down the CPU laod.

 

Best regards

Martin

Thank you for this update.
I can confirm, the CPU load dropped significantly.

I found this post which might explain a little more background to this astonishing behavior:
https://www.tinkerunity.org/topic/4832-raspberry-zero-w-hohe-cpu-auslatung-durch-brickd-service-mit-hat-zero-brick/?do=findComment&comment=27584

CPU load for brickd daemon now is barely notable.

Thank you, cheers
Michael