Products > Test Equipment

Upgrading Mainboard in Lecroy DDA-3000 (aka WavePro 7300a?)

<< < (140/155) > >>

georgo:
I've still got issues with the frontpanel on my SDA3010. Whenever I try to remove the loaded driver from device manager I will get a blue screen with "REFERENCE_BY_POINTER" Error. I did a fresh Win7 x32 install but the problem ist the same.

When I run the DSO Application  - the FrontPanel Emulation shows up - and entering the Service Menu I get Hardware ID = None and Led SlaveAddr = -1

Could it be a hardware Issue? Has anyone experienced a similar problem?

Mechatrommer:
not sure your problem is, but starting last night i removed my SDA6000 from its operation place into service place because it was giving me persistent random screen colors and dots and blue screens of death during probing few weeks ago. sometime i noticed corrupted/sliced text etc, i thought like display memory corruptions or loosen cable connection. last night i opened it up and turned it on (because i'm going to use it soon, so repair first) and the problem got worse, random color dots, and then squares and horizontal dashes and stripes everywhere during boot screen and unable to enter windows and then bsod, i was imagining the worst like damaged/incompatible motherboard and cpu (D865GSA + Pentium D 945 2 cored combo) i thought i'm going to need new more modern motherboard and will need georgo's hdmi to lvds adapter, or dso HW damage is also possible since i remember i lost traces plot on the screen and weird buttons blinks. i thought its going to be a long day or week for this repair project.. or if i cant find newer motherboard thats suitable, i thought i have to go back with the original motherboard that came with it which is highly underspeced from my current upgrade.

but luckily i got my mind settled down and do things rationally as its supposed to be, so i start with simple test first, one step at a time. i switched the 2x 1gb ddr memory that i bought 2nd hand about 2 years ago with the original 512mb ddr memory that came with the dso, turn it on and walla it works! i can start xstream app and get back my traces, no problem, no sign of corruption. turned it off and switched back to earlier ddr 1 piece at a time (1gb), it turned out one of the ddr piece that i bought is ending life, it went wacky and responsible for all the corruptions, so it goes to the bin and i'm currently on 1x 1gb ddr slot only temporarily, ordering another 4 pieces used kingston ram from eshop last night, better buy extra for spare parts. so luckily it was a quick repair and diagnostics. i was about to restore file system first but i thought file corruption is unlikely since i use new ssd. if i reformat the ssd first or worse dismantle the motherboard, really its going to be a long day of unecessary repair, just a lesson, the morale is, test simplest step first, dont go with emotion to deal with bigger thing, we wouldnt know... i think my dso is back again so far, hopefully for longer time. fwiw.

to georgo i hope you too can fix your problem soon. cheers.

georgo:
just a small update on my frontpanel issue ... and i am also asking for advice if someone has an idea how I should proceed.

After trying various things. I found out that the Connector J4 on the frontpanel board - was not seated correctly. Most likely the +3v3 was not connected.
This cable connects via a 16pin ribbon J4 on the frontpanel to J10 on the Touchstone-Board. This cable carries power for the frontpanel but also I2C for identifying the type of frontpanel. The same I2C also connects to the ProBus-Interface via J3 on the frontpanel board.

But the Data from the frontpanel is connected to the Aquistion PCI-Board via J2 - the 22pin FPC.

I do think that the MCU on the frontpanel is a MC68HC705C8ACFB (or something similar in a QFP44 package).
https://www.mouser.at/datasheet/2/302/MC68HC705C8A-1126873.pdf

with this knowledge i tried to make an educated guess that the Data is transfered over a SPI bus. If this assumption is correct than the pinout of the J2 is something like that:

1 GND
2 GND
3 GND
..
7 GND
..
10 MOSI
11 SCK
..
14 SS/
15 GND
..
17 MISO
..
21 GND
22 GND

----

To verify this assumption I started up the DSO Application and switched CH1 (via the Mouse) ON and OFF - because this would also toggle the LED associated with it.

So I started measuring the SPI Lines.

At first it seemed that MOSI is not working, cause I could measure activity on SCK and SS/  but not on MOSI. So I was afraid that maybe the SuperIO LPC47N227 was damaged. But after repeating the mesurement I could also receive something on the MOSI Line, while booting windows ( probably during driver initialisation) and application start. There are some bytes transfered and it seems that the bytes are always 0x80 (MSB first).

After start of the DSO application I can switch CH1 on/off and I do get activity on SCK and SS/ but MOSI always remains high.

I am not quite shure how I should proceed ... I am grateful for any Ideas, howto debug this issue further?


Remark: Pushing Buttons or turning Knobs doesn't result in SPI activity

georgo:
Digging deeper on the frontpanel.

After writing my last forum post, i stepped back and reflected if I am using the wrong drivers. I re-read the forum thread and concluded that I have to switch to v2 of DXL driver set (with the unmodified frontpanel driver) ... should have read the forum beforehand ...

With this driver I don't get the Bluescreen problem on removing the driver.

However still no success - so I decided to have a look at the LED shift registers - There are two of them U118 and U2 both of 74HC594-Type.

They are connected to J2

Pin 8 .. LED_RESET/ (STR/)
Pin 9 .. LED_DATA (DS)
Pin 11 SCK (SHCP)

SCK is shared with the MCU SPI. For the LEDs 16 Bits are clocked into the two registers.


With my Logic Analyzer I can see that LED_DATA is changing just fine (changes on CH1 Led are reflected on the LED_DATA).
BUT LED_RESET never is released!!!

Again when I look at the whole sequence I can measure activity on LED_RESET during driver loading, meaning the output of the SuperIO is working.

So my next guess would be that the LED Panel is somehow not properly addressed.

Could somebody please be so kind and lookup in the ServiceMenu (Code 9472) in the frontpanel section what the value of "LED Slave Address" is? thanks in advance.



Converter:

--- Quote from: georgo on October 17, 2020, 03:30:32 pm ---
Could somebody please be so kind and lookup in the ServiceMenu (Code 9472) in the frontpanel section what the value of "LED Slave Address" is? thanks in advance.

--- End quote ---
It should be so.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod