Siglent SSA3000X and SSA3000X-Plus Spectrum Analyzers

[gussy]

(Not actually a new user, but my account form 2012 doesn't exist anymore. It's been a while since I logged in, perhaps accounts got cleared out?)

I was hoping I could post here with a nice success story, but I'm not quite there yet.

Recently acquired an SSA3021X+, FW 2.2.2.3.2. Attempted to perform some "semirandom but careful mistakes" as others have put it

Here's what I did:
1. Ran the SSA3032X+_backup_NAND+mem+firmdata0.ADS and copied the backups to a safe place
2. Ran SVA1032X_telnet.ADS to get telnet
3. Connected to telnet, started with the instructions in #1223
4. Ran into the issue with step 3 about not having enough disk space, copied the ecomb_p file to the USB mount, then tried to copy it back as ecomb but didn't  have enough space?!
5. Also couldn't see the last line in startup_app.sh which I fixed with echo "" >> startup_app.sh
6. Tried to symlink /usr/bin/siglent/ecomb to the one on the USB, sync + reboot after editing startup_app.sh but the app still didn't run on boot
7. Now there was more space in /usr/bin/siglent (not sure why?) so I copied ecomb back there and just ran it manually to get the app to run
8. Went through the other steps in #1223 and started an upgrade with SVA1032X_V3.2.2.3.2.ADS
9. Unit rebooted twice but never launched the app. No more telnet either. (sigh)
10. Took off the back cover, got UART access, and ran ecomb from the USB manually and the app started up
11. (This is where I made things worse) I thought that SVA1032X_V3.2.2.3.2.ADS may be too new so I tried again with SVA1032X_V2.2.1.2.8.ADS, downgrading was a bad idea?
12. Following the progress of the upgrade using UART I can see that /usr/bin/siglent ran out of space and now I'm missing ecomb, startup_app.sh and all of /usr/bin/siglent/drivers, plus most other things in /usr/bin/siglent
13. I can still run original ecomb from the USB to get the app up, but it fails to load some drivers so I don't have a touchscreen and it doesn't seem to list any of the files on the USB drive in firmware upgrade anymore, so I can't run another update with an ADS file.

From what I can see, the upgrade_app step failed because there was no space left on /usr/bin/siglent aka MTD7, here's the relevant snippet of UART output:

Code: [Select]

update.sh starting ...
current version:
upgrade_app:            starting
rm: can't remove '/usr/bin/siglent/libscpi*': No such file or directory
cp: write error: No space left on device
cp: can't preserve times of '/usr/bin/siglent/startup_app.sh': No space left on device
cp: can't preserve ownership of '/usr/bin/siglent/startup_app.sh': No space left on device
cp: can't preserve permissions of '/usr/bin/siglent/startup_app.sh': No space left on device
-rpf /usr/bin/siglent/usr/usr/upgrade/app/startup_app.sh /usr/bin/siglent/
cp  -rpf /usr/bin/siglent/usr/usr/upgrade/app/ /usr/bin/siglent/usr/backup/
cp: write error: No space left on device
cp: can't preserve times of '/usr/bin/siglent/drivers/insmod_before_app.sh': No space left on device
cp: can't preserve ownership of '/usr/bin/siglent/drivers/insmod_before_app.sh': No space left on device
cp: can't preserve permissions of '/usr/bin/siglent/drivers/insmod_before_app.sh': No space left on device
cp: write error: No space left on device
cp: can't preserve times of '/usr/bin/siglent/drivers/uinput.ko': No space left on device
cp: can't preserve ownership of '/usr/bin/siglent/drivers/uinput.ko': No space left on device
cp: can't preserve permissions of '/usr/bin/siglent/drivers/uinput.ko': No space left on device
cp -rpf /usr/bin/siglent/usr/usr/upgrade/drivers/*   /usr/bin/siglent/drivers/
cp -rpf /usr/bin/siglent/usr/usr/upgrade/fpga/*   /usr/bin/siglent/config/fpga/
cp -rpf /usr/bin/siglent/usr/usr/upgrade/www/*   /usr/bin/siglent/config/www/
upgrade_app:  there is no *.dtb to upgrade
upgrade_app:            ending
rm: can't remove '/usr/bin/siglent/config/log/log4qt.conf': No such file or directory
upgrade_add:  upgrade  /usr/bin/siglent/usr/usr/upgrade/add/log4cpp.properties(I have full telnet and UART logs from the entire time I was attempting the cross-flash, so I can post much more detail if that helps.)

Now I have two options that I see:
1. Copy most/all(?) of the original MTD partitions back (nandwrite?) to reset it back to factory state, then try again?
2. Get an MTD7 dump from SVA1032X_V2.2.1.2.8.ADS and namdwrite it to complete the failed upgrade, then go for the SVA1032X_V3.2.2.3.2.ADS upgrade (or the latest version?).

Since I still have UART console access and things don't seem too badly broken, I'm wondering what those more experienced think is the best next step? It seems like I'm close to the goal of an SVA1032X_V2.2.1.2.8 crossflash, I just need a proper MTD7 partition.

[tv84]

A SSA3015X+ that booted up as a SVA1015X.

Here.

[gussy]

Thanks to the help of those here I was able to recover my SSA3021X+, then using post #1223 convert it into an SVA1032X. With firmware v2.2.1.2.8 as a base the instructions from post #1223 worked flawlessly, it seems that starting with v3.2.2.3.2 is more of a torturous path. Now it's unlocked and in developer mode, with persistent telnet.

I'd still like to know how to do it from the newer firmware version, so I may take some more nanddump's and revert this unit back to it's original state and see how it can be done safely.

Has anyone tested the latest firmware V3.2.2.3.3R1?

[s57mhj]

Always do a FULL BACKUP of your equipment before crossflashing!

Script to make a NAND dump + RAM dump + firmdata0 backup on a SSA3000X+ is attached.  (Tested OK.)

Use a pendisk >= 1 GBytes.  It can take up to 20 minutes.

Edit: Now it should reboot after backup is complete.

I am trying to make NAND dump and firmware backup of  SSA3021X Plus with FW 3.2.2.3.2…  It starts with Upgrading now,….. and restarts after 25 seconds without any backup.
Is the SSA3032X+_backup.ADS the right “toll” for the SSA3021X Plus with FW 3.2.2.3.2?
BR Joe

[s57mhj]

Hello!
Telnet is working,
dumpnand.sh results in nanddump: can't open '/dev/mtd12': No such file or directory and stops.
files size (together) is only 267.780.096 B (255MB)

LOG:
SUCCESS dumping /dev/mtd0
SUCCESS dumping /dev/mtd1
SUCCESS dumping /dev/mtd2
SUCCESS dumping /dev/mtd3
SUCCESS dumping /dev/mtd4
SUCCESS dumping /dev/mtd5
SUCCESS dumping /dev/mtd6
SUCCESS dumping /dev/mtd7
SUCCESS dumping /dev/mtd8
SUCCESS dumping /dev/mtd9
SUCCESS dumping /dev/mtd10
SUCCESS dumping /dev/mtd11
ERROR dumping /dev/mtd12
Is this all I need?

BR Joe

[s57mhj]

Hello!,
From what I see there is no mtd12 and each mtd from mtd0 – mtd11 is having mtdXro pair. I need advice from which point I am safe to proceed further. THX in advance!
BR Joe

[NCG]

Well, I did see no mtd12 either...

[s57mhj]

Well, I did see no mtd12 either...

Hello!,
Can you please check size of your nand dump backup? Thank you in advance!
BR Joe

[tv84]

If you run the "dmesg" command you should obtain all that info.

[s57mhj]

If you run the "dmesg" command you should obtain all that info.

Hello and thank you in the first place for your support and work done!

From dmesg it looks that NAND size iz 256MB !?
Flash is MT29F2G08ABAEAWP - M69A SLC 2Gb: x8, x16 ECC 
Do we know already what causes other members problem in crossflashing from FW 3.2.2.3.2 ?

BR Joe

[tv84]

Looking at dmesg output you can easily verify the individual mtd sizes.

Regarding the latest FW versions:

I haven't looked at it but I think there is no major problem. People just have to see if there is any need for the app rename or not (1st step).

The theory behind the method is pretty well explained so anyone with some linux knowledge can extrapolate any new step.

One thing is strongly advised: you should only crossflash with the same FW version. If not, there is an unnecessary higher risk in the operation.

[s57mhj]

Looking at dmesg output you can easily verify the individual mtd sizes.

Regarding the latest FW versions:

I haven't looked at it but I think there is no major problem. People just have to see if there is any need for the app rename or not (1st step).

The theory behind the method is pretty well explained so anyone with some linux knowledge can extrapolate any new step.

One thing is strongly advised: you should only crossflash with the same FW version. If not, there is an unnecessary higher risk in the operation.

Hello,
Thank you.
I renamed    /usr/bin/siglent/ecomb_p & to /usr/bin/siglent/ecomb &
Added /sbin/telnetd -l /bin/sh -p 10101 & one line above ecomb (the changed last line) of startup_app.sh
sync
reboot
to SSA 3021X Plus without problem (telnet  working tested/permanent)
crossflashed with SVA1032X_V3.2.2.3.2.ADS
and (stays) bricked with Siglent logo on the display (TG and Mode button illuminated).
BR Joe
Tomorrow I will open it to connect to console (have to look for the pin description In the forum)

[s57mhj]

and yes I changed the ID from 11405 to 11403 

BR Joe

[tv84]

The problem is the fact that Siglent finally corrected the app name in the new SVA FW to "Aladdin".

So instead of renaming ecomb_p to ecomb, one should rename to Aladdin to allow the overwriting when crossflashing (and not getting out of disk space).

If not, the Aladdin app doesn't get copied and the boot bricks...

PS: To solve, I suggest go in via serial, and rename the ecomb app to Aladdin and change also in the startup script.

[Bicurico]

Allow me to add:

WARNING:

IT IS UNSAFE TO USE SVA1032X_3.2.2.3.2!
This FW Upgrade does NOT delete "ecomb" or "ecomb_p" and thus the space runs out!

SVA1032X_2.2.1.2.5 --> deletes "ecomb" and replaces with "Aladdin"
SVA1032X_2.2.1.2.8 --> deletes "ecomb" and replaces with "Aladdin"
SVA1032X_3.2.2.3.2 --> does NOT delete "ecomb" and adds "Aladdin" --> BRICK because no free space left!
SVA1032X_3.2.2.3.3R1 -->  deletes "ecomb" and "ecomb_p" and replaces with "Aladdin"

Using this last FW is safe and you don't have to rename "ecomb_p" to "ecomb" nor do you need to edit the "startup_app.sh".

Regards,
Vitor

[Bicurico]

...
crossflashed with SVA1032X_V3.2.2.3.2.ADS
and (stays) bricked with Siglent logo on the display (TG and Mode button illuminated).
BR Joe
Tomorrow I will open it to connect to console (have to look for the pin description In the forum)

You have the same problem as gussy!

You need to telnet (probably through the console) and free up space by deleting the "ecomb" in /usr/bin/siglent.

Reboot.

The startup_app.sh should now run the upgrade_app1.sh that basically copies the files from /usr/bin/siglent/usr/usr/upgrade/app/* to /usr/bin/siglent/.

Good luck!

Regards,
Vitor

[gussy]

You have the same problem as gussy!
(...)

Yep, sounds like the same problem as me. Don't worry Joe, nothing is lost yet

Vitor posted the correct analysis of why it happens, it seems to just be an issue with the SVA1032X_3.2.2.3.2 firmware.
I made mine worse before it got better, but if you instead just do what is suggested above you should be fine.

I was able to upgrade to SVA1032X_3.2.2.3.3R1. I lost telnet (expected) and also seem to have lost the ability to mount any flash drives now. I need to crack mine open again and see what dmesg is saying and have a poke around. I don't even seem to get any activity LEDs on a few different flash drives, it seems like the port is just disabled. Needs more investigation.

[tv84]

Disclaimer: no pissing contest here.

As I said in my last post, the new SVA FW v3.x uses Aladdin as the name of its main app.

As such, one has to be sure that you are running an SSA app called Aladdin right before crossflashing the SVA FW 3.x.

Remembering the previous procedure:

2. rename
   /usr/bin/siglent/ecomb_p
   to
   /usr/bin/siglent/ecomb
3. in file /usr/bin/siglent/startup_app.sh change the line
   /usr/bin/siglent/ecomb_p &
   to
   /usr/bin/siglent/ecomb &

You only need to change to:

2. rename
   /usr/bin/siglent/ecomb_p
   to
   /usr/bin/siglent/Aladdin
3. in file /usr/bin/siglent/startup_app.sh change the line
   /usr/bin/siglent/ecomb_p &
   to
   /usr/bin/siglent/Aladdin &

and then you can flash any SVA FW 3.x

Another simpler option, as Bicurico explains, is just using SVA1032X_3.2.2.3.3R1 (which has an upgrade script that deletes ecomb, ecomb_p apps should any of them be present in the system, before attempting the transfer of Aladdin). Pay attention that this only works with that specific SVA1032X_3.2.2.3.3R1 FW version!

Nonetheless, in this case, you still need to do the NSP_config_upgrade_info.xml modification before attempting the crossflash.

I advise using this simpler method only if you have a SSAX+ with FW version 3.x.

[s57mhj]

With a lot of help from tv84 and Bicurico (Vitor) another SSA 3021X +  is alive and kicking  (again).

Best regards, Joe

[tv84]

I bring you another "semirandom but careful mistake" as a Xmas gift:

- a SSA3032X-R that reached 5GHz becoming a nice SSA3050X-R.


Merry Xmas to All!

[tv84]

Damn! I made a bigger mistake!!!   

Now the SSA3032X-R became a SSA3075X-R.   


There goes the neighborhood...

[Noy]

Ohhh teardown time? Whats the HW difference between -R and "cheap" SSA3021x plus?

[arturfra]

They are “real time” series...

[Noy]

Sure they are. But SSA+ and SVA have no HW difference. So is there a differnce between the -R and non -R in HW?

[arturfra]

-R have different hardware