When I reboot my Raspberry Pi (running NOOBS and its a rpi 3) in the root/command line thing, it prints something like this:
[ (numbers) ] Watchdog: watchdog did not stop!
Is this something to worry about?
This is normal behavior. If the Raspberry Pi reboots sucessfully, there is nothing to worry about.
See https://unix.stackexchange.com/q/249654
The watchdog did not stop! line is normal behavior. systemd sets a "hardware watchdog" timer as a failsafe, to ensure that if the normal shutdown process freezes/fails that the computer will still shutdown after the specified period of time.
Related
I'm running into a very strange issue attempting to run CodeSys on a 4GB RasPi-4. Long story short, the Pi works fine right up until I start running the CodeSys project. When I do, within 60sec, eth0 goes down and cannot be brought back up. Even rebooting the Pi has no effect. The only way I've found to recover eth0 is to re-burn RasPiOS from the source image from Raspberrypi.org (which I've done about 30 times over the past few days, trying to trial-and-error my way out of this).
Linux raspberrypi 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
I have eth0 set to a static IP using /etc/dhcpcd.conf. Whatever is causing this issue is not altering my settings there. Attempts to use ifconfig eth0 up/down have no effect -- no errors, no feedback, just nothing. Checking eth0's state shows "waiting for carrier," despite being connected to an active switch (I've also swapped out all the cables and the switch to eliminate them as the source of the problem).
When I re-burn the Pi and install CodeSys, eth0 stays up indefinitely (24hrs+ in my longest test). It's starting the CodeSys project that kills eth0. A reboot after etho "dies" gives a series of bcmgenet messages that appear to be related:
pi#raspberrypi:~ $ dmesg | grep bcmg
[ 1.033665] bcmgenet fd580000.ethernet: failed to get enet clock
[ 1.033685] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[ 1.033709] bcmgenet fd580000.ethernet: failed to get enet-wol clock
[ 1.033730] bcmgenet fd580000.ethernet: failed to get enet-eee clock
[ 1.044648] libphy: bcmgenet MII bus: probed
[ 9.528502] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[ 9.535175] bcmgenet fd580000.ethernet eth0: Link is Down
I also tried creating a new CodeSys project from scratch that had no eth0 drivers (ModBus, Ethernet/IP) installed, only the GPIO driver. That didn't help either -- eth0 dies within 60sec.
The strangest part is, only eth0 seems to be affected. The GPIO pins keep cycling as controlled by the CodeSys project (I have a simple LED-blinking program running), and I can still SSH into the Pi using wifi. But since my main reason for setting this Pi up is to use Ethernet/IP and ModBus....
This thread: at GitHub is the only place I've found anyone describing anything similar to what I'm experiencing, but in that case CodeSys is not installed. I did try adding genet.skip_umac_reset=n to my cmdline.txt as suggested in the thread, but it had no effect.
So, it turned out this was an issue configuring the GPIO pins.
CodeSys has two difference "device" files for adding the GPIO pins to the project device tree. The default selection is for older Pi models, and the alternate choice (labelled only for B+ and Pi2) is the correct one for the Pi4.
As it turns out, the outdated GPIO device file will work on a Pi4, mostly. But using the wrong device file allows CodeSys to try configuring GPIO pins that shouldn't be tampered with. In this case, GPIO 28 and 29. Setting either of them to Output mode killed eth0.
Using the correct device file removes 28&29 from the list of configurable GPIO pins. It also gives the correct list of available GPIO pins for the newer Pi models, hopefully avoiding other potential config issues that I didn't trip over.
In CodeSys, right-clicking on the GPIOs element in the device tree offers the option to "Update the Device." Select this option to get the list of available device files, and select the correct one before using the "Update Device" button in the bottom of the window.
Hi I made some programs that are to be run in a raspberry pi.
The programs are mainly about controlling GPIO pins and analyzing USB camera Videos.
But do I have to manually run those programs all the time?
Is there any way to make the program run after starting os automatically?
Just like an arduino... it remembers what has been uploaded in its memory
Edit your crontab with crontab -e and add:
#reboot yourscript
Be careful about the environment variables PATH because cron could be lauched before some of your services (distibutions start up dependant).
I have a raspberry pi with raspbian and a 32gb SD card. I need it to run a bash script 24/7, but the script runs for 20-30 minutes and then it stops. And when I reboot the raspberry, it won't load the desktop and this https://i.stack.imgur.com/b165r.jpg shows up. It seems that this is because there isn't enough memory. I guessed it's because of the cache (the script has to open a window in chromium). How can I delete it? Is there a way to do it every time at the end of the script? What else could it be? Thanks.
This is what happens when I do apt-get purge anything to free up some space
https://i.stack.imgur.com/5F0FM.jpg
And this is what happens when I write df -h... It says that the system is full but how the heck is that possible???
https://i.stack.imgur.com/L8uvM.jpg
I am currently developing a small OS on my Raspberry Pi, that I install by replacing the kernel.img file on the /boot partition of my SD card. By the time my code is run, the CPU is already in Normal Mode, so I can't have access to the Secure world / Trustzone area.
Is it possible to modify the boot process of the Raspberry to be able to start executing my code in Secure mode ?
Best,
V.
In fact you don't have to do anything but stop being stupid like me.
As explained here:
https://raspberrypi.stackexchange.com/questions/14953/is-it-possible-to-boot-the-raspberry-pi-in-secure-mode
When the NS bit of the SCR register is 0, it means that you are in Secure Mode, which is the case at boot on my Raspberry. I had the meaning of this bit backwards, sorry !
I'm working with an embedded computer that has a Debian on it. I already manage to run a command just before it has booted and play the "bell" to tell that is ready to work, and for example try to connect to a service.
The problem is that I need to play the bell (or run any command/program) when the system is halted so is safe to un-plug the power. Is there any runscript that run just after halt?
If you have a look in /etc/init.d, you'll see a script called halt. I'm pretty certain that when /sbin/halt is called in a runlevel other than 0 or 6, it calls /sbin/shutdown, which runs this script (unless called with an -n flag). So maybe you could add your own hook into that script? Obviously, it would be before the final halt was called, but nothing runs after that, so maybe that's ok.
Another option would be to use the fact that all running processes get sent a SIGTERM followed (a second or so later) by a SIGKILL. So you could write a simple daemon that just sat there until given a SIGTERM, at which point it went "ping" and died.