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?
Apparently MUI stands for multilingual user interface, it fails to load but the boot process continues. Then on the last line is the UI task starts but is stuck because of the previous error. The firmware is on Siglent website, one bug fix from 2016 is "A bug in file system could cause the generator never startup". But it can't be updated if it does not start...
Might be possible to boot off the SD card with the firmware image, as the bootloader likely will look first on the SD card to see if present, then will look for the filesystem on the card, read directory and then look for the first .bin file and flash it into the application space. Unless you get the right image though it will turn it into a very fancy doorstop, as the loader probably does zero sanity checking on the file, and writes the entire flash system at once, probably overwriting itself in the process anyway but still being fine as it is running the flasher in RAM on the micro, then executing a restart or simply a splash complete screen to the STDIO in the file system.
The leading m is part of the color escape sequence. The module is 'ui_task' and the function is 'ui_if_display_wm'. But yeah, it appears that the handle to the display is a problem. I see further down that there's a message about detecting an LCD... perhaps it is getting slow to initialize?
Some times when I see this kinda thing is when its waiting for that USB device to enumerate and come online then you see that at the end of all of those and once found it continues onto UI. Or it checked to see if certain options were installed and didnt find them responding to certain I/O requests and we see the one USB device come up, which I would assume is the front panel keypads its seeing, or the screen if its a touch based system, I didnt see the first tear down video on this model.
fpga_init_load_fpga_file_to_fpga::str_path = /usr/bin/siglent/config/fpga/fpga.bin SEEMS LIKE A GOOD PLACE TO START!!!! Since the FPGA needs to be programmed for what it needs become and to and have its circuits literally laid out to become a Signal Generator Processor!!!!
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.
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?
Yeah, my head was going there too, corrupted FPGA file, I reckon as it boots it'd be possible to replace it though, wonder if you can get to a command prompt of some sort...
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.
Oh and since that thing has a serial interface you may be able to flash the firmware onto it again over it, depends if they implemented that function or not. I remember when I had to rescue a broken OpenWRT Router that way, took hours to transfer that image via serial...
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 ;-)
Just find out that there is telnet running - ua-cam.com/video/-HcggjLN1LE/v-deo.html Connect the generator to your network and figure out what IP it gets. Then use PuTTY to telnet into it as in the video I linked above. If this works we are going to have a lot of Linux hacking fun here :)
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.
Attach a keyboard to the USB port and try Ctl Alt F1 to get a terminal screen? I doubt that it is a linux os though - they would have had to recognise open source licenses.
Benny Banger It’s very likely a BSD, then. That boot output and the filesystem layout seem to suggest it very loudly. I’m pretty sure the only way to diagnose it at this point is to get some sort of CLI. When things die suddenly like this and then exhibit uniform behavior afterwards, it’s almost always either a software configuration problem or a completely failed component that the software can no longer use.
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.
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.
Mini DK#9 These "Errors" are pretty common even in devices that are working without any issues. You can see them in other Teardown videos of scopes and so 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.
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 agree. It appears the window manager is failing to start due to some problem (and that error is probably in blinking red to get your attention if you had ansi color on lol). Check your cables going to the screen and keyboard. Try to init to defaults.
Kinda ignorant of Dave to say "Where?" and then not even thank you when you linked him directly to the manual. I'll do it for him: Thanks for taking the time to help.
Download the firmware from their website. Write it to the root folder of a FAT formatted SD card. Power off. Put that SD card in the reader. Power on. Go get breakfast. It should be running fine when you come back. It might lose calibration data, so check it with a known good frequency counter. It will probably lose Arbitrary waveform memory during the update. Such is life. Happy NY!
Looks like a typical software error? Try to update/upgrade the firmware. There is also "HWIN is 0" (HWIN could be Hardware Init), so maybe there is a broken cable?
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.
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?
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.
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
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
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.
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.
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..?
I'm gonna agree with everyone here that this machine is 1) Definitely running Linux of some sort as it explicitly states that it's running a file system known as UBIFS, which is a Nokia FS meant for raw flash applications. Looking around PEBS are Physical Erase Blocks and LEBS are Logical Erase Blocks. There are several lines here that seems to indicate that there are none available, meaning that there simply isn't enough free disk space to boot or decompress. Then you get all those errors at the bottom that might be caused by trying to access a value that was supposed to be on the loaded file system, can't find it and fails? Sounds like you should try to flash it with the SD card or send it back to them, definitely a software failure on their part.
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.
possibility: half-assed firmware-update has put it's boot-sequence between 2 distinct firmware-revisions. (my first digital camera was bricked by this kind of stupidity ... necessitating a new firmware-chip if it were to be operational again)
There are tons of lines with "Config module error: invalid parameter-type: get_type_instance" error messages in there, so that's probably a corrupted firmware. Maybe you've had the luck that a neutrino passing through your flash memory didn't just pass through without hitting anything, but instead it flipped the right bit to make it stop working ;) I'd say: Get the original firmware, reflash it (either over the serial terminal or with a microSD card), and it'll work fine again. Until the flash memory dies completely, that is...
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.
Maybe you can dump the firmware update image into a microSD card (maybe need some work in Linux to unpack UBIFS into ext4) and insert it into the microSD card slot to boot that way.
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.
"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.
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.
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 )
"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.
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...
This is actually good advice. I have terminal logs of many of my devices when working properly. If you look at the terminal only when it fails, it's hard to figure out what is an actual error and what is not. Many devices reports lots of errors in the logs even when they're running just fine....
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.
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.
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.
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
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.
First video with a possibly software issue that i have seen. Otherwise all i see on UA-cam is randomly replacing capacitor and aome voltage regulators. ☺
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.
do you have access to firmware download? maybe try reflashing it?
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?
Apparently MUI stands for multilingual user interface, it fails to load but the boot process continues.
Then on the last line is the UI task starts but is stuck because of the previous error.
The firmware is on Siglent website, one bug fix from 2016 is "A bug in file system could cause the generator never startup".
But it can't be updated if it does not start...
The pessimist in me reads "A Bug in the filesystem" as "we forgot rotate system logs and ran out of space". I wonder if telnet is running...
Might be possible to boot off the SD card with the firmware image, as the bootloader likely will look first on the SD card to see if present, then will look for the filesystem on the card, read directory and then look for the first .bin file and flash it into the application space. Unless you get the right image though it will turn it into a very fancy doorstop, as the loader probably does zero sanity checking on the file, and writes the entire flash system at once, probably overwriting itself in the process anyway but still being fine as it is running the flasher in RAM on the micro, then executing a restart or simply a splash complete screen to the STDIO in the file system.
Ad telnet - yes it is! It can be used to hack the 40MHz version into this 120MHz one. ua-cam.com/video/-HcggjLN1LE/v-deo.html
The leading m is part of the color escape sequence. The module is 'ui_task' and the function is 'ui_if_display_wm'. But yeah, it appears that the handle to the display is a problem. I see further down that there's a message about detecting an LCD... perhaps it is getting slow to initialize?
This isn't EEVBlog 2, material post it on main for all to see!
A bunch of "module config error: invalid parameter" messages don't look like a clue?
I was screaming at the monitor myself :)
Some times when I see this kinda thing is when its waiting for that USB device to enumerate and come online then you see that at the end of all of those and once found it continues onto UI. Or it checked to see if certain options were installed and didnt find them responding to certain I/O requests and we see the one USB device come up, which I would assume is the front panel keypads its seeing, or the screen if its a touch based system, I didnt see the first tear down video on this model.
Yeah, it is literally right under his nose! Looks like the FPGA or the memory holding it's software is toast.
fpga_init_load_fpga_file_to_fpga::str_path = /usr/bin/siglent/config/fpga/fpga.bin SEEMS LIKE A GOOD PLACE TO START!!!! Since the FPGA needs to be programmed for what it needs become and to and have its circuits literally laid out to become a Signal Generator Processor!!!!
Everything from "Since the FPGA needs to be programmed" onward is confusing as hell. What were you trying to say here?
SO8 with massive inductor, diode and capacitor? Yeah, probably a linear reg!
SaNjA2659 was looking for this comment
Funny :)
He meant linear, as he was talking about how we did not have to worry about ripple because of that.
that "inductor" is a beeper
MattOGormanSmith Not at all. We are talking about the cubical component with "220" written on it.
This calls for a diagnosis and repair video on the main channel!
agreed
But I think that's to much software for an electronics blog ;)
My money is on a corrupted file system - it can't load the UI image. Reflashing would be the only option
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.
After watching other UA-cam repair video's it either needs re-capping or re-flowing with a paint stripper gun...
Mike James rehot CPU bruh :p
Do you repair Macbook Airs for NYC schools?
Deader than a Dead Dingo's Donger... wow, as a Canadian that is definitely not something I've ever heard hahahahaha.
I believe the translation is "Deader than a deceased moose's penis". Could be wrong though
Or deader than a dodo.
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?
No hard reset that I could find. I'll have to ask them.
Yeah, my head was going there too, corrupted FPGA file, I reckon as it boots it'd be possible to replace it though, wonder if you can get to a command prompt of some sort...
Hold down power button for 30 seconds? Wild guess.
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.
Oh and since that thing has a serial interface you may be able to flash the firmware onto it again over it, depends if they implemented that function or not. I remember when I had to rescue a broken OpenWRT Router that way, took hours to transfer that image via serial...
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 ;-)
Did you try unplugging it for five minutes?
Rt
Just find out that there is telnet running - ua-cam.com/video/-HcggjLN1LE/v-deo.html
Connect the generator to your network and figure out what IP it gets. Then use PuTTY to telnet into it as in the video I linked above.
If this works we are going to have a lot of Linux hacking fun here :)
This looks like the most promising troubleshooting interface. Hand it over to David for 30 minutes.
you held your tongue at the wrong angle.
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
I remembered Shahriar used SCPI in one of his repair videos
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.
Easy. Chkdsk
fsck, more likely.
Attach a keyboard to the USB port and try Ctl Alt F1 to get a terminal screen? I doubt that it is a linux os though - they would have had to recognise open source licenses.
Benny Banger It’s very likely a BSD, then. That boot output and the filesystem layout seem to suggest it very loudly. I’m pretty sure the only way to diagnose it at this point is to get some sort of CLI. When things die suddenly like this and then exhibit uniform behavior afterwards, it’s almost always either a software configuration problem or a completely failed component that the software can no longer use.
I think we agree then Ryan - Ctl Alt F1 selects the first terminal in Linux.
LOL ...boot in safe mode
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.
Hey, what is this uart level converter board? Brand? Where to buy? Thank you
so expensive an so easy to fail... shame on you Siglent
It had enough of you, Dave.
What are the details on that serial interface board? I would like to get one.
Since you did a tear-down before, try to reseat the flatflex cable for the front controls and display.
Where is the enter button on this thing? I got one and I can’t figure out how to enter a frequency.
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.
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.
The big block of text saying "config module error" at the bottom didn't catch your attention? Might be a good place to start.
Mini DK#9 These "Errors" are pretty common even in devices that are working without any issues. You can see them in other Teardown videos of scopes and so on.
I suspect "it's rooted" means something different in Aussie parlance... :)
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 most scopes have an USB connection it would be nice if they supported a keyboard and included a terminal emulator.
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 agree. It appears the window manager is failing to start due to some problem (and that error is probably in blinking red to get your attention if you had ansi color on lol). Check your cables going to the screen and keyboard. Try to init to defaults.
any chance you could add a link to that serial board?
I would not like bring any of my devices to this service center
LOL sounds like a violent man in the police report 0:55
Firmware update fixed it...
ua-cam.com/video/tM2j9zuBiRQ/v-deo.html
Try talking to it through the Ethernet. Also try the USB.
I believe it's a typical Chinese tablet boot loader brick problem. Reflashing it should solve the issue mostly.
What the name make and the model of the USB to UART interface board you're using?
looks like it's this one: www.mario001.de/mikrocontroller/2014/08/09/usb-uart-interface/
There is a service manual available for that thing. At least it descripes the voltages on the test points.
Where?
www.siglentamerica.com/USA_website_2014/Documents/service_manual/SDG2000X_ServiceManual_SM0202X-E01A.pdf
Good job
Kinda ignorant of Dave to say "Where?" and then not even thank you when you linked him directly to the manual. I'll do it for him: Thanks for taking the time to help.
www.batronix.com/files/Siglent/Funktionsgeneratoren/SDG1000/SDG-SCPI-Command(EN).pdf
Perhaps the screen is actually booted fine, but there is NO BACKLIGHT!!?? My guess... I just had a Chromebook do this to me.
Anyone know where we purchase the serial to USB interface board?
I too would like to know where to buy the serial interface board
Download the firmware from their website. Write it to the root folder of a FAT formatted SD card. Power off. Put that SD card in the reader. Power on. Go get breakfast. It should be running fine when you come back. It might lose calibration data, so check it with a known good frequency counter. It will probably lose Arbitrary waveform memory during the update. Such is life. Happy NY!
Looks like a typical software error? Try to update/upgrade the firmware.
There is also "HWIN is 0" (HWIN could be Hardware Init), so maybe there is a broken cable?
No Tektronix, HP or Fluke gear ever failed. Given it's purchased from the correct distributor maybe it go back under warranty.
E-waste.
Made in China
You can download the service manual at:
www.siglentamerica.com/USA_website_2014/Documents/service_manual/SDG2000X_ServiceManual_SM0202X-E01A.pdf
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.
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?
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.
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
could be a break in the FFC cable going to front panel
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 was in the army signal corp, what this thing needs is what we call a "Brogan adjustment".
Sounds to me that the emmc is at fault you can try flashing it again but i think its dead sorry dave..
the rock You would not use ubifs on an e.MMC, ubi is for unmanaged nand and nor.
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.
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.
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.
The Siglent rust has rusted through the warranty banana.
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..?
I'm gonna agree with everyone here that this machine is 1) Definitely running Linux of some sort as it explicitly states that it's running a file system known as UBIFS, which is a Nokia FS meant for raw flash applications. Looking around PEBS are Physical Erase Blocks and LEBS are Logical Erase Blocks. There are several lines here that seems to indicate that there are none available, meaning that there simply isn't enough free disk space to boot or decompress. Then you get all those errors at the bottom that might be caused by trying to access a value that was supposed to be on the loaded file system, can't find it and fails? Sounds like you should try to flash it with the SD card or send it back to them, definitely a software failure on their part.
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.
The ribbon cables probably aren't seated correctly or are broken.
Edit: Or one of them is in backwards......
possibility: half-assed firmware-update has put it's boot-sequence between 2 distinct firmware-revisions. (my first digital camera was bricked by this kind of stupidity ... necessitating a new firmware-chip if it were to be operational again)
There are tons of lines with "Config module error: invalid parameter-type: get_type_instance" error messages in there, so that's probably a corrupted firmware. Maybe you've had the luck that a neutrino passing through your flash memory didn't just pass through without hitting anything, but instead it flipped the right bit to make it stop working ;)
I'd say: Get the original firmware, reflash it (either over the serial terminal or with a microSD card), and it'll work fine again. Until the flash memory dies completely, that is...
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.
Maybe you can dump the firmware update image into a microSD card (maybe need some work in Linux to unpack UBIFS into ext4) and insert it into the microSD card slot to boot that way.
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.
"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.
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.
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 )
"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.
I know its less fun but ask your friend Eric Qin for a free replacement :)
Does the front panel host a separate cpu? As the main board appears ok, check the front panel pcb...
The problem you had on the screen !!! ( Config module error Invaild parameter-type get_type_instance ) Update the Firmware !
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...
This is actually good advice. I have terminal logs of many of my devices when working properly. If you look at the terminal only when it fails, it's hard to figure out what is an actual error and what is not. Many devices reports lots of errors in the logs even when they're running just fine....
Remco Stoutjesdijk Yes, I've seen many normal boot logs with lots of a "errors", so lots of red herrings no doubt.
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.
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.
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.
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.
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!?
Seems like Murphy's Law has a regional office located in the EEVblog Lab.
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)...
jajajajajajajajjajaj¡¡¡¡ mc fly mcfly ....jajajaj genius.
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
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.
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?
First video with a possibly software issue that i have seen. Otherwise all i see on UA-cam is randomly replacing capacitor and aome voltage regulators. ☺
Random guess, a bunch of errors after it started initializing fpga. "Config module error" .... memory issues ?
Memory issues famsquad
That is a corrupt firmware if I ever seen one probably needs a reflash using that as card slot
You stated this unit was torn down? Check ribbon connection to front panel.
Looks like a file got corrupted. Or it's asking to be widlarized.
CPU failed to download FPGA code. It was right there in the end of the log listing...
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.
Based on logs my first quess is it needs reflash, since fpga docent seem to load properly its binary file...
Send it to the signal path for repair or
I'll give you 5 bucks for it you pay shipping