Touch Drive Raspberry PI 4 stop working after some time - touch

Hello I am using a Raspbarry 4 8Gb system
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
$ lsusb
Bus 001 Device 004: ID 1ff7:0013 CVT Electronics.Co.,Ltd CVT Touch Screen (HID)
For some reason after a few hours the touch with infrared frame stops working. If you restart the machine it will work again.
I'm even using a program to reset the USB made in C
usbreset.c that works perfectly I left it in crontab every 10 min.
I noticed that this problem only started in the new version 11 of Raspbian, in version 10 I never had this problem.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Has anyone experienced this, know how to fix it?

Related

esm_cache.py crash with no network connectivity after

I've recently updated Ubuntu to 22.04, and it seemed to work perfectly fine for about 2 weeks. Yesterday while launching Rstudio I got a message about an internal error with title "esm_cache.py crashed with apt.cache.FetchFailedException" relating to package ubuntu-advantage-tools 27.13.2-22.04.1.
Afterwards I completely lost network connection and can't restore it in any way. This is a dual boot system, and the same ethernet cable still works on Windows 11.
I am very new to Ubuntu and am not able to think of any solution short of re-installing the system from scratch. After a search for similar issues, I tried to do some diagnostics:
sudo lshw -C network
*-network UNCLAIMED
description: Ethernet controller
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci#0000:04:00.0
version: 15
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list
configuration: latency=0
resources: ioport:f000(size=256) memory:fc604000-fc604fff memory:fc600000-fc603fff
nmcli device
DEVICE TYPE STATE CONNECTION
lo loopback unmanaged --
Any help would be very appreciated!

Debugging USB serial disconnection on raspberry pi

On one of my raspberry pis (Raspbian OS) with a USB serial device connected, there is periodic disconnection of the serial device while still being registered as a USB device.
lsusb returns a valid Bus Device entry, but there is no corresponding /dev/serial/ entry.
The only way to fix this issue is rebooting the pi, which I'd like to avoid.
I'd love some ideas on how I can debug USB serial connections on a Raspberry Pi Linux platform, or methods to reset the serial connection without requiring a reboot.
We tried:
Tracking udevadm monitor to see USB related events. This is what is seen where we catch a serial disconnection / reconnection happening:
KERNEL[65879.184887] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM1 (tty)
KERNEL[65879.185179] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
KERNEL[65879.185389] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
KERNEL[65879.185728] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
KERNEL[65879.186275] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
UDEV [65879.193792] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
UDEV [65879.197016] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM1 (tty)
UDEV [65879.197414] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65879.203665] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
UDEV [65879.205795] remove /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
==> /var/log/messages <==
Jan 20 18:36:42 rpi4161a-172-101 kernel: [65879.307684] usb 1-1.3: USB disconnect, device number 12
==> /var/log/syslog <==
Jan 20 18:36:42 rpi4161a-172-101 kernel: [65879.307684] usb 1-1.3: USB disconnect, device number 12
KERNEL[65880.121912] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
KERNEL[65880.122424] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
KERNEL[65880.125157] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0 (tty)
KERNEL[65880.125702] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
KERNEL[65880.126324] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65880.158159] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 (usb)
UDEV [65880.167588] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0 (usb)
UDEV [65880.168004] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1 (usb)
UDEV [65880.169128] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.2 (usb)
UDEV [65880.177534] add /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0 (tty)
==> /var/log/messages <==
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.244987] usb 1-1.3: New USB device found, idVendor=****, idProduct=****, bcdDevice= 1.00
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245001] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245010] usb 1-1.3: Product: J-Link Pro OB
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245020] usb 1-1.3: Manufacturer: ****
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.245028] usb 1-1.3: SerialNumber: ****
Jan 20 18:36:43 rpi4161a-172-101 kernel: [65880.248227] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Jan 20 18:36:43 rpi4161a-172-101 mtp-probe: checking bus 1, device 13: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Jan 20 18:36:43 rpi4161a-172-101 mtp-probe: bus: 1, device: 13 was not an MTP device
Checking if the raspberry pi was overheating, using vcgencmd. It returns 8000 Soft temperature limit has occurred flag sometimes, but not always.
Tried the following method to "reset" the serial connection, which had no effect
echo -n '1-1.3:1.0' | sudo tee -a unbind
echo -n '1-1.3:1.0' | sudo tee -a bind
Followed some of the solutions here: https://raspberrypi.stackexchange.com/questions/9264/how-do-i-reset-a-usb-device-using-a-script, including the solution to reset the USB bus, with no luck.
USB Serial malfunctioning may be caused by many different factors, including software, hardware or noisy environment.
The following diagram roughly describes the related components,
-------------------- ----------------
| Userspace (Apps) | | Power Supply |
-------------------- ----------------
^
|
-------------------- ------------- ----------
| Kernel (Drivers) | <-- | USB Cable | <-- | Device |
-------------------- ------------- ----------
Narrow down to the faulty part
As first step, elimination method can help us to narrow down to the faulty part, basically you replace the suspect part with another good component, and observe if it changes result. for example,
use the latest official raspbian image to eliminate userspace issue
choose a different kernel/firmware image to eliminate kernel/driver issue
change usb cable
change usb device
use a decent power supply
Troubleshooting on software issue
Assume we could narrow down the scope to software, I would use the following procedures to do further check,
Make sure the usb device is recognized by kernel, check with lsusb, dmsg, udevadm.
Have a correct name (dev path), check udev rules;
Run udevadm monitor to observe any unexpected disconnection events, make sure it works (stable connection) on a fresh OS image, and install only necessary packages step by step.
Other tips
Check if your usb device is a "smart" device? meaning the device may have its own logic to disconnect or change mode, so that affect your host side connection.
To see what happened on the USB bus it is better to use usbmon (see https://wiki.wireshark.org/CaptureSetup/USB).
I think you should carefully check usb descriptors: lsusb -v and check how much current it attempts to take (check configuration descriptor: https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-configuration-descriptors).
I think reconnects could occur due to insufficient current to you usb device especially if device supplied only from bus. If current > than usb host controller can provide, usb host-controller limits current this could lead to device reset. To check this hypothesis connect your device to Raspberry using active hub with external power supply.

Flutter on Chromebook

I tried to get flutter running on my Lenovo Duet Chromebook. Unfortunately, I got
$ flutter doctor -v
~/apps/flutter/bin/internal/shared.sh: line 228: ~/apps/flutter/bin/cache/dart-sdk/bin/dart: cannot execute binary file: Exec format error
$ uname -a
Linux penguin 5.4.119-14945-gafc97d54f809 #1 SMP PREEMPT Tue Aug 10 21:44:33 PDT 2021 aarch64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
How is it possible to flutter running?
Thank you in advance,

Build AOSP on MacOS M1

I wanted to get my feet wet with AOSP on my MacOS M1 (ARM64) with Big Sur, but it looks like there is no configuration build for this host.
When I look under build/soong/cc/config I only see one Darwin related file, namely x86_darwin_host.go.
With the latest aosp release, namely android-11.0.0_r35 I'm able to build a generic arm64 target, but the resulting emulator does not boot. Configuration shows that the HOST is detected as x86_64, in fact binaries generated are in x86_64 format.
total 0
drwxr-xr-x 3 salvatorebenedetto staff 102 Apr 10 15:21 common
drwxr-xr-x 9 salvatorebenedetto staff 374 Apr 10 15:21 darwin-x86
➜ aosp file out/host/darwin-x86/lib64/libc++.dylib
out/host/darwin-x86/lib64/libc++.dylib: Mach-O 64-bit dynamically linked shared library x86_64
➜ aosp
This is what I get when booting the emulator from the kernel
RAMDISK: lz4 image found at block 0
RAMDISK: lz4 decompressor not configured!
Invalid ramdisk decompression routine. Select appropriate config option.
Kernel panic - not syncing: Could not decompress initial ramdisk image.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.94+ #1
Hardware name: ranchu (DT)
Call trace:
[<ffffffc00008a590>] dump_backtrace+0x0/0x128
[<ffffffc00008a6cc>] show_stack+0x14/0x1c
[<ffffffc0005ca064>] dump_stack+0x80/0xa4
[<ffffffc0005c95a0>] panic+0xe8/0x228
[<ffffffc00074ba34>] rd_load_image+0x2fc/0x5e0
[<ffffffc00074be30>] initrd_load+0x50/0x2cc
[<ffffffc00074b47c>] prepare_namespace+0xd8/0x1ac
[<ffffffc00074ad04>] kernel_init_freeable+0x1bc/0x1dc
[<ffffffc0005c8150>] kernel_init+0x10/0xf4
Rebooting in 5 seconds..Reboot failed -- System halted
Any idea how I can debug what is wrong with the initrd image?
I think this should help, it has a peace specific for setup the missing sdk 10.15.
Good luck, let us know if it works to you!

I'm trying to set up apcupsd on a raspberry pi to communicate with a tripp-lite power supply

I am trying to get this to work. I have:
Raspberry Pi B (I think) running Raspbian 10 (buster)
Tripp Lite OMNI1500LCDT
Connection via USB
I have the following configuration files:
/etc/apcupsd/hosts.conf:
MONITOR 127.0.0.1 "Local Host"
/etc/default/apcupsd
ISCONFIGURED=yes
/etc/apcupsd/apcupsd.conf:
UPSNAME triplite
UPSCABLE usb
UPSTYPE usb
DEVICE
When I run sudo apctest (note that I stopped the daemon first) I get:
apctest
2020-04-04 00:28:18 apctest 3.14.14 (31 May 2016) debian
Checking configuration ...
sharenet.type = Network & ShareUPS Disabled
cable.type = USB Cable
mode.type = USB UPS Driver
Setting up the port ...
apctest FATAL ERROR in apctest.c at line 321
Unable to open UPS device.
If apcupsd or apctest is already running,
please stop it and run this program again.
apctest error termination completed
when I run sudo /etc/init.d/apcupsd start, the log looks OK:
Apr 4 00:29:57 megabyte systemd[1]: Starting UPS power management daemon...
Apr 4 00:29:57 megabyte systemd[1]: apcupsd.service: Can't open PID file /run/apcupsd.pid (yet?) after start: No such file or directory
Apr 4 00:29:57 megabyte apcupsd[6712]: apcupsd 3.14.14 (31 May 2016) debian startup succeeded
Apr 4 00:29:57 megabyte apcupsd[6712]: NIS server startup succeeded
Apr 4 00:29:57 megabyte systemd[1]: Started UPS power management daemon.
When I run lsusb I get (note that the Tripp Lite UPS is listed on Device 4:
lsusb
Bus 001 Device 005: ID 0781:5575 SanDisk Corp. Cruzer Glide
Bus 001 Device 004: ID 09ae:3016 Tripp Lite
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I wound up installing nut by following these directions and now nut is working fine.