do you have access to firmware download? maybe try reflashing it?

This isn't EEVBlog 2, material post it on main for all to see!

Complete guess "Error Module: mui_task func mui_if_display_wm line: 00155: hwin is 0" mui_if_display_wm might be: interface display window-manager Sounds like it's trying to get a handle to the display (hwin) and fails (null) Massive speculation: Is it possible the display processor has the boot image baked into it? (and it's not the CPU) It could just mean the flat-flex cable is damaged?

The FPGA itself is fine. To quote the service manual "To check if the FPGA is working properly, please observe the test point marked with FPGA_LED on the channel board drawing. The LED light flashes at the rate of 1Hz in normal case, if it cannot be lighted or twinkles at incorrect frequency, then the FPGA may be at fault." Hardware-wise everything seems to be fine, it's strictly a firmware corruption error. I'd try re-seating the ribbon cables just in case, maybe the CPU can't communicate with the FPGA itself. Other than that, I suggest contacting Siglent.

SO8 with massive inductor, diode and capacitor? Yeah, probably a linear reg!

What are the details on that serial interface board? I would like to get one.

This calls for a diagnosis and repair video on the main channel!

Hey, what is this uart level converter board? Brand? Where to buy? Thank you

A bunch of "module config error: invalid parameter" messages don't look like a clue?

Deader than a Dead Dingo's Donger... wow, as a Canadian that is definitely not something I've ever heard hahahahaha.

Kinda looks like it either can't load the fpga.bin file or the module loads but the path to the fpga is obstructed. Is there a way to factory reset the arb with a button on power up (like an old school LCD organiser) or similar key combo? A hard reset to factory would clear up any data corruption issues. Could the path to the analogue fpga be obstructed or a ribbon cable not seated properly?

any chance you could add a link to that serial board?

Check the output to see if it's generating a signal. Is there a button on the front to switch the output on?

That "heart beat" in the CPU card's LED is a Linux standard LED trigger. Its frequency varies depending on the system load. In this case, it isn't it terribly fast unlike what you would expect to see during a startup. In my opinion, it's simply waiting for something, though I have no idea on what it could be. My favorite choice would be to reflash.

Since you did a tear-down before, try to reseat the flatflex cable for the front controls and display.

Try re-seating all the ribbon connectors. It might be a flash memory issue like you said, maybe corrupted cal data. Have you tried powering it up while holding down various buttons?

Does it finish loading the FPGA? I see it start near the end of the kernel boot log... Also that C++ application debug dumping to the kernel log is a bit _how you doin_ ... typically that is debugging printk() statements left in a driver somewhere... - Eddy

I had to repair a Nikon microscope camera that had failed after some mains power disturbances. Nikon metrology had remotely diagnosed a failed motherboard and wanted about £2000 for a replacement, plus another £500 off for fitting and it was at this point that my help was sought to ask if I could fit the board. I wasn't about to believe Nikon's diagnosis without checking for myself. The unit crashed and rebooted whenever you selected the camera on the touchscreen, so I guessed that the operating system was likely corrupted due to the power disturbances. There's a whole long saga about Nikon's apalling customer service and all the hoops I had to jump through to get hold of the firmware. Then there's the fact that the installation instructions were wrong, but eventually I got the firmware installed and the camera sprung to life. It's increasingly a problem with equipment that has a build in operating system, Windows CE, or some flovour of Linux, that it gets corrupted and you're faced with a brick.

Check the mechanical connection between the front panel and the control PCB. My guess is that the UI process waits for a response from the front panel before drawing anything on the display.

is it possible to connect via scpi thru usb or ethernet, and run a diag or control the Arb. It looks like scpi started ok at 11:48

It almost seems as if they created logs onto the flash, forgot to delete them and then that thing can't boot up anymore because it has no space for new logs and/or temporary files to write to anymore, the last task almost seems as if it's trying to start the UI which command is probably programmed into the bootloader but fails due to not being able to make any temporary files anymore. There's an error further up where it says that it can't reserve space for root.

My money is on a corrupted file system - it can't load the UI image. Reflashing would be the only option

After watching other KZfaq repair video's it either needs re-capping or re-flowing with a paint stripper gun...

Does the front panel host a separate cpu? As the main board appears ok, check the front panel pcb...

Does it have to do with the Boot ram reserve? I notice it is 0 bytes. Perhaps they forgot to allocate the ram to the boot process?

Could it be at stuck button in user interface it waiting for to be released?

That 31m stuff with brackets is ansii colour. Do you have a working one (or similar one) to compare? I would for now ignore the FPGA part, even if its not working, it should boot up the UI. and it starts the UI task, but then nothing. My guess would be it tries to start another kind of graphic mode but fails to do so. I have no idea about the architecture of that thing, but maybe you can watch the data going to the LCD module and see that nothing is going there anymore? But not sure if its worth trying, this doesn't seem to be really on the component level, more like faulty processor, faulty ram kind of things. If you have another one, try swapping out the analogue/fpga boards...

find out if theres a factory reset combination?

Had the same issue on my Siglent scope: Siglent logo during boot and no UI, no response to keys. Siglent scopes have workaround for these situations: you rapidly press and release Math button while booting and it gets reset and unstuck. However, this didn't work in my case. It was still under warranty so I RMAd it. They repaired it, no problem.

Make sure the lcd is getting power and data, could be an lcd failure?

My first Siglent "cro" did the same thing when I received it. Sent it back, I was told it had old software, the unit was re-flashed and as been good ever since.

What the name make and the model of the USB to UART interface board you're using?

Looks like a buck converter rather than a linear regulator at 3:33. You can easily spot the diode, the inductor (220 -> 22uH) and the output cap.

I'm waiting for Dave to figure it out and fix it before I post my recommendations, so I can look smart!

It had enough of you, Dave.

there seems to be a ribbon cable connector on the processor board that's missing a ribbon cable. Although that might be for QC testing? Anyhow, the second board doesn't seem to have a ribbon cable connector, but there's a ribbon cable on the processor board going all the way to the front, so if there IS a ribbon missing, then maybe it might go to the front aswell, although I'd guess it to probably be for QC.

Did you try unplugging it for five minutes?

"Invalid parameter" stood out like a sore thumb. Perhaps the onboard storage has experienced a malfunction of sorts? But my guess is that it is trying to communicate with something, and if you wait for a while, you might get a timeout. I never understood if you had taken it apart, but of you have, try reseating some of the obvious communication wires towards, both towards the user interface and the analogue board. A boot log from a working unit could help to pinpoint faults as well.

Front panel control board?

it is saying “task start ui”. it can not started the ui due to a bad software. so, reflashing it can be a simple solution before trying to check everything else. by other hand , can be: mem chips. bad flashram, bad bga cold joints. thoughts?

It could be something to do with the screen/backlight. I have had several monitors that went black and you could see the display by shining a flashlight on the screen. I have one monitor right now that i am thinking about repairing that does the same thing. The screen lights up and gives a image for about 30 sec before going dark.

UBI and UBIFS are Linuxes Flash storage universal bock interface and associated file system. Good stuff and seems happy from the output. The issue seems to be in the application software somewhere. If they were clever, the upgrade process works via the bootloader. re-flash it, worth a try. Or if there is a parameter ram, wipe it.

If it’s possible, I would re-I stall the latest firmware. I’ve had systems that get hit with static or power spikes and they started acting weird. Sometimes that solves it.

could be a break in the FFC cable going to front panel

Looks like the FPGA doesn't get its config file (12:30) correctly, or something in the memory messed with this file (in the display section)...

Could the flash be out of storage and is failing to write to the fs? The unable to write a log jumped out.

Since most scopes have an USB connection it would be nice if they supported a keyboard and included a terminal emulator.

My money is on the filesystem being full. You can see a bunch of errors about how there is no free space on the disk, creating new logs fail, etc. The UI probably needs some free space to put its locks on files etc. Most of the time Linux won't boot with a full FS.

So how did you fix it?

Random guess, a bunch of errors after it started initializing fpga. "Config module error" .... memory issues ?

Did you try buying a new one?

Check the ribbon cable that connects the front panel to the processor card - if not seated correctly at aither end, the keyboard controller may not initialise, resulting in what you see there.

Thanks for sharing 😀👍

Try to get shell access (maybe already working over the Serial port), this looks like a Linux. If you can get access, check "dmesg" for driver (Hardware) errors. If there is nothing interesting, try to kill the main Process (try to find with e.g. "ps aux"), kill it, and start it with "strace XXXX". This shows you, what the process does. Then you see, where it stopps. Post the Output somewhere in the forum or so... Please not as Screen recording ;-)

Maybe an issue of some sort with the front panel board? Maybe the process is starting fine but the front panel isn't initializing or isn't responding properly, so nothing interacts. Maybe try remote controlling it with a PC to see if you can get a signal on the output without having to go through the front panel.

I believe it's a typical Chinese tablet boot loader brick problem. Reflashing it should solve the issue mostly.

"Deader than a dead dingo's donger".... .... Superb!

fial to load boot image of either another co-pro or the FPGA boot image.... Gald my tube operated signal gen doesn´t use any boot image nor any semicon stuff, besides a LED that i put in as a replacement of a funny socketed light bulb.

I would definitely look into the firmware after reseating the connectors.

Based on logs my first quess is it needs reflash, since fpga docent seem to load properly its binary file...

The display window manager isn't initializing. It is unhappy with the display hardware for some reason. Check the cables and connections to the display unit and the keyboard. Initialize to defaults if possible.

Think that maybe the assumption that the splash screen is sent by the processor when it could very well just be handled by the display controller....could be that for some reason, the processor board is just not talking to the display or front panel controller.

Anyone know where we purchase the serial to USB interface board?

Looking a that text maybe it is saying a fpga is not starting up as it should. I would have tried reseating the ribbon connectors just to try to be lucky, but it is probably not the problem. Another great thing would be if there was a software bug you could somehow force a total reboot. Oh maybe there is a firmware update but it would have to actually to do it without dying. Maybe if you disconnect as much of the front panel including display and booted it, it may get over the software bug, and then it may work again next time you put it back together.

There is a service manual available for that thing. At least it descripes the voltages on the test points.

Love the choice aussie slang. :)

hi it looks like a firmware problem if you can make a recovery usb to see if you can get it to boot from that to recover the firmware but before you do that tack all the boards out and check then put it back together and then see if it boots if that

I would say the micro is working. The flat flex cable running to the display/ui looks fuckered. You may want to check out the UI circuit.

Hi, i think to a corrupt firmware, best thing to try is reflash firmware with usb stick if possible or to connect the signal generator to pc via the usb port at the back of the case

I think the ribbon cable between cpu board and front controls needs to be checked. I bet it not fully seated or is inserted a bit off.

Looks like a mem problem, screen will want to start storing its buffer, and dies. Random high energy space particle played pinball in the mem chip!?

does it dhcp?

you held your tongue at the wrong angle.

so expensive an so easy to fail... shame on you Siglent

You stated this unit was torn down? Check ribbon connection to front panel.

I was in the army signal corp, what this thing needs is what we call a "Brogan adjustment".

Yes a firmware upgrade might fix bad boot parameters

You could turn VT-100 terminal emulation on and you could see better the error message after fpga configuration load message... There might be a problem with one of the frontpanel buttons stuck on (tin whisker maybe) or flat flex cable connection lost. (error message: ... line 00155 hwin is 0 )

it's definitely an embedded linux. connect the TX pin and try to log in via serial interface (root/root, something like that). maybe you can check the logs (dmesg, /var/log/...) for more info..?

Try talking to it through the Ethernet. Also try the USB.

I suspect "it's rooted" means something different in Aussie parlance... :)

The big block of text saying "config module error" at the bottom didn't catch your attention? Might be a good place to start.

I think the part you should be paying attention to is the bit where it says: Error[module: ui_task func:ui_if_display_wm line:00155]:: hwin is 0 Config module error: invalid parameter-type:get_type_instance … (It'd be easier to read if you had your Terminal program set to interpret VT-100 escape sequences…) If I had to guess, I'd say there's some non-volatile memory (either battery backed RAM or Flash) that needs to be erased and reset to factory defaults. That's what I'd be looking for - in particular, if there are any onboard batteries, I'd try removing them, waiting a while, then replacing them, on the off chance that that on its own would be sufficient.

I will have my review video up for the SDS1104X-E up within the next couple of days.

Seems like Murphy's Law has a regional office located in the EEVblog Lab.

I'd guess at a hardware fault. The system probably doesn't start the main task because it can't detect something that should be there. My guess would be that it can't see the siggen circuitry on the other board which would lead me to suspect that board interconnect cable.

At 11:44 that image sequence number is a time stamp. It translates to Fri, 24 Jun 2016 12:12:01 GMT. All those "Config module error" messages are a bit suspicious.

CPU failed to download FPGA code. It was right there in the end of the log listing...

The Siglent rust has rusted through the warranty banana.

LOL sounds like a violent man in the police report 0:55

Perhaps the screen is actually booted fine, but there is NO BACKLIGHT!!?? My guess... I just had a Chromebook do this to me.

"you wouldn't touch live heat sinks" .....I did once , there's a mistake I won't ever make again and I also learned to not presume something is not on/live with out testing first.

I wouldn't be surprised if it was the flash chip. I stumble upon more and more of these flipping random bits without any particular reason.

I noticed the fan header has no power on bootup... maybe safety shutdown

Memory issues famsquad

First video with a possibly software issue that i have seen. Otherwise all i see on KZfaq is randomly replacing capacitor and aome voltage regulators. ☺

Perhaps a stuck button on the front panel.

Looks like a file got corrupted. Or it's asking to be widlarized.

The best bang for the buck. Yea ya buy it and it goes bang really big.

I was going to get one.