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.
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?
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.
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!!!!
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.
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...
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.
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...
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.
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
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?
"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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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....
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 ;-)
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.
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..?
"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 )
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.
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?
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.
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.
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
First video with a possibly software issue that i have seen. Otherwise all i see on TH-cam is randomly replacing capacitor and aome voltage regulators. ☺
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
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.
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)
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.
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!
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.
This isn't EEVBlog 2, material post it on main for all to see!
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.
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. th-cam.com/video/-HcggjLN1LE/w-d-xo.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?
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 ;)
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.
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?
After watching other TH-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?
Since you did a tear-down before, try to reseat the flatflex cable for the front controls and display.
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.
My money is on a corrupted file system - it can't load the UI image. Reflashing would be the only option
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.
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.
I'm waiting for Dave to figure it out and fix it before I post my recommendations, so I can look smart!
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.
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...
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.
What are the details on that serial interface board? I would like to get one.
"Deader than a dead dingo's donger".... .... Superb!
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.
Check the output to see if it's generating a signal. Is there a button on the front to switch the output on?
Hey, what is this uart level converter board? Brand? Where to buy? Thank you
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
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?
"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.
It had enough of you, Dave.
Does the front panel host a separate cpu? As the main board appears ok, check the front panel pcb...
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.
LOL sounds like a violent man in the police report 0:55
Did you try unplugging it for five minutes?
Rt
I was in the army signal corp, what this thing needs is what we call a "Brogan adjustment".
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
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?
I believe it's a typical Chinese tablet boot loader brick problem. Reflashing it should solve the issue mostly.
any chance you could add a link to that serial board?
Since most scopes have an USB connection it would be nice if they supported a keyboard and included a terminal emulator.
Thanks for sharing 😀👍
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.
Love the choice aussie slang. :)
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.
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.
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.
I would definitely look into the firmware after reseating the connectors.
you held your tongue at the wrong angle.
Seems like Murphy's Law has a regional office located in the EEVblog Lab.
so expensive an so easy to fail... shame on you Siglent
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.
Could it be at stuck button in user interface it waiting for to be released?
I will have my review video up for the SDS1104X-E up within the next couple of days.
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 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.
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
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.
could be a break in the FFC cable going to front panel
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.
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.
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 ;-)
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/
Make sure the lcd is getting power and data, could be an lcd failure?
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.
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..?
"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.
find out if theres a factory reset combination?
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.
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.
Front panel control board?
Random guess, a bunch of errors after it started initializing fpga. "Config module error" .... memory issues ?
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 )
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.
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.
I suspect "it's rooted" means something different in Aussie parlance... :)
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?
Yes a firmware upgrade might fix bad boot parameters
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.
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.
Based on logs my first quess is it needs reflash, since fpga docent seem to load properly its binary file...
The best bang for the buck. Yea ya buy it and it goes bang really big.
Try talking to it through the Ethernet. Also try the USB.
So how did you fix it?
Could the flash be out of storage and is failing to write to the fs? The unable to write a log jumped out.
Could not create log file: file exists -- The last two words are important.
The Siglent rust has rusted through the warranty banana.
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!?
You stated this unit was torn down? Check ribbon connection 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
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)...
First video with a possibly software issue that i have seen. Otherwise all i see on TH-cam is randomly replacing capacitor and aome voltage regulators. ☺
Perhaps the screen is actually booted fine, but there is NO BACKLIGHT!!?? My guess... I just had a Chromebook do this to me.
Memory issues famsquad
Did you try buying a new one?
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
The ribbon cables probably aren't seated correctly or are broken.
Edit: Or one of them is in backwards......
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.
Perhaps a stuck button on 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)
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.
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!
I noticed the fan header has no power on bootup... maybe safety shutdown
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.