Siglent 1202X-E recovery

[jonathanlemoine]

Hi there guys. I picked up a Sds1202x-e as a repair project off of EBay. The listing said it had a booting problem. I did manage to get it to boot eventually by a hard reset and a long 30min wait. When it did boot it displays something like noise on the screen. Full length of the graticule no matter what scale. It has the latest firmware and nobody has been inside of it. I was thinking maybe a firmware flash gone wrong? I've been trying to flash othe firmwares with no luck. Mostly because getting it to reboot is nearly impossible. You can spend hours trying to get it to boot into the main screen again. It looks new. Came in the original box with all accessories and manual. Nobody has even changed the little probe rings.

[tautech]

Hmm, interesting. 
Have you tried to do the Self Cal ?

Wonder why the previous owner didn't try for a warranty claim ?

[jonathanlemoine]

I have done a self cal and it took a little of it out but not much. It takes anywhere from 1hr to never to complete. Usually it just hangs. I have managed to downgrade the firmware and if anything it made it worse. I'm leaning towards a hardware issue now. I may have to crack it open. I agree it's very strange that someone didn't try for a warranty claim. it only had 22 boots when I got it. I am now up to 144 and I have only been playing with it for a day.

[tautech]

OK thanks. I'll go fishing for some answers/solutions for you.

[jonathanlemoine]

  well this doesn't look normal. Upon further inspection it looks like the glue they used to fix the heatsink to the processor. Someone got messy at the factory. It's a thick, very hard substance. Crappy.

[jonathanlemoine]

All around the heatsink. Not sure if it's the problem though. It makes sense that it would be the reason that it hangs and won't boot half of the time.

[jonathanlemoine]

Not conducive though. Moving on. Going to have a look at voltages and ripple on the outputs of the PSU.   

[jonathanlemoine]

All voltages on the main board appear to be correct and all clock signals are present.  That's about all I can do. Well maybe I'll hook up a serial connection and see what that is saying....gurrrrr

[thinkfat]

That could be a good idea. Of course provided Siglent chose to output some kind of helpful diagnostic messages. There's a Linux system working under the hood. If you get a console, please post the boot log, I'd like to have a look.

[jonathanlemoine]

Here is a text file with the output..this is where it fails to boot. FPGA problem? I'll try to get one where the boot is sucessful also. I wasn't sure if I should attach it as a file or just paste it in here.it

edit:

Actually finally finished booting with no further output. So this is it.

[thinkfat]

Here is a text file with the output..this is where it fails to boot. FPGA problem? I'll try to get one where the boot is sucessful also. I wasn't sure if I should attach it as a file or just paste it in here.

I'd attach it as a file. Easier to handle than inline text.

[Mark19960]

It's not happy about one of the FPGAs in the instrument and that doesn't bode well.

Code: [Select]

insmod: can't read '/usr/bin/siglent/drivers/udc-xilinx.ko': No such file or diy
Can't load the driver to even talk to the FPGA?

There are other things in there like a CRC error and it not being able to copy from USB.

[thinkfat]

Here is a text file with the output..this is where it fails to boot. FPGA problem? I'll try to get one where the boot is sucessful also. I wasn't sure if I should attach it as a file or just paste it in here.it

edit:

Actually finally finished booting with no further output. So this is it.

The log lines seem to have been cut at 80 columns. But there's nothing jumping out, actually. Can you configure your terminal program to capture the full lines and add a timestamp in front of each line?

[goaty]

So the TOis a similar unlucky person like me who also tries to buy broken stuff for repair but doesn´t have Shariar´s luck (signalpath) for finding graeat equipment with minor errors 

[thinkfat]

It's not happy about one of the FPGAs in the instrument and that doesn't bode well.

Code: [Select]

insmod: can't read '/usr/bin/siglent/drivers/udc-xilinx.ko': No such file or diy
Can't load the driver to even talk to the FPGA?

There are other things in there like a CRC error and it not being able to copy from USB.

The CRC error is normal if the u-boot environment has no backing store in the NAND (because it isn't provided or it has never been initialized).

Not being able to load the linux kernel from USB is also not an error. That looks like part of the development setup still part of the firmware. It successfully loads the kernel from NAND afterwards.

The FPGA related messages are a bit suspicious, but they could be just normal debug output. Maybe if you look around on the forum a bit you'll find a boot log from a working device. I know Dave Jones has put boot logs from Siglent scopes up for download, maybe check out the thread regarding the test and teardown of this scope.

[jonathanlemoine]

i copied and pasted from the terminal. On my screen the colums weren't  cut off. maybe something happened when i copy it to LibreOffice. Mayabe I should make the file with the command line instead?
Maybe next time. I don't do this often guys sorry. Here is an odt file instead of text incase something was lost in the txt format.This time where it goes into a kernal panic. As you can see it fails 785s into the boot process. It does take a long time to boot when it does.

[Mark19960]

ODT looks better to me.
There is a kernel panic related to the FPGA.

Might be worth some checking about to make sure all of the power supplies for the FPGAs are up and running.

[thinkfat]

The kernel panic certainly isn't a good sign. It looks like the software is waiting for a certain status from the FPGA which doesn't arrive.

Code: [Select]

[  785.178931] [000010c4] *pgd=00000000
This means the CPU tried to access memory that isn't mapped, could be the equivalent of a null-pointer de-reference.

The stacktrace is also a bit weird, it failed in sched_show_task(), called from rcu_print_detail_task_stall_rnp(), this is a standard diagnostic kernel function that belongs to the RCU subsystem (read-copy-update). It appears the kernel detected a stuck task and tried to call it out and then panic'd while it tried to print the task data.

It sounds like there's something very wrong, at least something that the software was never prepared to handle sensibly.

[jonathanlemoine]

This is interesting. Figured I'd try to see why it won't complete a recalibration.

[Mark19960]

I know there are chaps a lot better at this than I certainly but some module that may not have loaded and then a bunch of errors about a read-only filesystem.
Seems to start pointing in my mind to the flash being corrupted or bad.

[jonathanlemoine]

Maybe someone will have an idea. Until then I have a paperweight. I thought about reflowing the FPGA but I don't know if that would do anything and may just make things worse.

[tautech]

  Didn't think you'd be so keen to rip it apart and go sniffing just yet.
I haven't heard back from Siglent but now they have lots of additional info to digest. 

[jonathanlemoine]

I should be leaving it alone but I figure I might as well learn some things on something that doesn't matter if I break it... Don't get me wrong I'd love to get it working. I bought it for $285 CAD + shipping so it would be an expensive paperweight. Right now I'm just sniffing around to see if I can see anything odd... The trouble is I don't know enough. For instance why is the root filesystem mounted read-only. How can anything be configured if nothing can be changed? Seems odd. But I know nothing. I appreciate everyone's help though. I really need it. I'm aware it may be beyond my ability to fix in the end but I like to try. It's all a learning experience.

[thinkfat]

This is interesting. Figured I'd try to see why it won't complete a recalibration.

I see you're using minicom. Ctrl-a w switches on line-wrap mode, ctrl-a l allows logging into a text file. Ctrl-a n toggles different timstamp modes.

I should be leaving it alone but I figure I might as well learn some things on something that doesn't matter if I break it... Don't get me wrong I'd love to get it working. I bought it for $285 CAD + shipping so it would be an expensive paperweight. Right now I'm just sniffing around to see if I can see anything odd... The trouble is I don't know enough. For instance why is the root filesystem mounted read-only. How can anything be configured if nothing can be changed? Seems odd. But I know nothing. I appreciate everyone's help though. I really need it. I'm aware it may be beyond my ability to fix in the end but I like to try. It's all a learning experience.

I didn't see rootfs mounted read-only in your first log, but if it is, that's a sign of a corrupted NAND flash.

Maybe someone will have an idea. Until then I have a paperweight. I thought about reflowing the FPGA but I don't know if that would do anything and may just make things worse.

That's probably the last thing I'd try. Carefully applied pressure might have the same effect temporarily and be less dangerous.

[jonathanlemoine]

Ok so I tried applying some pressure too the chips while booting and it had no effect.
Any file I open with vi is read-only. Also I can't create any files as it returns an error that the filesystem is read-only.
I guess we found the problem then? Corrupted NAND? I take it there is no fix like a re-flash? Ah well. It was a nice journey.