Electronics > Repair
Tektronix DPO4054 stucked at tektronix splash screen
<< < (11/16) > >>
analogRF:

--- Quote from: ApertureScience on February 14, 2021, 05:34:18 pm ---analogRF, I just found your thread regarding the dpo4104. I dont know how I didnt find it beforehand |O

I tried the firmware update....so it gets past the boot screen, but only on firmware lower than 2.68. It still crashes afterwards with not being able to handle button presses because of errors and finally kernelpanic :-DD

--- End quote ---

I'd still think there is also a problem in the CPU/computer area and not just the acquisition.
can you post the new boot log after forcing the firmware refresh
pcwrangler:

--- Quote from: analogRF on February 12, 2021, 01:41:48 am ---did you check all the crystal oscillators? there are several of them. at least two I remember were on the bottom side. Remember the CPU clock is 333MHz which is not directly generated by any crystal so there must be a PLL somewhere to multiply one of those crystal frequencies up to 333MHz
or maybe the CPU has that PLL implemented inside of itself.

--- End quote ---
All oscillators on both sides are present and stable. The CPU does have an integrated PLL.


--- Quote ---I'd start by CPU architecture and pin out.
IF everything is suddenly stopped and there is no activity, either a clock has stopped or the CPU is halted or reset. So finding those pins is important

--- End quote ---
I checked every pin imaginable from the vias under the BGA. The only suspect was clkEn which enables the RAM clock. It is steady at 2.2v instead of the documented 2.5v in the CPU datasheet. However,  I believe that is still within SSTL 2 specs.  :-//


--- Quote ---I think this CPU has no internal ROM (check?), so I guess that I2C EEPROM provides the small bit of code needed to start a boot loader but from where? or perhaps the EEPROM actually contains the bootloader itself? 1KB seems too small for that I guess but who knows.

--- End quote ---
You were right. I confirmed the CPU bootstrap is configured to gather boot configuration from the 16 bytes on the I2C EEPROM. I believe that is telling the CPU to get the bootloader from the 4MB flash chip at U822. The CE and OE pins between the CPU and U822 start enabled and then go high at the same time the boot log stops. I think bootloader instructions are interrupted because of this. I just don't know why the CPU is doing this.


--- Quote ---your system is halted in the middle of that small code (or boorloader) for some reason. at that point nothing has been initialized yet I think
but DDR memory is probably already in play here so checking that supply termination is a good start. That is a specialized regulator IC soldered very near the CPU I dont remember the P/N but just look around the CPU and you will see it.

--- End quote ---
I confirmed the DDR termination regulator is at U650 and is behaving as specified in the datasheet. :(


--- Quote ---maybe it's a good idea to use I2C decoding on the SDA/SCL lines of that chip and see what you get and compare with what the datasheet says about the signaling of that EEPROM.

But first and foremost is (1) all voltages including the DDR termination chip (2) all crystal oscillators (3) finding out if the CPU is halted or reset

--- End quote ---
Sadly, I have ruled out voltages, DDR termination and oscillators. I will attempt an I2C decode just to see what it looks like but I think we are beyond the I2C EEPROM step in the boot process.

Is it possible that the bootloader on the flash is damaged or missing at my halt point due to a failed FW update? I do have the means to program that chip if necessary. It feels like I'm so close!
analogRF:

--- Quote from: pcwrangler on February 15, 2021, 12:52:24 am ---
--- Quote ---I think this CPU has no internal ROM (check?), so I guess that I2C EEPROM provides the small bit of code needed to start a boot loader but from where? or perhaps the EEPROM actually contains the bootloader itself? 1KB seems too small for that I guess but who knows.

--- End quote ---
You were right. I confirmed the CPU bootstrap is configured to gather boot configuration from the 16 bytes on the I2C EEPROM. I believe that is telling the CPU to get the bootloader from the 4MB flash chip at U822. The CE and OE pins between the CPU and U822 start enabled and then go high at the same time the boot log stops. I think bootloader instructions are interrupted because of this. I just don't know why the CPU is doing this.


--- End quote ---

excellent piece of troubleshooting  :-+ This is the most important information that we have by now and you should focus on this flash memory U822. I also think it does contain the bootloader code. Can you remove the sticker and post the part number?

you are right, based on what you have gathered, the I2C EEPROM has done its job and I dont think it is at fault.

I'd guess the bootloader flash is corrupted. At least at this point and with the other information that we have, this seems to be the most likely cause. It happens  :palm:
That chip is easy to desolder and solder back in. If I remember correctly it is QFP package with J-leads, right? so one course of action would be to
just desolder it and read it and perhaps get a similar chip off another scope and re program this one.


one last thing to check, if you let the scope run for while, does any component get hot? I mean only the CPU, DRAM or the flash chips?
 
pcwrangler:

--- Quote from: analogRF on February 15, 2021, 02:11:53 am ---excellent piece of troubleshooting  :-+ This is the most important information that we have by now and you should focus on this flash memory U822. I also think it does contain the bootloader code. Can you remove the sticker and post the part number?

--- End quote ---
U822 is a Am29LV040B PLCC. Does anyone have a dump of this chip? This MSO4104(non-B) has the same version header as others have posted from different versions of the 4000. "U-Boot 1.1.4 (Jan  8 2007 - 11:12:14) Tektronix, Inc. V1.06". I'm not sure if that means it's universal and interchangeable but I also found this same version digging through the downloadable FW update from Tek. Maybe I'll desolder and compare the two.

--- Quote ---one last thing to check, if you let the scope run for while, does any component get hot? I mean only the CPU, DRAM or the flash chips?

--- End quote ---
Unfortunately, no. This was the first thing I checked with an IR cam, hoping to find a simple short.  :--
m k:
My guess is that F-line is good and if that flash has a checksum it's good also.
Based on an assumption that the programmer is not doing the text letter by letter.

There seems to be a leap from F-line to next.
If there is a watchdog, is it so accurate that it will never let through more or less than that F.

Processes seems to be asyncronous, many processing entities I guess.
How long is one letter sent, is that time too long, can it really pin point anything.

If PCI-signals are easily accessed I'd check that the bus is alive.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod