New RPi seems not to work

I have the same problem

My Raspberry Has the pwr light on. The ok light has the faintest green light ever(pin dot size)

and i get no display. I have tried Multiple power adaptors.

I recieved Mine yesterday.

One of my Friend has this problem too.

David Sullivan wrote:

 

I have the same problem

My Raspberry Has the pwr light on. The ok light has the faintest green light ever(pin dot size)

and i get no display. I have tried Multiple power adaptors.

 

I recieved Mine yesterday.

Is this a problem with a certain batch?  I am going to test my friend's RPi to see he has a bad RPi.

Fergus Byrne wrote:

 

One of my Friend has this problem too.

David Sullivan wrote:

 

I have the same problem

My Raspberry Has the pwr light on. The ok light has the faintest green light ever(pin dot size)

and i get no display. I have tried Multiple power adaptors.

 

I recieved Mine yesterday.

Is this a problem with a certain batch?  I am going to test my friend's RPi to see he has a bad RPi.

I'm starting to wonder if there's a bad batch.  It could also be that there are a few random bad boards, and the vast majority work fine so we don't see queries.  That doesn't help if you're the one with a bad board.

My general advice is to start with the RasPi Troubleshooting page (http://elinux.org/R-Pi_Troubleshooting), which now covers the most common user-fixable problems.  If that doesn't make your RasPi perky and you know someone who has a RasPi, try swapping SD cards.  Not knowing if you have a working SD card with a working image is a real pain, and I like Morgaine's suggestion that all RasPis ship with a working OS -- any working OS -- to avoid this pain.

If all the user-fixable culprits have been ruled out, it's probably a failed solder joint and it's RMA time.  I detest BGAs because they're inherently unreliable, especially when subjected to thermal cycling.  BGA solder balls don't flex when heated -- they crack.  And that SoC has lots of tiny balls, both on the top and on the bottom.  It only takes one DRAM address or data line to cause the green OK LED to behave like a dim bulb.  SoC tries to read from SD card (LED on) and then immediately crashes (LED off), and the process repeats with a low duty cycle.  Just my hypothesis, YMMV.

I don't know if RasPi gets any "burn in" testing at the factory.  At this price point, probably not in which case end users are providing that service.

At some point, maybe someone will put power-on diagnostics into the boot image and run them out [of] cache.  The diags could test DRAM connectivity and functionality and flash out an "SOS" in Morse code over the OK LED in case of failure.

EDIT:  The good news is that RasPis are a lot more plentiful nowadays so an RMA should be PDQ.

Fergus Byrne wrote:

 

One of my Friend has this problem too.

David Sullivan wrote:

 

I have the same problem

My Raspberry Has the pwr light on. The ok light has the faintest green light ever(pin dot size)

and i get no display. I have tried Multiple power adaptors.

 

I recieved Mine yesterday.

Is this a problem with a certain batch?  I am going to test my friend's RPi to see he has a bad RPi.

I'm starting to wonder if there's a bad batch.  It could also be that there are a few random bad boards, and the vast majority work fine so we don't see queries.  That doesn't help if you're the one with a bad board.

My general advice is to start with the RasPi Troubleshooting page (http://elinux.org/R-Pi_Troubleshooting), which now covers the most common user-fixable problems.  If that doesn't make your RasPi perky and you know someone who has a RasPi, try swapping SD cards.  Not knowing if you have a working SD card with a working image is a real pain, and I like Morgaine's suggestion that all RasPis ship with a working OS -- any working OS -- to avoid this pain.

If all the user-fixable culprits have been ruled out, it's probably a failed solder joint and it's RMA time.  I detest BGAs because they're inherently unreliable, especially when subjected to thermal cycling.  BGA solder balls don't flex when heated -- they crack.  And that SoC has lots of tiny balls, both on the top and on the bottom.  It only takes one DRAM address or data line to cause the green OK LED to behave like a dim bulb.  SoC tries to read from SD card (LED on) and then immediately crashes (LED off), and the process repeats with a low duty cycle.  Just my hypothesis, YMMV.

I don't know if RasPi gets any "burn in" testing at the factory.  At this price point, probably not in which case end users are providing that service.

At some point, maybe someone will put power-on diagnostics into the boot image and run them out [of] cache.  The diags could test DRAM connectivity and functionality and flash out an "SOS" in Morse code over the OK LED in case of failure.

EDIT:  The good news is that RasPis are a lot more plentiful nowadays so an RMA should be PDQ.

i'll let you know the results of my Friend's RPi testing with my power adapter and my SD card. 

I will get back to you with these results (working or not working ).

I'm starting to wonder if there's a bad batch.  It could also be that there are a few random bad boards, and the vast majority work fine so we don't see queries.  That doesn't help if you're the one with a bad board.

If there's any suspicion of a bad batch, then when people come here with problems one of the very first things we ask needs to be what the FN1207xxxxx label on the bottom of the board is. That'll quickly show if there's a pattern of closely related serial numbers.

Also likely not relevant to Johns particular problem, but nobody bothered to ask the much too obvious question if the particular input on the TV was known to be working and if that input had been selected.

Not everyone who comes here asking for help will be a rocket scientist (No offense meant John, especially if you are ), so we should start with the basics before assuming the worst.

I'm very guilty of expecting people have some basic level of knowledge, but the audience for the Pi is such that this may not be true. So I'm trying hard to ask all the dumb questions that might just help someone

selsinork wrote:

 

I'm starting to wonder if there's a bad batch.  It could also be that there are a few random bad boards, and the vast majority work fine so we don't see queries.  That doesn't help if you're the one with a bad board.

 

If there's any suspicion of a bad batch, then when people come here with problems one of the very first things we ask needs to be what the FN1207xxxxx label on the bottom of the board is. That'll quickly show if there's a pattern of closely related serial numbers.

 

Also likely not relevant to Johns particular problem, but nobody bothered to ask the much too obvious question if the particular input on the TV was known to be working and if that input had been selected.

 

Not everyone who comes here asking for help will be a rocket scientist (No offense meant John, especially if you are ), so we should start with the basics before assuming the worst.

 

I'm very guilty of expecting people have some basic level of knowledge, but the audience for the Pi is such that this may not be true. So I'm trying hard to ask all the dumb questions that might just help someone

Here Here!  I have seen that some people on the forums just assume you know linux inside and out but the fact is that most people don't.

Here Here!  I have seen that some people on the forums just assume you know linux inside and out but the fact is that most people don't.

I've been using linux for more than 20 years, since before RedHat/Fedora, Debian or Suse even existed. Back then 'linux' was two floppies and didn't really support hard disks properly.

I can confidently say that I don't know linux inside and out

It is true that the obvious can sometimes be overlooked. But, yes, the setting on the TV was appropriate and known to be working.

There is no activity on the green LED at all.

As far as SD cards go, I have tried 2. Both appear to have valid images with a full file structure as viewed from another Linux system. For the Raspian version, there is also a windows accessible section with booting files as mentioned in the trouble shooting guide.

It appears that I have come to the end of what can be done, since I have no access to a known working card. It seems to me that if the device is so sensitive to the card type, perhaps it should be supplied with a tested card.

John Tendys wrote:

 

It is true that the obvious can sometimes be overlooked. But, yes, the setting on the TV was appropriate and known to be working.

There is no activity on the green LED at all.

As far as SD cards go, I have tried 2. Both appear to have valid images with a full file structure as viewed from another Linux system. For the Raspian version, there is also a windows accessible section with booting files as mentioned in the trouble shooting guide.

It appears that I have come to the end of what can be done, since I have no access to a known working card. It seems to me that if the device is so sensitive to the card type, perhaps it should be supplied with a tested card.

It is supplied with a card but you have to pay extra for it ! Not sure if E14 have started this yet but I know that you can buy working cards from RS.

It is supplied with a card but you have to pay extra for it ! Not sure if E14 have started this yet but I know that you can buy working cards from RS.

Next week: http://uk.farnell.com/samsung/raspberry-pi-prog-4gb-sdcard/memory-sdcard-raspberry-pi-4gb/dp/2113756

There is no activity on the green LED at all.

That's not good.  with earlier firmware there was little noticable activity on the green led until after the kernel was loaded.  With recent images this has changed and you now get two or three very noticable flashes very quickly after power on.

As far as SD cards go, I have tried 2. Both appear to have valid images with a full file structure as viewed from another Linux system. For the Raspian version, there is also a windows accessible section with booting files as mentioned in the trouble shooting guide.

There should be a windows accessible section on all images as the SoC uses a small FAT16 partition to store the GPU blobs, start.elf and the kernel.img.

Another stupid question from me.. You mentioned earlier using Winimager to write the card. Did you try writing the card using the linux system as well ?

It seems to me that if the device is so sensitive to the card type, perhaps it should be supplied with a tested card.

Perhaps it should be, not sure it would help. If it doesn't boot you're then left with the question whether the supposedly tested card and/or Pi is at fault.

SD card compatibility is getting better, if you'd been trying this back in April when the first ones were delivered they were a whole lot more picky about what worked.

Anyway, seems you're doing all the right things. If you still can't get it working or find someone local with a working one you can use for further troubeshooting then you don't seem to have a lot of choice. Go for the RMA.

I thought that I should report how the story ends.

Element14 replaced my RPi, and I am delighted to say that it works now exactly as advertised, using the same SD card and image, and power supply.

So thanks to all you folks for your help, and I learned more about the RPi trying to troubleshoot than I might otherwise have.

Great to hear!