I am getting "Cannot get the control attributes /dev/ttyAMA0 " in the MMDVM log followed by "MMDVMHost-20240126_PS4 exited on receipt of an unknown signal"
I assume this means I have bricked the modem, is there a way to recover it?
Thanks for the help,
Jeffrey
Cannot get the control attributes
Re: Cannot get the control attributes
I don't know how to fix it - but I had the same thing happen to my DStar and DMR hotspots.
I had upgraded both of them to 4.2.0. To create the problem go to the configuration screen
and make an edit. Just about anything does it. On my DStar hotspot I changed english_uk to english_us.
On my DMR hotspot I had enabled DumpTAData. The end result was an error as you describe.
What's going on under the hood is /dev/ttyAMA0 becomes a link to /dev/pts/0.
I don't know how to undo that.
Bob, NS2B
I had upgraded both of them to 4.2.0. To create the problem go to the configuration screen
and make an edit. Just about anything does it. On my DStar hotspot I changed english_uk to english_us.
On my DMR hotspot I had enabled DumpTAData. The end result was an error as you describe.
What's going on under the hood is /dev/ttyAMA0 becomes a link to /dev/pts/0.
I don't know how to undo that.
Bob, NS2B
Re: Cannot get the control attributes
Thanks Bob, based on that I tried a fresh load and sure enough it lives... You are correct, /dev/ttyAMA0 becomes a link to /dev/pts/0. In my case it happened when I switched from simplex to full duplex. I was running 4.3.0.
Thanks again!
Jeffrey
Thanks again!
Jeffrey
Re: Cannot get the control attributes
It is fixed by doing:
sudo rm /dev/ttyAMA0
sudo mknod /dev/ttyAMA0 c 204 64
sudo chown root:dialout /dev/ttyAMA0
sudo chmod 660 /dev/ttyAMA0
this recreates the device file and sets ownership and permissions.
Hope this help someone else
Jeffrey
sudo rm /dev/ttyAMA0
sudo mknod /dev/ttyAMA0 c 204 64
sudo chown root:dialout /dev/ttyAMA0
sudo chmod 660 /dev/ttyAMA0
this recreates the device file and sets ownership and permissions.
Hope this help someone else
Jeffrey
Re: Cannot get the control attributes
I added some extra checks around NextionDriver (I think that is actually the cause in this case)
So it should not happen any more after an update.
So it should not happen any more after an update.
Re: Cannot get the control attributes
With 4.3.0 I have the problem every single time I reboot!
I've set up a cron job to deal with it.
@reboot sleep 35 && rpi-rw
@reboot sleep 40 && sudo rm /dev/ttyAMA0
@reboot sleep 45 && sudo mknod /dev/ttyAMA0 c 204 64
@reboot sleep 50 && sudo chown root:dialout /dev/ttyAMA0
@reboot sleep 55 && sudo chmod 660 /dev/ttyAMA0
@reboot sleep 60 && sudo pistar-update
I've thrown in the update command at the end to reload the pistar services and bring things back up!
J
I've set up a cron job to deal with it.
@reboot sleep 35 && rpi-rw
@reboot sleep 40 && sudo rm /dev/ttyAMA0
@reboot sleep 45 && sudo mknod /dev/ttyAMA0 c 204 64
@reboot sleep 50 && sudo chown root:dialout /dev/ttyAMA0
@reboot sleep 55 && sudo chmod 660 /dev/ttyAMA0
@reboot sleep 60 && sudo pistar-update
I've thrown in the update command at the end to reload the pistar services and bring things back up!
J
Re: Cannot get the control attributes
Seems all be related to bluetooth taking the device.
In /boot/config.txt search for dtoverlay and disable the bluetooth.
This will fix it and no need scheduled scripts with reboots.
In /boot/config.txt search for dtoverlay and disable the bluetooth.
Code: Select all
# Dissable Pi3 Bluetooth (so that UART works)
dtoverlay=disable-bt
Re: Cannot get the control attributes
Posted this in the 4.3.0 Beta Feedback Thread
SOLVED - I found an issue with the 4.3.0 default image. It's resulted in a few hours of trouble-shooting to get the image working with a single band DV-Mega daughter board on Pi 3's & 4's. Others here on the forum have had the same issues with other modems and configurations. This has been discussed here in the "4.3.0 Beta Feedback" thread and in the "Cannot get the control attributes" thread. Some have developed very creative work arounds. I found the solution today and solved my problem by making one simple change.
PROBLEM - After installing a new image and inserting all your data in the sections of the configuration page the hotspot will function normally. You can reboot the image etc... The problems come into play when you make a change to an entry on the Configuration Page and apply the change. All the services restart as they should but /dev/ttyAMA0 gets reassigned. Now your DV Mega etc...won't run because the port has been assigned to another system user.
FACTS - On the Configuration Page in the MMDVMHost Section - "MMDVM Display Type" field = "None". "Port" is prepopulated = /dev/ttyAMA0
SOLUTION: Change the MMDVM Display Type Port = "None". Apply the Changes.
With that one simple change my DV-Mega returned to life. Prior to that I'd disabled bluetooth, purged bluetooth, reassigned ownership of the port by cli, etc...uggg, but an interesting learning experience.
My thanks to Andy and the PiStar Team for providing and maintaining this resource for us to use.
Tom - W1TG
SOLVED - I found an issue with the 4.3.0 default image. It's resulted in a few hours of trouble-shooting to get the image working with a single band DV-Mega daughter board on Pi 3's & 4's. Others here on the forum have had the same issues with other modems and configurations. This has been discussed here in the "4.3.0 Beta Feedback" thread and in the "Cannot get the control attributes" thread. Some have developed very creative work arounds. I found the solution today and solved my problem by making one simple change.
PROBLEM - After installing a new image and inserting all your data in the sections of the configuration page the hotspot will function normally. You can reboot the image etc... The problems come into play when you make a change to an entry on the Configuration Page and apply the change. All the services restart as they should but /dev/ttyAMA0 gets reassigned. Now your DV Mega etc...won't run because the port has been assigned to another system user.
FACTS - On the Configuration Page in the MMDVMHost Section - "MMDVM Display Type" field = "None". "Port" is prepopulated = /dev/ttyAMA0
SOLUTION: Change the MMDVM Display Type Port = "None". Apply the Changes.
With that one simple change my DV-Mega returned to life. Prior to that I'd disabled bluetooth, purged bluetooth, reassigned ownership of the port by cli, etc...uggg, but an interesting learning experience.
My thanks to Andy and the PiStar Team for providing and maintaining this resource for us to use.
Tom - W1TG