Yes, from that and the https://www.raspberrypi.org/documentati ... teeprom.md all tends to indicate corrupted EEPROM. The problem here is that I can't manage to rewrite the eeprom following that procedure.Imperf3kt wrote: ↑Tue Oct 08, 2019 2:35 amI assume you've read the Pi4b section of the.boot sticky?
https://www.raspberrypi.org/forums/view ... 1#p1485558
Are you able to measure the SD clock and command lines ? Best guess is that some fault related to the sd-card which has caused the ROM to hang and fail to proceed to the EEPROM, although I've never seen this when the sd-card slot is empty.iosabi wrote: ↑Tue Oct 08, 2019 12:08 pm"Does this happen if you remove the SD-CARD and power on ?"
Yes, same symptoms with or without an sdcard installed.
I probed around the EEPROM with the oscilloscope and found out that the EEPROM is not even read:
1) On my healthy Pi4B without an sdcard, when probing the #CS (pin 1) and CLK (pin 6) of the chip labeled 4H916 next to the AV jack, I see the following sequence:
* #CS stays up for ~100ms, then down for ~180 ms while the EEPROM is read
* CLK goes up for ~12ms, then down for 90ms, then I see a clock of about 3.5MHz with ~1 clock pauses every 8 pulses. This is clearly reading the EEPROM (it looks to me like less than 4Mbit, but didn't measure super accurately)
2) On the other Pi4B, again without the sdcard at all I see:
* #CS goes up and stays there forever (2s+)
* CLK goes up for ~12ms, then down forever
The pi then sits there draining 300mA @ 5V. Nothing obviously dead in the power side.
The green LED blinks very briefly, I measured ~12ms but this happens very early. It starts ~70ms after applying power to the 5V rails in the GPIO header. This is at the same time that CLK goes up for 12ms, so well before we even read the EEPROM (which doesn't happen in the broken Pi4B).
Is there anything earlier than the 4Mbit EEPROM that could be broken? Any hints on how to debug this?
This rpi4 is new, I have booted it only a few times before and if I remember correctly it broke when updating the eeprom from the running OS.
I created the sdcard in linux with gparted, selecting fat16 or fat32. I also tried formating the partition with mkfs.fat which lets you force fat16 or fat32.
I don't think there's much more that you can do to debug it. However, we'd be interesting in getting the board back so that our hardware engineers can take a look. We'll send you a replacement + Pi goodies to cover the postage & hassle.iosabi wrote: ↑Wed Oct 09, 2019 9:30 amTimg236, first of all thank you for following up on this issue. Really appreciate your time looking into it.
I measured the sdcard slot lines without any sdcard in it. All of them remain low, except for the sdcard Vdd which comes high (3v3) ~70ms after power is applied to the 5v lines in the gpio port.
In the healthy pi4b i also have, I see a clock in the CLK line after about 15ms of sdcard Vdd coming up, but this doesn't happen on my other pi4b. I don't see any physical damage, and as I say I was trying to flash the new eeprom from a booted OS when this stopped working.
Is there any JTAG or other debug port I can look at for the main cpu?
It's not easy to spot on that photo either - is it the thing to the left of the 2D barcode label?timg236 wrote: ↑Tue Oct 22, 2019 11:20 amThe reason that the board was no longer booting is that a resistor had become dislodged which prevented the SOC from powering up properly. It's a tiny resistor so not easy to spot but I've attached an image showing where it was re-worked which allowed the board to boot and run Raspbian. The bootloader EEPROM seemed to be fine.
N.B. The brief flash of the green LED at power on is just due to the power sequencing rather than the ROM enabling it.
https://drive.google.com/open?id=1KtjSr ... begfSVrWDe
I was under the impression that all boards were individually tested at the factory, but I may be wrong. It perfectly possible that it was attached firmly enough to test OK then due to mechanical stresses, vibration etc somewhere along the way came loose.