The Siglent SDG2042X Thread

[Vit G]

From the SD card recovery instructions, please see below pic with the location of the SD card holder.
It is likely the footprint is still there to be populated with a new SD card holder.

Hi!
 No. 05-00-xx-xx-xx hardware fundamentally different from the previous one. everything is done differently there.

[tautech]

Nobody finds it weird how it's even possible to install a firmware that is too old to support the hardware? Preventing this must be trivial. 

No but I do find it weird someone would fuck with roll back firmware to the earliest public release and not read the 2.01.01.17R5 release notes that say this:
NOTE: After being updated to this release, the generator cannot be backward to previous releases any more

 

[rf-loop]

Hello! I have a 2042x after trying to downgrade the firmware (16R2) stopped loading. On the screen only a Logo presents. how to bring it back to life now? Help please!
I saw on Dave's video how to restore 2122x using sd card. Where can I get the files for it for the 2042x model? perhaps this would help me.

UPD
My 2042X is 05-00-00-46-00 hw version. Dont have SD slot on board. it seems i need USB recover stick ?

UPD2
After about 10 minutes, a message appeared on the screen:  "No external clock source!".
 I connected an external 10MHz from my HP8920A and repeated the power-up procedure again. It did not help. The message reappeared after 10 min.

 The HL1 LED near CPU does not light up.

UPD3
 Thanks  for Siglent support. I make restore USB stick but this not helped .  I see some numerous errors in the bootlog. I am attaching it here.
 Need opinion from more experienced people  :'(

Can you tell where from you get this FW version 16R2 and why. Least Siglent do not share this version anymore.  Oldest shared is 17R5. Because can not downgrade more backwards from this or more new versions.

[tautech]

Can you tell where from you get this FW version 16R2 and why. Least Siglent do not share this version anymore.  Oldest shared is 17R5. Because can not downgrade more backwards from this or more new versions.

Older are available on HQ website:
https://int.siglent.com/download/firmwares/?ProId=5

[thinkfat]

Nobody finds it weird how it's even possible to install a firmware that is too old to support the hardware? Preventing this must be trivial. 

No but I do find it weird someone would fuck with roll back firmware to the earliest public release and not read the 2.01.01.17R5 release notes that say this:
NOTE: After being updated to this release, the generator cannot be backward to previous releases any more

 

I would read (and implement) that as "After you have installed 2.01.01.17R5, you CAN NOT downgrade any more". I would not assume "You MUST NOT downgrade any more or you will brick your device".
Quite honestly, Siglent have eff'd up here big time. The way out is not to tell the customer that he's stupid.

[Vit G]

Hi!
I found something interesting while reading UART. Here is a snippet of the USB initialization dump. With the USB stick inserted, I see this:

Code: [Select]

======RESET USB======
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   ULPI request timed out
zynq ULPI viewport init failed
lowlevel init failed
       scanning usb for storage devices... 1 Storage Device(s) found
Copying Linux from USB to RAM...


reading boot_uImage
** Unable to read file boot_uImage **
** Unrecognized filesystem type **
reading
.txt
** Unable to read file sdg6000x_udiskEnv.txt **
** Invalid partition 2 **
** Bad device usb 1 **
** Bad device usb 1 **
** Bad device usb 1 **
** Bad device usb 2 **
** Bad device usb 2 **
** Bad device usb 2 **
** Bad device usb 3 **
** Bad device usb 3 **
** Bad device usb 3 **
Copying Linux from NAND flash to RAM...

It's a mystery to me why the device starts looking for download files from the sdg6000? This is apparently some kind of rudiment in the firmware remaining in it.

I have a 2042x recovery file from the SD card. it has a file uEnv.txt. I just for the sake of interest changed its name to what the device asks for : sdg6000x_udiskEnv.txt. And now I see it:

Code: [Select]

======RESET USB======
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   ULPI request timed out
zynq ULPI viewport init failed
lowlevel init failed
       scanning usb for storage devices... 1 Storage Device(s) found
Copying Linux from USB to RAM...
reading boot_uImage
** Unable to read file boot_uImage **
** Unrecognized filesystem type **
reading sdg6000x_udiskEnv.txt
2292 bytes read in 22 ms (101.6 KiB/s)
Loaded environment from sdg6000x_udiskEnv.txt
Importing environment from SD or UDISK ...
Running uenvcmd ...

But the download apparently stops there. nothing else happens.
I have an idea that a properly prepared usb media with the right files can bring the device to life. but I don't know what he wants.
1.The important thing is that usb port still works!
2. which of the files on the usb stick should be renamed to boot_uImage?

 UPD:   UART keyboard is also working!

 result of help command:

Code: [Select]

zynq-uboot> Hit any key to stop autoboot:  0
Unknown command 'Hit' - try 'help'
zynq-uboot> zynq-uboot>
Unknown command 'zynq-uboot>' - try 'help'
zynq-uboot> nknown command 'ry 'help'
> zynq-uboot> help
> ?       - alias for 'help'
> base    - print or set address offset
> bdinfo  - print Board Info structure
> boot    - boot default, i.e., run 'bootcmd'
> bootd   - boot default, i.e., run 'bootcmd'
> bootelf - Boot from an ELF image in memory
> bootm   - boot application image from memory
> bootp   - boot image via network using BOOTP/TFTP protocol
> bootvx  - Boot vxWorks from an ELF image
> bootz   - boot Linux zImage image from memory
> clk     - CLK sub-system
> cmp     - memory compare
> coninfo - print console devices and information
> cp      - memorycopy
> crc32   - checksum calculation
> dcache  - enle or disable data cae
> dfu     - Device Firmware Upgde
> dhcp    - boot image via networksing DHCP/TFTP protocol
> echo    echo args to console
> editenv - edit environment variableenv     - environment handlincommands
> exit    - exit script
> ext2load- load binary file from a Ext2 filsystem
> ext2ls  - list les in a directory (default /)
> ext4load- load binry file from a Ext4 filesystem
> ext4ls  - list les in a directory (default /)
> ext4write- create  file in the root directory
> false   - do nothi, unsuccessfully
> fatinfo - print information aut filesystem
> fatload - load binaryfile from a dos filesystem
> fatls   - list fes in a directory (default /)
> fatwrite- write fie into a dos filesystem
> fdt     - flattened dece tree utility commands
> fpga    - loadablFPGA image support
> go      - start application t address 'addr'
> help    - print comnd description/usage
> i2c     - I2C sub-systemcache  - enable or disable instruction cche
> iminfo  - print header information for application image
> imxtrac- extract a part of a multi-image
> itest   - return true/flse on integer compare
> loadb   - load biny file over serial line (kermit mode)
> loads   load S-Record file over serial line
> loadx   - load binar file over serial line (xmodem mode)
> loady  - load binary file over serial line (ymodem mode)
> loop    infinite loop on address range
> md      - memory display
> d5check- check MD5 message digest
> mdio  - MDIO utility commands
> i     - MII utility commands
> mm    - memory modify (auto-incremeing address)
> mmc     - MMC susystem
> mmcinfo - display MMC info
> mw      - memoy write (fill)
> nand    NAND sub-system
> nboot   - b from NAND device
> nfs     - bt image via network usinNFS protocol
> nm      - memoryodify (constant address)
> ping    - send ICMP ECH_REQUEST to network host
> printenv- print vironment variables
> reset   - Perform RESET of t CPU
> resetusb- reset usb
> run     - rn commands in an environment varile
> saveenv - save enonment variables to persistent storage
> setenv   set environment variables
> showup  - turn on led to showthat update has finishd
> showvar - pnt local hushshell variables
> sleep   - delay executiofor some time
> source  - run script from emory
> spl     - SPL configuration
> test  - minimal test like /bin/sh
> tfboot- boot image via networksing TFTP protocol
> tftpput - TFTP t command, for uploading files to a server
> thordon- TIZEN "THOR" downloader
> true    - do nothing, successfuy
> usb     - USB sub-system
> usbboo - boot from USB device
> version -rint monitor, compiler anlinker version
> zynq-uboot>
 

 UPD2

 Wow. i can switch on DHCP!

Code: [Select]

zynq-uboot> dhcp
Gem.e000b000:30 is connected to Gem.e000b000.  Reconnecting to Gem.e000b000
Gem.e000b000 Waiting for PHY auto negotiation to complete.... done
BOOTP broadcast 1
DHCP client bound to address 192.168.1.176
*** Warning: no boot file name; using 'C0A801B0.img'
Using Gem.e000b000 device
TFTP from server 10.11.0.30; our IP address is 192.168.1.176; sending through gateway 192.168.1.1
Filename 'C0A801B0.img'.
Load address: 0x0
Loading: T T T T T T T T T T
Retry count exceeded; starting again

i think i have chance!  need help!

[thinkfat]

It if you extracted the "uImage" from a more recent firmware update file, this could be used as boot file for TFTP. But this will only get you the linux kernel and maybe an initial RAM root filesystem (aka "initrd". However, with all other options exhausted, this is what might get you a step further.

Maybe you can use some of content of the USB recovery image?

BTW - the reason this thing believes it is "SDG6000x" - they might share the same application processor platform. I have looked around but didn't find a tear down of the SDG6000x that looked under the heatsink. Shariar from The Signal Path also only glossed over it. But as far as I understood, Siglent seems to consolidate their hardware platforms and we have seen the Zynq-7000 SoC pop up in quite a number of devices from them. Like, the 05-xxx SDG2000X, the SDS2000X scopes, and possibly the SDG6000X also meanwhile got a hardware "facelift" to use this platform.

[Vit G]

  Yes.  I also came to this idea. And now I would like to know if it is possible that the recovery disk for HW version 05-xx-xx-xx should contain other files that are not compatible with the old recovery disk. in other words, my bootloader actually works, but I don't give it the files it needs to recover. Is it possible to ask the support service to clarify this case? There is an opinion that the recovery disk for version 05-00 should be different, not the same as for older HW versions?

[TimLamborn]

Hey - has anyone had any success with sending waveforms via SCPI?

Your supposed to send the waveform file using binary bytes.
Given the following points: [0x0000, 0x0000, 0x4000, 0x4000]
You send the following command:"C1:WVDT WVNM,wave_name,WAVEDATA,\x00\x00\x00\x00\x00\x40\x00\x40\x00" (I am using python notation to describe literal bytes).

However - when sending the following wave: [0x0000, 0x0000, 0x400a, 0x4000] - the resulting binary string has a newline character in it (0x0A)!
This does exactly what you'd expect - ends the command causing the waveform to be truncated.

Usually this is solved by specifying the length, using an escape sequence, or encoding the bytes into something like hex pairs.
Does anyone know how this is supposed to work for the SGD2000X?

[bicycleguy]

You have to encode it.  See these examples:
https://siglentna.com/application-notes/sdg2000x-series/

[TimLamborn]

I'm following their example here:
https://siglentna.com/application-note/programming-example-sdg-waveform-creation-with-python-and-sockets-no-visa/

Running this example directly seems to have the same problem.
I get the expected output initially, but as soon as I introduce a 0x0A anywhere in wave_points, then the written wave gets truncated.

For example:
wave_points = [0x0000, 0x0000, 0x0000, 0x0000, 0x0a40, 0x0040, 0x0040, 0x0040]
wave1.bin then contains (hex): 00 00 00 00 00 00 00 00 0a40 00 40 00 40 00 40

data.decode('latin1') on line 75 doesn't actually do much here - merely transform the bytes into a string. The 0x0a just becomes a '\n'.

Have I missed something obvious?

[bicycleguy]

Don't remember where I googled this but to work with Python3:
replace   binascii.a2b_hex(b)  with:  binascii.unhexlify(b)

and maybe your issue is in the example add:  ,encoding='latin1'
like this:
SocketSend(s,"C1:WVDT WVNM,wave1,FREQ,2000.0,AMPL,3.0,OFST,0.0,PHASE,0.0,WAVEDATA,%s"%(data),encoding='latin1')       

[tautech]

I'm following their example here:
https://siglentna.com/application-note/programming-example-sdg-waveform-creation-with-python-and-sockets-no-visa/

Running this example directly seems to have the same problem.
I get the expected output initially, but as soon as I introduce a 0x0A anywhere in wave_points, then the written wave gets truncated.

For example:
wave_points = [0x0000, 0x0000, 0x0000, 0x0000, 0x0a40, 0x0040, 0x0040, 0x0040]
wave1.bin then contains (hex): 00 00 00 00 00 00 00 00 0a40 00 40 00 40 00 40

data.decode('latin1') on line 75 doesn't actually do much here - merely transform the bytes into a string. The 0x0a just becomes a '\n'.

Have I missed something obvious?

Tim, I'll make contact by email with some stuff.

[JDubU]

I have hardware version 02-01-00-40-00.
I am not able to update firmware to 2.01.01.37R3.  Gets mostly through the update and then briefly shows "Update Failed" before going back to file browser.
Flash drive is recognized properly and I can reliably upgrade/downgrade from it, without problem, between firmware versions 2.01.01.35R3B2, 2.01.01.35R3B1 and 2.01.01.23R8.

I notice that the new 2.01.01.37R3 file is more than twice the size of the earlier ones (~39MB vs ~15MB).  I deleted all user files from the C: drive and the file manager shows it's capacity as 397B/85M.  Also tried upgrading from the various older firmware versions directly to 37R3 without success.

Any ideas?

[Vit G]

Most likely, firmware 37R3 was made for the 05-xx-xx-xx-xx board and will not work on others, just like earlier firmware will not work on 05-xx... It was necessary to give this device a new index so that there would be no confusion. Also I can't use the recovery disk because it doesn't fit 05-xx HW and I can't explain it to the support team. I will have to wait a while until they guess to make a new recovery disk and explain to users that these are completely different devices with the same name 

[tv84]

I notice that the new 2.01.01.37R3 file is more than twice the size of the earlier ones (~39MB vs ~15MB).  I deleted all user files from the C: drive and the file manager shows it's capacity as 397B/85M.  Also tried upgrading from the various older firmware versions directly to 37R3 without success.

The new FW has twice the size because the same file contains the necessary files to both HW configurations now in use.

It was necessary to give this device a new index so that there would be no confusion.

They could have done that but it would make people think that the device is "totally different". They decide which files to flash in the update script, depending on the device's HW.

It should work OK.

Maybe, as you say, tautech doesnt yet have the recovery disk for the new HW.

See also here.

[Vit G]

I hope that the problem with the recovery disk will be resolved soon. However, I was alarmed why JDubU could not update the FW ?

See also here.

To: tv84
 Thanks! This is very interesting info.

[Vit G]

 Good news!
 Siglent support finally figured out my problem and sent a recovery disk with 37R3 firmware. My SDG came to life! 
 And the bad news: the methods of hacking described on the forum do not work with this hardware 

[blurpy]

Good news!
 Siglent support finally figured out my problem and sent a recovery disk with 37R3 firmware. My SDG came to life! 
 And the bad news: the methods of hacking described on the forum do not work with this hardware 

Excellent!

Which guide did you follow?

[Vit G]

It didn't need guidance. I just connected the usb stick with restore files to the SDG and turned it on. It did it all by itself

[blurpy]

Sorry, I was unspecific. I meant which guide did not work for hacking the new hardware?

[Vit G]

https://www.eevblog.com/forum/testgear/siglent-sdg2042x-hack-door-closed/msg4018144/#msg4018144
and
https://www.eevblog.com/forum/testgear/siglent-sdg2042x-hack-door-closed/msg4112236/#msg4112236

Because access via SCPI is now impossible to get even using hack by   telnet_SDG2000X.ADS file   
I did everything according to the instructions but SDG does not accept commands

[blurpy]

I would be extremely surprised if Siglent disabled SCPI support on the new hardware. I'm guessing you made a mistake somewhere in following the guide. The ADS should not be necessary.

[Vit G]

No, the normal SCPI control commands are most likely available. Commands that interfere with the file system are not available, I think.
I'm not familiar with SCPI. SDG accepted the *IDN? command, but the MD5 and MCBD commands remained without reaction. May be I was doing something wrong.

[blurpy]

You do not need to interfere with the file system. Just follow the guide you linked to where you generate a license code