R-Pi Troubleshooting

Back to the Hub.

This page lists the most common problems and suggests some solutions.

See RPi_Bugs for problems that are bugs.

Power / Start-up
A good power supply that will supply 5V is vital. There is more information about See.

Red power LED does not light, nothing on display
The power is not properly connected.

Red power LED is blinking
The red power LED should never blink, because it is hard-wired to the 3.3V power supply rail. If it is blinking, as one user has reported it means the 5V power supply is dropping out. Use a different power supply.

Red power LED is on, green LED does not flash, nothing on display

 * The Raspberry Pi cannot find a valid image on the SD card. Check card is inserted correctly. Check that you have correctly written a Raspberry Pi image to the card. Insert the SD card into a Windows machine and you should see bootcode.bin, loader.bin and start.elf amongst others. See also, Known SD Cards.
 * Try with no cables connected except the USB power lead, and SD card inserted. You should see flashing of the OK light for ~20 seconds. If that helps, plug in cables one at a time to identify which is interfering with boot.
 * The voltage is too low (below 5 V), try a different power supply and/or cable. The R-Pi needs a supply rated for 700 mA or more. Some supplies labeled as such cannot actually provide their rated current while maintaining 5V. See also,.
 * There is a bug in the distributed version of bootcode.bin which causes problems with some sdcards. Try this version: https://github.com/raspberrypi/firmware/blob/234c19de7cbaaf4997671d61df20a05759066295/boot/bootcode.bin. Please let us know if it "fixes" your non-working SD card (or, more importantly, if it doesn't). This can also manifest itself as intermittent booting, or only booting when cold.
 * (unlikely) hardware abuse, for example by connecting a 7 V supply to a 3v3 GPIO output pin or powering up the board after a solder splash shorts some traces.
 * Look at the SD card holder on the Raspberry Pi carefully. At first glance it may look fine but the contacts must be springy and they must protrude at least 2mm as measured from the lower edge of the holder to the top of the contact bulge. This happens due to the solder process and the type of holder used. Some of the solder residue falls into the contact cavity restricting the springiness and the height that the contact protrudes. You can fix this yourself but remember you can void your warranty. The contacts are delicate so be carefull. Insert a needle pin under the contact bulge and pull lightly up until the one end of the contact unclips. Clean the cavity where the contact unclipped from of any solder or other residue by blowing into the cavity. Clip the contact back into the cavity by lightly pushing it into the cavity. Do this for all the contacts. Look at these photos.  [[Media:SDcardHolder.JPG]], [[Media:UnclipContact.JPG]], [[Media:UnclippedContact.JPG]]

Green LED blinks in a specific pattern
With recent firmware, according to this forum post the green light will blink in a specific pattern to indicate some types of errors:


 * 3 flashes: loader.bin not found
 * 4 flashes: loader.bin not launched
 * 5 flashes: start.elf not found
 * 6 flashes: start.elf not launched

Coloured splash screen


With recent firmware, a coloured splash screen is displayed after firmware (start.elf) is loaded. This should be replaced by linux console a second later. However if the coloured screen remains, it suggests the kernel.img file is failing to boot. Try replacing it with a known good one.

Kernel Panic on boot
Text appears on screen, but then hangs with debug messages. This can be caused by USB devices such as keyboards. Try again with nothing in the USB.

Raspberry Pi shuts down soon after booting up
This is caused by a power supply producing too low a voltage. See.

Pi boots sometimes but not always
With a known good power supply and known good SD card, the R-Pi boots occasionally, but other times shows only a tiny green flicker from the "OK" LED and it fails to start, even with no USB devices and no Ethernet. This has been reported several times and remains an open issue. Low voltage or an improper SD card can cause it. Some SD cards will work until they warm up slightly, and then fail. When exposed to 21 C room temperature the warmest part of an uncased working R-Pi should be 41 C. The wiki has a list of working SD cards. Buy from a reliable vendor as it has been claimed that 1/3 of all "Sandisk" labelled memory cards are counterfeit.
 * It could be that the SD memory card is not making proper contact with the Raspberry Pi. Look at the SD card holder on the Raspberry Pi carefully. At first glance it may look fine but the contacts must be springy and they must protrude at least 2mm as measured fron the lower edge of the holder to the top of the contact bulge. This happens due to the solder process and the type of holder used. Some of the solder residue falls into the contact cavity restricting the springiness and the height that the contact protrudes. You can fix this yourself but remember you can void your warranty. The contacts are delicate so be carefull. Insert a needle pin under the contact bulge and pull lightly up until the one end of the contact unclips. Clean the cavity where the contact unclipped from of any solder or other residue by blowing into the cavity. Clip the contact back into the cavity by lightly pushing it into the cavity. Do this for all the contacts. Look at these photos. [[Media:SDcardHolder.JPG]], [[Media:UnclipContact.JPG]], [[Media:UnclippedContact.JPG]]

R-Pi does not respond to key presses / Keyboard randomly repeats key presses
This is caused by inadequate power. Use a good power supply and a good power cable. Some cheap cables that work with a cell phone, cannot fully power the R-Pi. Some USB devices require a lot of power: most will have a label showing the voltage and mA requirements. They should be 5v 100mA each max, any more than this they must be used with a powered USB hub. Try unplugging every USB device except the keyboard (you should also note that some keyboards have built in hubs and can try to draw 150mA (Pi can only handle 100mA per USB slot without a hub)). Also, use the latest software. Forum user MrEngman reported some keyboard repeats and wireless hangs until upgrading to the debian6-19-04-2012 kernel, which he reports stable with no problems even with a low TP1-TP2 voltage of 4.65 - 4.68 volts.

Keyboard / Mouse interferes with USB WiFi device
Connecting a keyboard and/or mouse while a USB WiFi device is connected, may cause one or both devices to malfunction. On April 30 2012, there was a bugfix relating to USB sharing between high-speed (eg. WiFi) and full/low-speed devices (eg. keyboard/mouse). User spennig reports this patch did not fix the Mouse/WiFi conflict. On 2012-05-12, user spennig was pleased to confirm that wifi was working with a USB keyboard and mouse, as long as the Raspberry Pi had a good PSU and a powered hub. Even so, some experimentation was needed, e.g. USB WiFi connected to the device, and the keyboard and mouse connected to the powered hub. Some experimentation may be necessary to find a working combination; however a good power supply is essential.

Wireless Keyboard trouble
Some wireless keyboards, for example the Microsoft Wireless Keyboard 800 are reported to fail even though the current drawn by the wireless adaptor is within the R-Pi USB spec limit of 100 mA. This may be a software driver problem.

Re-mapping the keyboard with Debian Squeeze
If different letters appear on-screen from that which you typed, you need to reconfigure you keyboard settings. In Debian, from a command line type: sudo dpkg-reconfigure keyboard-configuration Follow the prompts. Then restart your RasPi. Or: From the command line type: sudo nano /etc/default/keyboard Then find where it says "XKBLAYOUT=”gb”"and change the gb to the two letter code for your country. 

Slow keyboard mapping
If you have remapped your keyboard and get a very long delay during the keyboard mapping at startup, type the following once on the command line after you have logged in: sudo setupcon

No USB device works, with known good PS, SD card, KB
There has been more than one report  of a R-Pi booting but not getting USB input, using a known-good power supply, SD card, and keyboard. The more common cause for no USB devices working is low power supply voltage from bad PSU, cable, or USB hub, but in this case the problem was no clock signal present at the LAN9512 USB/Ethernet chip "IC3", and the solution was to reflow the solder on the 25 MHz crystal "X1" on the bottom side of the board. Or return the board for a replacement, but before making this conclusion, confirm known good peripherals. A significant number of USB keyboards are not compatible with R-Pi. As of June 1 2012, Eben reported that only about 1 in 1000 shipped R-Pi boards have been found to have a hardware fault of any kind.

Check your firmware version
Using the latest firmware version may help various problems with SD card and display compatibility. Check the kernel version with: uname -a Linux RPi 3.1.19 #1 PREEMPT Fri Jun 1 14:16:38 CEST 2012 armv6l GNU/Linux

And the GPU firmware with: /opt/vc/bin/vcgencmd version May 31 2012 13:35:03 Copyright (c) 2012 Broadcom version 317494 (release)

Get the latest firmware version
The GPU firmware and kernel can be updated with Hexxeh's rpi-update tool.

However this requires the Pi to be successfully booted. With sdcard problems, you may not get that far, so can try a manual udpate. If you have a Linux machine, rpi-update can be run on that in an offline mode, and will update your sdcard from the Linux machine.

Otherwise, on a Windows computer, you will see the "/boot" partition appear as the contents of SD card. You can download the latest GPU firmware version here. Click on view raw, then save it, and put the new start.elf file on the sdcard replacing the existing one. Similarly, the latest kernel is here. After updating these files you should be able to boot. You still need to run rpi-update to update the kernel modules (in /lib/modules) and the GPU libraries (in /opt/vc).

Choosing the right ARM/GPU memory split
There is a choice of how the 256M of RAM is divided between the ARM and GPU: arm240_start.elf : 240M ARM, 16M GPU split : Maximum ARM memory. Good for ARM desktop use. No accelerated video or 3D possible. arm192_start.elf : 192M ARM, 64M GPU split : Reasonable ARM memory. Simple video (omxplayer) or 3D (quake) is possible. This is the default. arm128_start.elf : 128M ARM, 128M GPU split : Use this for heavy 3D work, or 3D plus video. Needed for XBMC.

To switch replace start.elf with one of the above files and reboot. E.g. sudo cp /boot/arm240_start.elf /boot/start.elf && sudo reboot

SD cards
Luckily, if you have this problem, most built-in card readers are easy to pull apart and repair; some users have even reported succesfully unjamming the switch with a blast of compressed air from a can into the SD-card slot without having to dismantle anything. You may also be able to temporarily get round the problem by putting the write-protect tab in a half-way position - this pushes on a different part of the strip and may break the contact - it's worth trying a few, slightly different positions. You could also use a USB-SD card adaptor, which are cheap to buy.
 * If you have problems, check you have latest firmware version (described above)
 * Some SD cards do not work on the R-Pi, so check the list of known SD cards.
 * If you are having problems setting up your SD card you might want to start by erasing it completely - especially if it has been used elsewhere and still contains data / partitions.
 * Windows and Mac users can download a formatting tool from the SD Association: https://www.sdcard.org/downloads/formatter_3/
 * Reformatting cards is also easy to do in a digital camera.
 * After writing the image to the SD card, verify that you can see the boot partition when you insert the SD card into your computer. The partition should contain a number of files, including start.elf and kernel.img. If you do not see these files on the SD card, you have made an error writing the image file.
 * If you are manually preparing your SD card on Linux or Mac OS using the dd command, this operation will completely erase any existing data and partitions. Make sure you write to the whole card (e.g. /dev/sdd) and not to an existing partition (e.g. /dev/sdd1).
 * If you have an sdcard that doesn't work with latest firmware, head over here.
 * If you put the SD card into your PC in an attempt to write the R-Pi operating system onto it, and the PC tells you the card is write-protected, even with the write-protect tab in the correct, forward position, then you may have a faulty SD-card rewriter. There's a common fault with many SD-card rewriters - The write-protect tab is detected by a very thin, narrow metal strip, that is part of a switch. When the card is inserted, the write-protect tab is supposed to push the strip and make/break the contact, as needed. Unfortunately, these strips have a habit of getting stuck, because they are mounted in a thin plastic channel, and only need to be deformed slightly sideways to get jammed.

Ethernet connection is lost when a USB device is plugged in
This is caused by inadequate power. Use a good power supply and a good power cable. Some cheap cables that work with a cell phone, cannot fully power the R-Pi. Some USB devices require a lot of power (>100 mA), so they must be used with a powered USB hub. Some cheap USB hubs suck power from the Raspberry Pi even if a USB power supply is connected.

There is an ongoing issue with the Ethernet connection being lost when mouse and / or keyboard are connected via a powered USB hub. The simplest way to solve this is to connect your mouse and keyboard directly into the 2 USB ports on the R-Pi.

Ethernet connects at 10M instead of 100M
The LED in the corner of the board labelled "10M" is mislabeled. When that LED is on, the R-Pi is actually connected at 100 Mbps. You can confirm the true transfer rate using a network benchmark such as iperf. You can also read the current network speed with cat /sys/class/net/eth0/speed

Cannot ssh in to Pi
In the Debian image, ssh is disabled by default. Boot commands are taken from /boot/boot.rc if that file present. There is an example file named boot_enable_ssh.rc that enables ssh. So:

sudo mv /boot/boot_enable_ssh.rc /boot/boot.rc

and reboot should enable ssh. (password as below)

Network/USB chip gets too hot to touch
This is normal. In open air at 24 C, the LAN9512 Ethernet/USB chip reaches about 52 C after some time. This is too hot to touch for more than a few seconds, but it is not unusually hot for the chip.

The LAN9512 data sheet in Table 4.1 on p.40 says it comes in two versions, rated for operation at an ambient temperature in still air (Ta) of 70 C (commercial) or 85 C (industrial). It uses 763 mW at 3.3V with maximum traffic on 100baseT and both USB ports (Table 4.3.4, p. 42).

There is a study of RasPi heat profiles by "Remy" at [http://www.geektopia.es/es/technology/2012/06/22/articulos/se-calienta-el-ordenador-raspberry-pi-estudio-de-sus-temperaturas-en-funcionamiento.html ¿Se calienta el ordenador Raspberry Pi? Estudio de sus temperaturas en funcionamiento] (Is the Raspberry Pi computer getting hot? A study of its operational temperature.)  The Spanish article has numerous color temperature images of RasPi in various operational modes, with the highest LAN9512 case temperature measured as 64.5 C.

Networking no longer works when changing SD card between two Raspberry Pis
In some distributions, /etc/udev/rules.d/70-persistent-net.rules remembers which MAC address is associated with eth0, so each new device will be assigned as a different interface (eth1, eth2, etc.) due to the different MAC addresses. Editing /etc/udev/rules.d/70-persistent-net.rules to remove the invalid rules and rebooting may help fix the problem.

Crashes occur with high network load
The USB driver allocates memory from the kernel, and when traffic is very high (e.g. when using torrents/newsgroup downloads) this memory can be exhausted causing crashes/hangs. You should have a line like:

vm.min_free_kbytes = 8192

in /etc/sysctl.conf. Try increasing that number to 16384 (or higher). If that doesn't work, try adding to /boot/cmdline.txt

smsc95xx.turbo_mode=N

which will reduce network throughput, but has improved stability issues for some.

I do not know the password to login
Please check the page http://www.raspberrypi.org/downloads for the correct username and password for each image.

Here are the most common username/password combinations:
 * Debian after Feb 2012: pi/raspberry
 * Debian 17 Feb 2012: pi/suse
 * Arch: root/root
 * Bodhi: pi/bodhilinux

Some programs refuse to accept my password
While using Debian, some programs may ask for your password but refuse to accept a valid password.

This is a fault in some Debian images and will be fixed soon. If you are using an image with this fault, enter the following command on the command line. gconftool-2 --type bool  --set  /apps/gksu/sudo-mode  true Please enter this command carefully, the spaces are important. The command should be accepted without any response or errors.

I don't know the root password
There is no root password set by default on Debian. You are expected to do everything through sudo. You can set one with "sudo passwd root" - just make sure you know what you are doing with a root account.

Sound does not work with an HDMI monitor
This is caused by some computer monitors which select DVI mode even if an HDMI cable is connected. This fix may be necessary even if other HDMI devices work perfectly on the same monitor (or TV)!

Edit the configuration file - see the instructions at R-Pi_ConfigurationFile.

Add the following line to the configuration file: hdmi_drive=2

This will force it to select HDMI mode.

Sound does not work at all, or in some applications
In Debian Squeeze, sound is disabled by default because the ALSA sound driver is still "alpha" (not fully tested) on the R-Pi. To try out sound, from the command prompt before "startx", type

sudo apt-get install alsa-utils sudo modprobe snd_bcm2835

On Debian Wheezy, snd_bm2835 is enabled, by default, do that step is not necessary. Next try:

sudo aplay /usr/share/sounds/alsa/Front_Center.wav

By default output will be automatic (hdmi if hdmi supports audio, otherwise analogue). You can force it with:

sudo amixer cset numid=3 

where n is 0=auto, 1=headphones, 2=hdmi.

With recent firmware, you can build hello_audio with: cd /opt/vc/src/hello_pi/ ./rebuild.sh cd hello_audio

With older firmware cd /opt/vc/src/hello_pi/hello_audio make

to test analogue output: ./hello_audio.bin and: ./hello_audio.bin 1 to test HDMI.

Also note that you may have to add your user to the 'audio' group to get permission to access the sound card.

Startx fails to start
If you just get errors instead of a desktop when typing startx you may be out of storage space on the SD card. By default there are only a few hundred MB free in the 2 GB main partition, which can quickly fill up if you download files. Make sure there is some space free (gparted can expand a partition, if the SD card is > 2GB). Also, installing some software may incorrectly create or modify a .Xauthority file in your home directory, causing startx to fail, according to this thread. Temporarily renaming, moving, or deleting that file may fix the problem.

Screen is the wrong color
Check and see if the DVI cable is screwed in properly. If that doesn't work then try this section.

Video does not play or plays very slowly
The only hardware-accelerated video player is in the XBMC distribution and its command line variant omxplayer. H264 is the only hardware-accelerated codec, for playback. No hardware encoding is supported. Additional codecs were not purchased as licensing fees would have increased the R-Pi's price.

Can only get 800x480 resolution in LXDE (Arch linux)
Known issue with distro package as of 17th April 2012 - there's some missing boot config information. Creating a suitable cmdline.txt fixes it - type the following at the Raspberry Pi command line:

sudo echo "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait" >/boot/cmdline.txt

Big black borders around small image on HD monitors
Out of the box, R-Pi graphics don't necessarily fill the whole screen. This is due to something called "Underscan", and it can be fixed easily.

Note: the best solution is to disable overscan in display menu options (it may be called "just scan", "screen fit", "HD size", "full pixel", "unscaled", "dot by dot", "native" or "1:1"), then use the disable_overscan=1 option.

Edit the configuration file, see the instructions at R-Pi_ConfigurationFile.

Add the following lines to the configuration file...

If your display has no overscan:

disable_overscan=1

or if your display has some overscan:

overscan_left=-20

overscan_right=-20

overscan_top=-20

overscan_bottom=-20

Making the R-Pi graphics fill the screen is a matter of experimenting with the numbers you put in the config.txt file. Change the numbers – try jumps of 5 or 10 at a time. Bigger negative numbers reduce the black borders (so -40 means less black border than -20). The numbers do not all have to be the same; you can use this feature to centre the display on the screen.

Writing spills off the screen on HD monitors
Out of the box, R-Pi graphics may be larger than the 1080p (ie Full HD) screen. This is due to something called "Overscan", and it can be fixed easily by creating a simple text file on the R-Pi SD card by using Notepad on your PC.

Follow the instructions in the section "Big black borders around small image on HD monitors", but use positive numbers for the overscan settings, for example

overscan_left=20

overscan_right=20

overscan_top=20

overscan_bottom=20

Interference visible on a HDMI or DVI monitor
This may be caused by loss of signal on long video cables. The signal level may be increased by changing a configuration parameter.



Edit the configuration file, see the instructions at R-Pi_ConfigurationFile.

Add the following line to the configuration file config_hdmi_boost=4

You may experiment with different values of config_hdmi_boost. Value 1 is used for very short cables, value 7 is used for very long cables.

This option can also help when there is no display output at all, the display periodically blanks, or colours are wrong/inverted.

This symptom can also be caused by RasPi +5V (measured from TP1 to TP2) falling too low. See "Troubleshooting Power Problems".

No HDMI output at all
First make sure the display is powered on and switched to the right input before booting Pi.

If you have the Wheezy image (recommended) then try hdmi_safe=1

Otherwise, try adding the following line to the configuration file (similar to interference case above) config_hdmi_boost=4

Your monitor/cable may not be asserting the hotplug signal. You can override this with: hdmi_force_hotplug=1

Also try the following video options: hdmi_group=2 hdmi_mode=4 which resolved an issue with DVI monitor reporting "input signal out of range"

As a last resort, try deleting (rename to keep backup) config.txt from the SD card.

Also check that the RasPi +5V voltage (measured from TP1 to TP2) is in the correct range. One user found that his DVI-D monitor blanked out when +5V was too low. See "Troubleshooting Power Problems".

Composite displays only back and white or no image
The output display will default to HDMI if a HDMI display is connected, and composite if not. Make sure there isn't a HDMI cable connected when you want to use composite output.

The composite display defaults to NTSC (American) output. Most TVs will show an image with that, but older PAL (European) televisions may display only back and white or no image. To fix this:

Edit the configuration file, see the instructions at R-Pi_ConfigurationFile.

Add the following line to the configuration file sdtv_mode=2

(You can try other values: 0 is NTSC, 1 is Japanese NTSC, 2 is PAL, 3 is Brazilian PAL)

GPIO
Remember that the GPIO pins are 3.3V logic level only, and are NOT 5V tolerant.

If you momentarily shorted the two end GPIO pins together (+3.3V and +5V), or a supply pin to ground, and the Pi appears to be dead, don't panic. The input polyfuse may have tripped. It is self-resetting after it cools down and the polymer re-crystallizes, which can take several hours. Set the Pi aside and try again later.

The GPIO pins connect directly into the core of the ARM processer, and are static-sensitive, so you should avoid touching the pins wherever possible. If you are carrying a static charge, for example by taking off an acrylic pullover, or walking across a nylon carpet, touching the GPIO pins could destroy your R-Pi, so always earth yourself before touching the pins or anything connected to them.

The time is incorrect
If the clock is off by a series of hours, in the command line type: sudo dpkg-reconfigure tzdata

The R-Pi has no real-time clock, so unless it can access a timeserver over the network at boot, or time is manually entered by the user, the time/date will restart counting from the last logged time in the previous session.

A part broke off
The silver cylinder near the microUSB power input is a 220 uF capacitor ("C6" on schematic). It sticks up and due to the small surface-mount pads, it is easy to break off; several people have done so. This is a power supply filter capacitor which reduces any noise and spikes on the input +5V power. If you like, you can solder it back on, or just leave it off. If you do solder it back on, take care to observe the correct polarity with the black stripe towards the board edge. This part, C6 is a "just in case" component which is good design practice to include, but | as it turns out most power supplies still work OK without this part installed. This part is also discussed here.

Unable to install new software
When trying to install a software package (using the command sudo apt-get install xxxx) you may see the error Package yyyy is not available This means that your software list is out of date. Before attempting to install software, you should always make sure that you are using the latest software list by using the command sudo apt-get update

Troubleshooting power problems
If you think you have a problem with your power supply, it is a good idea to check the actual voltage on the Raspberry Pi circuit board. Two test points labelled TP1 and TP2 are provided on the circuit board to facilitate voltage measurements.

Use a multimeter which is set to the range 20 volts DC (or 20v =). You should see a voltage between 4.75 and 5.25 volts. Anything outside this range indicates that you have a problem with your power supply or your power cable.

If you have not used a multimeter before, see these [basic instructions]

Note: Even if the multimeter shows the correct voltage, you may have some power supply problems. A multimeter only displays the average voltage. If there are very short-lived dips or spikes in the voltage, these will not be shown by the multimeter. It is best to measure voltage when Pi is busy.

If your voltage is low, it could be: Note: keyboards with LCD displays, built in USB hubs, backlights, etc are likely to be problematic. Try to use a basic one. Wifi dongles are also unlikely to work when directly connected. Connect high powered USB devices to a powered USB hub.
 * The power supply produces too low a voltage
 * The power supply cannot supply enough current, which results in a voltage drop. Make sure Power supply is labelled as at least 700mA. (Some cheap power supplies don't deliver what is labelled).
 * The USB power cable is low quality. See: On_the_RPi_usb_power_cable
 * Attached USB devices want too much power. The Pi is only designed for up to 100mA USB devices. A USB device wanting more that that will cause a voltage drop.

Try booting without HDMI, ethernet or USB deviced plugged in, and see if the voltage improves. See also: Power Supply Problems



If you prefer to make your own PSU - see: Power Supply construction - HowTo

Hardware versions/revisions
Several different boards have been found probably from different assembly lines, and the following tables try to help you identify your board for better troubleshooting.

Look for the date of manufacturing printed with the year and week. In this example year (2012) and week (18th):

For what we can see for model B boards there are mainly two versions that differ on the type RAM used, Samsung (S) and Hynix (H).

For Board ver. we used:  (ex.: BS1218 is "Model B, Samsung RAM, 18th week of 2012")

Model A:

Model B:

See a complete list and user feedback here: RaspberryPi Boards

=References=