I have a raspberry pi 3.
Whenever I want to shutdown, I always execute this command:
sudo shutdown -h now
And I will wait until only the red light is lighting. (And I always remove the power until only the red light is lighting)
But the problem is : every time I shutdown, I can't boot it again. I need to install the OS into the SD card again every time after I shutdown.
If anyone has the same problem ? Please help me. Thanks a lot.
I encountered this after my comment. As I mentioned, I perform the same steps to safely shutdown, unplug, and store.
Based on this page, you might be getting a corrupt SD card. Not sure if any of these apply.
https://www.raspberrypi.org/documentation/installation/sd-cards.md
If you are having trouble with corruption of your SD cards, make sure you follow these steps:
Make sure you are using a genuine SD card. There are many cheap SD cards available which are actually smaller than advertised or which will not last very long.
Make sure you are using a good quality power supply. You can check your power supply by measuring the voltage between TP1 and TP2 on the Raspberry Pi; if this drops below 4.75V when doing complex tasks then it is most likely unsuitable.
Make sure you are using a good quality USB cable for the power supply. When using a high quality power supply, the TP1->TP2 voltage can drop below 4.75V. This is generally due to the resistance of the wires in the USB power cable; to save money, USB cables have as little copper in them as possible, and as much as 1V (or 1W) can be lost over the length of the cable.
Make sure you are shutting your Raspberry Pi down properly before powering it off. Type sudo halt and wait for the Pi to signal it is ready to be powered off by flashing the activity LED.
Finally, corruption has been observed if you are overclocking the Pi. This problem has been fixed previously, although the workaround used may mean that it can still happen. If after checking the steps above you are still having problems with corruption, please let us know.
Hope that helps.
Cheers.
Ian
Related
Good day
The problem:
I am trying to connect/flash/debug a Olimax STM32-E407 dev board over SWD and I am not able
When trying to connect, using CubeProgrammer, I get: "No STM32 Target Found"
What I have tried:
I have connected a ST-link V3 mini to the pinout of the the 20pin header of the Olimax board including 3.3V, GND, SWDIO (PA13/Pin7), SWCLK (PA14/Pin9) and NRST (Pin15).
I am powering the powering the board from a power supply into the power jack
All jumpers and solder bridges are in stock places.
I have also tried manually pulling NRST to ground and doing a full chip erase, but that has not worked either.
I have used these ST-link debuggers on other boards I made and it works perfectly fine
I have 3 Olimax boards and none of them work
Any help would he hugely appreciated.
Debugging problems on microcontrollers have two general common methodes.
Hardware Problems:
In this part, it is highly recommended that use an oscilloscope to monitor circuit.
Make sure the microcontroller is powered with a correct and stable power supply.
Check the soldering quality and there is no short circuit on the board (especially between ground pins and other pins).
Check the NRST pin is high when the board is powered.
Remember that this reset is active low so during programming or debugging this pin should be high. Also, check this pin is debounced with a capacitor.
Also you can check the JTAG pins signals with an Oscilloscope to check if the programmer device is working fine.
Sometimes adding a capacitor between debugging pins and GND increases the bus capacitance and solves the problem. The value of the capacitor should be found by trying.
Software Problems
Check the programmer driver is correctly installed on your PC.
Check the programming method is true(for example maybe the board is designed to be programmed with SWD, not JATG).
Sometimes reducing the programming clock of the programmer solved the problem.
If all of these methods didn't work and you are sure that the board is fine, probably the programmer is broken, so change the programmer with another one.
I am trying to build a small system which include a rPi and rPi Zero. rPi act as local wifi hotspot and rPi zero connect to rPi hotspot.Then I access zero camera through rPi. My diagram looks like this.
It works totally fine if I have a LAN connection. Once I remove the lan connection motionEyeOs won't stream any data. And even it disconnect from wifi and go to boot loop.
So my question, is there any way we can make motionEyeOs works with out actual internet ?.
The answer to your question: You can set link_watch="false" in /data/etc/watch.conf
But this come with a few other problems:
If your camera boots without network connection (internet), it has no time set (your videos and images could get overwritten)
If your camera boots without or looses network connection (internet), the camera does not try to reconnect and you have no other chance and have to connect a keyboard an monitor to it
A hardware clock would help for the first problem but I am still searching for a solution for the second. If you already have one, I would appreciate it, if you could help me out.
https://www.raspberrypi.org/documentation/usage/camera/raspicam/raspivid.md
This is what I use for an offline video recorder and it only needs the software and a power source..Camera also but you get the idea. Keep your image (os) small as possible as this can fill an sd card fast. If I remember right, I used 800 x 600 and it would use a gig an hour.
I'm trying to get to work a raspberry pi 0 W and a pervasive display eink screen together.
But, every time when the screen refresh, it reboots the pi 0. Software works great on a RPi3 but not on Rpi0w with Raspbian Lite.
Here is the soft : EpaperDisplay
Here is the screen : Screen
There is no log in /var/log/messages, neither in /var/log/syslog. Every time it reboots, it's erasing history, logs ...
If this was a software issue, you would probably see something in the logs (or you'd at least see a kernel panic message on the console in the HDMI output if you have a screen connected there).
If you have nothing in the HDMI screen when the pi crashes, I'd suspect that the display is using more power than your power supply can provide. Try with a PSU with a higher ampere rating.
If a better power supply does not help, it can be that the display sucks too much 3.3v from the raspberry pi than the zero can provide. In that case you should try feeding the display via a separate 3.3v regulator.
First I want to point out that I'm very new to Raspberry Pis. I have bought a Raspberry Pi Zero for my project, because Arduino did not have enough horsepower.
My Project involves an I2C sensor and audio output (I2S). The audio is generated on the Raspberry and that is why I need the computational power.
Now I'd like to know what would be a good choice for the operating system. I don't really need anything else but the I2C and I2S and some math to generate the sound. The project is going to have the Raspberry embedded in the system and is battery powered, so it should be able to survive sudden power loss.
I found something relating to Real Time Operating systems, but I'm not sure if I need it to be exactly real time since I can buffer the generated sound data. But I do need the system to be fast, and as light as possible as the sound generation is rather heavy process.
I understand this is sort of vague question and I'm happy with any information I can get and if you could just point me in the right direction, that would be appreciated.
How to reset PC(motherboard) from FPGA on PCI board (without BIOS manipulations)
Subj.
You are probably not going to find a scheme that works with all motherboards, if you even find any. Intel and AMD do this differently too. If you're lucky to find a motherboard where the PCI reset signals are open drain you might be able to drive it and cause some bad stuff to happen and cause a reset. If the motherboard drives those signals then you are out of luck (you could damage the driver).
You could also try to crash the system that would cause a reset, although that's getting harder nowadays with PCIe. Operating systems seem to be able to survive bad PCI devices due to better error handling and timeouts, etc.
Is this to implement some sort of watchdog? Probably easier to do this using IPMI and some sort of heart beat.