Hacking the Siglent SDM3055 Bench DMM

[Inovet]

Bonjour! Привет! Hello.

Good health to you! Success in developing interesting internal programs for multimeters SDM3055 (3045).

Good health to you!

[dfc123dfc]

Is the black SDM3055 made with 3D-printed parts? If it's convenient, would you be willing to share the 3D printing files? I'd like to modify my device so that it can be mounted more securely on the rack.

[alexvg]

Hi,

I need to give some information about my project.
I'm actually working on the firmware through multiple aspects.

- The project will be open on GitHub (i'm searching fo the most efficient licence)
- I'm working on a bootable SD-card with new version of Linux
- It is possible that I suggest my project at the FOSDEM 2027 (but I need to have a better fluent english)

Thanks for your support.
Alexia.

[MrNerdHair]

TL;DR: Would someone mind dumping the "oem" partition from the SDM3055 (i.e., the boot logo BMP) for me?

A few years ago, I ran an update on my SDM3055 from a USB drive that I'd loaded with a variety of updates for a number of different devices. One of them was a BIOS update for a Compulab filtet2, which had a "logo.bmp" file. Whichever update I was running on the SDM3055 saw that file and overwrote the multimeter's boot logo.

The logo is the wrong resolution and displays backwards, but the issue has been purely cosmetic and so I've just been ignoring it. I finally spent yesterday reversing the currently-available ADS update files and the USB recovery package looking for the original logo to restore with no luck. I'm confident I can get the original loaded back correctly if I just had the data, and all the updates seem to have support for loading a new logo if it's present in the update package, but the original doesn't seem to be in any of them. (I assume whichever ill-fated update messed up the logo accidentally looked for the logo to update from in the wrong place.)

For those interested, I've attached a picture of my unit's boot screen. All this happened several computers ago, but I've saved the original file that caused the issue in case anyone wants to take a look -- I've attached a PNG for forum display purposes as well as a zip file with the original BMP file.

[GigaJoe]

it seems interpolation of bmp file .
if i do understand . you can create logo.bmp file again with size let say a half of screen resolution , ideally mark corners , to see a position, it you drop a latest firmware to usb , will it updates anyway with the new logo file?  if so it just matter of couples iterations to make correct bmp file, with content whatever you like ...

[tautech]

TL;DR: Would someone mind dumping the "oem" partition from the SDM3055 (i.e., the boot logo BMP) for me?

A few years ago, I ran an update on my SDM3055 from a USB drive that I'd loaded with a variety of updates for a number of different devices. One of them was a BIOS update for a Compulab filtet2, which had a "logo.bmp" file. Whichever update I was running on the SDM3055 saw that file and overwrote the multimeter's boot logo.

The logo is the wrong resolution and displays backwards, but the issue has been purely cosmetic and so I've just been ignoring it. I finally spent yesterday reversing the currently-available ADS update files and the USB recovery package looking for the original logo to restore with no luck. I'm confident I can get the original loaded back correctly if I just had the data, and all the updates seem to have support for loading a new logo if it's present in the update package, but the original doesn't seem to be in any of them. (I assume whichever ill-fated update messed up the logo accidentally looked for the logo to update from in the wrong place.)

For those interested, I've attached a picture of my unit's boot screen. All this happened several computers ago, but I've saved the original file that caused the issue in case anyone wants to take a look -- I've attached a PNG for forum display purposes as well as a zip file with the original BMP file.

Welcome to the forum.

I would first try running the SDM3055 USB recovery package and if all is well proceed through the firmware updates until Version： V1.01.01.27R2 or later.
https://siglent.tawk.help/article/instrument-stuck-at-boot-screen-recovery
https://int.siglent.com/download/firmwares/?ProId=26

[tv84]

Siglent's bitmap format is not a standard Windows .bmp.  Similar but not the same. You won't get there by trial and error.

If I have some time, I'll search my notes.

[MrNerdHair]

The relevant u-boot code from a recent update package is as follows:

Code: [Select]

uplg=echo   =============oem(logo.bmp)===============;if ${loadcmd} ${interface} ${devpart} 0x83000000  ${filedir}/logo.bmp;bmpload ${loadaddr} 0x83000000;then mmc write ${loadaddr} ${oem_start} ${oem_size};mw.b ${loadaddr} 0x0 ${filesize};else setenv up_flag 0;fi;
What's happening here is that the logo.bmp file is being loaded to an extra temporary address (0x83000000), and then the bmpload command extracts the RGB data from it and writes it to the "normal" temporary address (${loadaddr}) used by the other stanzas of the script, and then the data at that temporary address is dumped to the partition. So when my logo got messed up, the bmpload command will have stripped out the BMP file header where the dimensions are stored, explaining the "interlacing."

I don't need the a raw .BMP file, just the contents of the oem partition. (The one which is 5MiB long, starts at 10MiB from the start of the disk, and has GUID 272fa41c-7c22-454e-8bf7-8d6d150de04b.) From what I saw, the USB recovery package doesn't touch this partition, and none of the firmware updates (are supposed to) touch it either, so I'm skeptical that going through @tautech's suggested process will help. I'll try, though.

[tautech]

The relevant u-boot code from a recent update package is as follows:

Code: [Select]

uplg=echo   =============oem(logo.bmp)===============;if ${loadcmd} ${interface} ${devpart} 0x83000000  ${filedir}/logo.bmp;bmpload ${loadaddr} 0x83000000;then mmc write ${loadaddr} ${oem_start} ${oem_size};mw.b ${loadaddr} 0x0 ${filesize};else setenv up_flag 0;fi;
What's happening here is that the logo.bmp file is being loaded to an extra temporary address (0x83000000), and then the bmpload command extracts the RGB data from it and writes it to the "normal" temporary address (${loadaddr}) used by the other stanzas of the script, and then the data at that temporary address is dumped to the partition. So when my logo got messed up, the bmpload command will have stripped out the BMP file header where the dimensions are stored, explaining the "interlacing."

I don't need the a raw .BMP file, just the contents of the oem partition. (The one which is 5MiB long, starts at 10MiB from the start of the disk, and has GUID 272fa41c-7c22-454e-8bf7-8d6d150de04b.) From what I saw, the USB recovery package doesn't touch this partition, and none of the firmware updates (are supposed to) touch it either, so I'm skeptical that going through @tautech's suggested process will help. I'll try, though.

The recovery packages rebuild the OS and may install an older FW version hence the mention to update the firmware after the recovery package has run.
Be sure to follow the instructions regarding USB stick compatibility for the recovery process.

If the DMM operates normally the recovery package should fix any minor SW issues.
Do report the outcome .... 

[MrNerdHair]

So, oddly enough, I can't get the USB recovery package to run. I've tried a 4GiB and an 8GiB stick, tried formatting as FAT32 with both linux (mkfs.vfat -F32) and windows, and also tried using an MBR or not. I can see the drive attached and accessible from the menus once the meter boots, but nothing out of the ordinary seems to happen during boot. (I'm on V1.02.01.28.)

I don't think this will solve my problem even if I can get it working, because this is the u-boot script the recovery package runs:

Code: [Select]

usblogo=echo load logo(logo.bmp) ...... ; if fatload usb 0 0x83000000 logo.bmp; then bmpload 0x82000000 0x83000000; nand erase 0x280000 0x300000; nand write.i 0x82000000 0x280000 0x300000; mw.b 0x82000000 0x0 0x300000; mw.b 0x83000000 0x0 0x300000; fi
usbk=echo load kernel(ro_uImage) ...... ; if fatload usb 0 0x82000000 ro_uImage; then nand erase 0x3080000 0x500000; nand write.i 0x82000000 0x3080000 0x500000; mw.b 0x82000000 0x0 0x500000; fi
usbf=echo load rootfs(rootfs.img) ...... ; if fatload usb 0 0x82000000 rootfs.img; then nand erase 0x580000 0x2b00000; nand write.i 0x82000000 0x0580000 0x1500000; mw.b 0x82000000 0x0 0x1500000; fi
usbf1=echo load firmdata0(firmdata0.img) ...... ; if fatload usb 0 0x82000000 firmdata0.img; then nand erase 0x3680000 0x3200000; nand write.i 0x82000000 0x3680000 0x1500000; mw.b 0x82000000 0x0 0x1500000; fi
usbd=echo load datafs(datafs.img) ...... ; if fatload usb 0 0x82000000 datafs.img; then nand erase 0x9a80000 0x6580000; nand write.i 0x82000000 0x9a80000 0x1500000; mw.b 0x82000000 0x0 0x1500000; fi
usbenvcmd=run usbk;run usblogo; run usbf; run usbf1; run usbd

There's no logo.bmp or firmdata0.img files in the recovery package, so all it can do is restore the kernel, root, and data partitions. (That's good in the sense that it's not overwriting the calibration data, I suppose!)

[BillB]

Not that this is helpful in any way, but seeing the image of the corrupted bitmap reminded me of my 3055s.  I've got two, running the same firmware version 1.01.01.27R2 but at different hardware levels (02-00-00-12-00 and 03-00-00-13-00).  When they first come on, the image is fine, then the older 3055 does as shown in the pic for the remainder of boot, then it's fine after boot.  I don't think it's always been like that, but I can't remember when I first noticed it.  It seemed harmless enough, so I hadn't done anything about it, then forgot until I saw the image in this thread.   

[tv84]

Here an official logo.bmp (480x272). Taken from a SDG.

Try to see if it solves the problem.

[Doctorandus_P]

Interesting to learn this thing runs Linux. It would be nice if you could SSH into it and then run custom measurement scrips.

I once thought of buying this DMM. But I do not have enough depth on my workbench to give it a place. I even thought of sawing the case in two, and putting the two PCB's on top of each other. But that is all a bit too much for buying a brand new instrument.

[tautech]

Interesting to learn this thing runs Linux. It would be nice if you could SSH into it and then run custom measurement scrips.

I once thought of buying this DMM. But I do not have enough depth on my workbench to give it a place. I even thought of sawing the case in two, and putting the two PCB's on top of each other. But that is all a bit too much for buying a brand new instrument.

AFAIK all Siglent instruments run some form of Linux OS and most now have an opensource acknowledgement you can find in their documents folder.
Check the Downloads folder for the programming guides:
https://int.siglent.com/products-document/sdm3055/#navs

These are side vented and made to be stacked.....