Anritsu MS2721B internal CF card missing

[analogRF]

I've got a MS2721B which doesn't boot and the internal CF card has been taken out before they got rid of the instrument.
There are minor damages inside all fixable but I need to restore the OS before attempting anything.

Does anyone know how I can make the firmware CF card for this unit? I could not find a disk image

I downloaded the firmware and unzipped it on a USB flash ready for "firmware upgrade"
The whole file system of the OS seems to be already in there. Is it possible to just copy the firmware file structure
to a CF card and put it in? How should I format the CF card?

I asked Anritsu tech support and as usual they are of no help, saying (1) go read the maintenance manual! (2) The whole CPU board of the unit must be replaced so send it to us!

any help is appreciated.

[Stray Electron]

  is there any chance of getting the seller to send you the CF card if you offer him a ridiculous price for it?  I have two Anristsu SAs (older models) and I like them but there is ZERO support for them. 

[DaJMasta]

Have your tried just updating the OS with a blank CF card installed?  The updater on later models, at least, will load before the instrument fully boots if the USB stick is in at power on.  There's also an alternate firmware loading mode (not sure if it normally resides on the flash, though) that's accessible from startup with a button sequence, though again I don't know whether this applies to B models.


In any case, it could be worth contacting Anritsu support.  They've been helpful to me a couple of times (replacing a tilting bail and downgrading a firmware update that caused issues), so while they may just say "send it in for service" they also may be able to help you out.

[analogRF]

Have your tried just updating the OS with a blank CF card installed?  The updater on later models, at least, will load before the instrument fully boots if the USB stick is in at power on.  There's also an alternate firmware loading mode (not sure if it normally resides on the flash, though) that's accessible from startup with a button sequence, though again I don't know whether this applies to B models.


In any case, it could be worth contacting Anritsu support.  They've been helpful to me a couple of times (replacing a tilting bail and downgrading a firmware update that caused issues), so while they may just say "send it in for service" they also may be able to help you out.

as I already mentioned, I have contacted anritsu. they have never been of any kind of help to me in several cases including this one.
They simply said the whole board must be replaced

anyways, the instrument seems to be a decommissioned unit from a government agency and the seller I got it from had bought a bunch of these in a government auction and they all had their CF card removed. It even has a sticker showing when and by whom was the CF card removed 

yes, there is an emergency repair procedure in the manual when you need to hold softkeys #1,3,5 and power it on with a firmware USB in the unit.
but it didn't work with a blank CF card. Well I had it formatted (FAT32) maybe I shouldn;t have or it is just for recovering a corrupt OS not a fresh install...

Shahriar has a video on of these and the CF card in his unit was also cut out and he simply says he downloaded the firmware and made a CF card for the unit and he puts back in and it works. I have asked him how exactly he did it but he has never answered any of my questions in the past.

I think I am gonna just dump the unpacked firmware on the CF card and see how it goes. In the mean time I have damaged the CF card (another long story) so I need to buy another one first. The file structure of the unpacked firmware on USB stick seems like an image of a working OS...

[Thedon]

I own a MS22723B which I purchased a couple of years ago and was going to do a tear down and review but forgot to. I ended up taking it apart to replace the screen protector as the original was scratched and yellow I have attached photos. Maybe somebody can compare lower spec models with mine to see if there are any hardware differences. AnalogRF I don't understand why Anritsu informed you that the main PCB needs changing as the service manual lists the 512MB internal flash card as a replaceable part (3-2000-1567). If it helps I'm willing to take apart my unit again and have a look what's on my flash card maybe there are files on there with model and serial numbers which are scanned during boot up I don't know I always thought the card was for storing calibration data any way let me know if I can help.

[Thedon]

Here are some more photos including the old screen protector which is yellow and the new one which is nice and clear.

[analogRF]

I own a MS22723B which I purchased a couple of years ago and was going to do a tear down and review but forgot to. I ended up taking it apart to replace the screen protector as the original was scratched and yellow I have attached photos. Maybe somebody can compare lower spec models with mine to see if there are any hardware differences. AnalogRF I don't understand why Anritsu informed you that the main PCB needs changing as the service manual lists the 512MB internal flash card as a replaceable part (3-2000-1567). If it helps I'm willing to take apart my unit again and have a look what's on my flash card maybe there are files on there with model and serial numbers which are scanned during boot up I don't know I always thought the card was for storing calibration data any way let me know if I can help.

Thanks, Thedon. Nice instrument. The board looks very much like mine except that I don't have the flash card 
here is what exactly Anritsu "support engineer" wrote to me: "This internal compact flash is not sold separately and a new Main/SPA PCB would need to be ordered to get a new one of these." Sounds ridiculous but that's how Anritsu is.

The calibration data and system settings are stored in the EEPROM on the board not in the CF card. CF card only holds the OS and user data, traces, etc...

Anyways, I checked their website and it seems your fiirmware must be different than my instrument, so its image will not help me. However, if you
are willing to open it up again, I would very much appreciate if you can send me a copy of the firmware (OS)  files/directories. I want to compare it with what is unpacked on the USB flash and if the structure is exactly the same, I guess it would be safe to say that the firmware update just copies the files from USB to the CF card, so I can make the CF card myself. I also need to know how the CF card is formatted.

by the way, where did you get the screen protector? from Anritsu directly?

[Thedon]

Sounds like you did your homework that response from Anritsu makes no sense unless they want to install the firmware themselves maybe they don't trust their customers but we know what's the real reason. OK I will take it apart and copy the contents of the card and yes the screen protector was obtained from Anritsu but it came at a cost $170.45 for a piece of plastic I couldn't see any inbuilt RF shielding.

[brainstorm]

I purchased the same unit over ebay a while ago and also had the internal CF missing (with slightly broken holder as if it was removed by force). I wrote up my experience trying to boot it up with a firmware update image (with limited yet encouraging success) over here:

https://blogs.nopcode.org/brainstorm/anritsu-ms2721b-spectrum-analyzer/

TL;DR: I managed to dump the uncompressed memory contents to poke around with a few of the VxWorks functions to diagnose the underlying problem(s).

I think it would be of very high value (to me, perhaps others), if some of you owning the instrument could:

1. Connect it via ethernet to your home router or equivalent and power it up.
2. Telnet into it via the DHCP-assigned IP address.
3. Run a few of the commands outlined in the blogpost and paste the output back over here.

I'm specially interested on the VxWorks shell commands: DoRAMTest, sysSelfTest, sysOptionUpgrade and dumpEEPROM... to start with

You can either run the python script published on my blog to retrieve a ton of callable-from-the-VxWorks-shell functions and offsets or ask me about the .csv if you are interested.

/cc @Thedon, from your photos, you seem to have a fancy version of the unit with GPSDO and extra RAM daughter board? Interesting!

Cheers!

[brainstorm]

Here's a followup on my repair efforts if somebody is interested:

https://www.reddit.com/r/ReverseEngineering/comments/g0g8w2/vxhuntervxworksradare2_a_spectrum_analyzer_repair/

... r2/ghidra give quite a bit of insight on how to repair the boot process on my instrument (i.e when the CF card is "not good"), hope it helps someone else in my situation!

[thm_w]

Here's a followup on my repair efforts if somebody is interested:

https://blogs.nopcode.org/brainstorm/anritsu-ms2721b-spectrum-analyzer-repair-part-2/

... r2/ghidra give quite a bit of insight on how to repair the boot process on my instrument (i.e when the CF card is "not good"), hope it helps someone else in my situation!

Thanks for writing out all of this information.

[analogRF]

I purchased the same unit over ebay a while ago and also had the internal CF missing (with slightly broken holder as if it was removed by force). I wrote up my experience trying to boot it up with a firmware update image (with limited yet encouraging success) over here:

https://blogs.nopcode.org/brainstorm/anritsu-ms2721b-spectrum-analyzer/

TL;DR: I managed to dump the uncompressed memory contents to poke around with a few of the VxWorks functions to diagnose the underlying problem(s).

I think it would be of very high value (to me, perhaps others), if some of you owning the instrument could:

1. Connect it via ethernet to your home router or equivalent and power it up.
2. Telnet into it via the DHCP-assigned IP address.
3. Run a few of the commands outlined in the blogpost and paste the output back over here.

I'm specially interested on the VxWorks shell commands: DoRAMTest, sysSelfTest, sysOptionUpgrade and dumpEEPROM... to start with

You can either run the python script published on my blog to retrieve a ton of callable-from-the-VxWorks-shell functions and offsets or ask me about the .csv if you are interested.

/cc @Thedon, from your photos, you seem to have a fancy version of the unit with GPSDO and extra RAM daughter board? Interesting!

Cheers!

have you had any success yet? I have read your blog and it seems you are still stuck as I am 
I can only think of two possible causes, one is a hardware problem like a bad RAM or other chip and another is a corrupted flash rom or eeprom
on the board. For instance when I turn it on, it shows OS Build 2.04 while I am putting OS 3.78 on the CF card. I think during update, it loads the OS into a flash rom or something and I am guessing that mine is corrupted perhaps due to a failed update?

the two biggest problems that I have (aside from the unit not booting!) is that first of all when I get to the bootstrap mode (emergency recovery) I cannot update the OS from USB  the USB stick is in there but no matter what, when I select Update OS from USB, it does not do anything. I used 4 different USB sticks

the second problem is with the ethernet connection. if I connect to my router and turn it on, it never shows up on my network. If I go to recovery mode and manually force it to get IP address, then it does get IP and I can ping it but I cannot telnet to it and the Master Software on my laptop cannot recognize it. Any idea? any suggestion?

[analogRF]

Here's a followup on my repair efforts if somebody is interested:

https://www.reddit.com/r/ReverseEngineering/comments/g0g8w2/vxhuntervxworksradare2_a_spectrum_analyzer_repair/

... r2/ghidra give quite a bit of insight on how to repair the boot process on my instrument (i.e when the CF card is "not good"), hope it helps someone else in my situation!

it seems my instrument is stuck at about the same point as yours but how come you can telnet to it so easily? Mine does not even show up on the network and only if I go to the recovery mode I can force it to get IP and even then, still telnet does not do anything. when I telnet, it clears the terminal screen and that's it...nothing else shows up on terminal

[analogRF]

I finally got the god damn thing fixed 
Here is what you should do
1-install the Anritsu Master Software Tool (MST)
2-go to Product Update and download (retrieve) the firmware file inside the MST so it is ready
there you will see a button "Emergency Repair", click on that and it will explain what to do but I will tell you
3-connect the instrument to ethernet and turn it on in Recovery mode (hold softkeys #1-3-5 and power on)
when you are in the Bootstrap mode, choose Update OS using Ethernet and it will change to a blank screen with
one red statment saying it is waiting for Ethernet downloading connection...
4- in the MST enter the IP address of the instrument and click on Install New OS Now. and then just sit back and DO NOT TOUCH anything
no matter how everything seems weird or dead. (the message on the instrument screen will not change until much later) but it is actually
accepting the new OS from your computer
5-after quite a while the instrument will flash a new message saying the transfer is complete and it starts programming the ROMs on the instrument with new OS and it will finally go back to the first bootstrap screen
6- reboot the system and enjoy 

However, the only problem that I have right now is that the tracking generator option is nowhere to be seen 
my instrument passes all self tests and works perfectly but the tracking gen is not anywhere...

hope you can find a way to bring that back 

[analogRF]

brainstorm,
can you find a way to dump the eeprom? I am sure all options as well as cal data and serial number are stored in there
I tried your dumpEEPROM command but it didnt work although it seems it was recognized by the OS but didnt dump the EEPROM

[brainstorm]

Awesome news, I'm so happy for you @AnalogRF!

My instrument needs review on the power rails/capacitors, it was a bit finicky on power-on before and now it doesn't even turn on, just flickers. I tried the MST software before but couldn't get a connection so no firmware update was possible, I'll take your advice into account when the hardware side is back in good health

So unfortunately I cannot dump the EEPROM... yet. If you are based in Melbourne we can meet and exchange notes perhaps? Happy to!

[analogRF]

Awesome news, I'm so happy for you @AnalogRF!

My instrument needs review on the power rails/capacitors, it was a bit finicky on power-on before and now it doesn't even turn on, just flickers. I tried the MST software before but couldn't get a connection so no firmware update was possible, I'll take your advice into account when the hardware side is back in good health

So unfortunately I cannot dump the EEPROM... yet. If you are based in Melbourne we can meet and exchange notes perhaps? Happy to!

no, ignore when MST says cannot connect to the instrument! Mine said that too. Ignore that. That type of connection can only be established when the instrument is up and running.
But when you go to the emergency repair and select Install New OS then IT WILL CONNECT to the instrument although it does not say it explicitly.
I guess it must be a sort of ftp connection but FIRST you must put the device in the firmware downloading state as I explained.
You will not see anything happening on the instrument screen but it is actually downloading the firmware.

I desoldered the EEPROM (there is only one single 32KB SPI EEPROM - AT25256AW - on the entire board) and dumped it. It's all garbled binary.
I used every tool I know of to try to extract some meaningful information like the serial number or even model number which the manual says are in the EEPROM or any other meaningful word , but nothing    I put it back in and of course the instrument works fine .

The power rails are easy to repair, but are you sure it is the power rails? Disconnect the RF deck completely and try it again. Actually you can go though the whole firmware flashing without having the RF deck connected but I recommend having it because it might want to flash the FPGA on the RF board, too. but for troubleshooting you can disconnect it. There are two 12.2V rails that are the mother of all the other voltages. 1.8V, 2V, 4V, 5V and 3.3V  the rest of the voltages do not start until the instrument is up and runs the application

[brainstorm]

Interesting, can you send me that EEPROM dump? What you mention seems like cal data... it'll help me understand as I go through the EEPROM function callgraph as I recover this repair work: brainstorm at nopcode dot org

I am not 100% sure the rails are the problem, but what I know is that the SuperH4 CPU has all the clock signals, the READY signal shows up but it seems to be rebooting all the time... I did remove the RF deck entirely during all tests, so only working on the main board + display: it flickers on power up and that's it so far, worked well before... what else do you reckon it could be? Perhaps I should revisit the caps near the RAM chips, I might have knocked them off making the system unstable :/

Any sound way to know if the RAM ICs are fine?

[analogRF]

one thing I learned is that your power supply must be able to deliver at least 2.5-3A current (at 13V which I used) otherwise the system reboots randomly at various stages. Just during the boot I think it took up to 2.2A and later on during normal operation sometimes based on what operation you do it would take surge currents up to 3A or more. If the power supply cannot deliver it and drops its voltage, it will reboot.
This thing draws some surge currents (pulse) for a short time that you will not see it on the power supply display. So I finally ended up using an Agilent supply which could deliver 4A and I used it at 13V. The instrument sticker also shows it needs 12V-15V@4A. The original adapter of this unit is rated 12V@5A. I thought that kind of current is only needed if you have a battery that needs charging but I was wrong, even normal operation with no battery still needs some large currents
also if it "flickers", maybe it is the backlight driver or the power supply rail that goes to the backlight driver. The capacitors look high quality and I hardly think they are bad unless they have leaked.
Take the power supply shield off and measure at the big inductors. You must have the 12.2V (I think at two of them IIRC), 1.8V,3.3V, 5V, 4V and I think 2V. but 2 or 3 of them do not have anything because they dont come online until later.

[codex0]

RE what is stored in the EEPROM, the user manual states:

EEPROM This memory stores the model number, serial number, and calibration data for the instrument. Also stored here are the user-set operating parameters, such as frequency range. During the master reset process, all operating parameters that are stored in the EEPROM are set to standard factory default values.

RAM Memory This is volatile memory that is used to store parameters that are needed for the normal operation of the instrument along with current measurements. This memory is reset whenever the instrument is restarted.

External USB Flash Drive This memory may be selected as the destination for saved measurements and setups for the instrument. You can also copy the contents of the internal disk-on-chip memory to the external flash memory for storage or data transfer. The external Flash USB can be reformatted or sanitized using software on a PC. Refer to the Chapter 4, “File Management” for additional information about saving and copying files to the USB flash drive.

Compact Flash Card This memory may be selected as the destination for saved measurements and setups for the instrument. The external Compact Flash Card can be reformatted or sanitized using software on a PC. Refer to Chapter 4, “File Management”

[brainstorm]

Hello @AnalogRF,

I now have a proper lab PSU that can do up to 30V and 6A (ITECH triple output IT6302)... it is definitely a big improvement over the dodgy chinese wall wart I had before XD

I have been chasing the voltage rails you mentioned under the Anritsu tin can:

You must have the 12.2V (I think at two of them IIRC), 1.8V,3.3V, 5V, 4V

I have attached a few of them in this post, it would help a lot if you could verify that those are the same you are seeing on your board. I'm powering the main board with 15V and it barely consumes 350mA, no chip gets hot AFAICT and I've disconnected *everything* (no screen attached, no cold tube board, no CF card, etc...). Please let me know if there's any critical rail that I should specifically check, I have "The Signal Path" youtube video screenshot as a reference, but since that video is from the "A" model (attached below, image with red post-it stickers), there are a few differences.

There's a very small "PWR_FAIL" via that reads 3.3V... but since it's close to the battery charging circuit, I doubt it's an "overall" diagnostic for the instrument's power supply, but just a battery present/not present type of check?

@AnalogRF, I could not locate the 12.2V rail you suggested. The closest seems to be the input voltage (using 15V input via the barrel jack, with 0.2V voltage drop for the cable leads).

As I mentioned a while ago, the processor seems to be alive (3.3V and RDY/RESET signals) and the screen does flicker on boot, but doesn't get very far. When I connect the screen, it oscillates very slowly between 300 and 400mA, which suggests a bootloop.

I'll be taking a closer look at the RAM chips soon since I have some suspicion that one of them is not behaving exactly as the other does, but if anybody has other good troubleshooting suggestions, I'm all ears

[brainstorm]

The RAM seems to have addresses being latched on Ax pins (see attached pinout from the datasheet), but no data is coming in/out via DQx pins (the RAM ICs in this device are on the 16x pinout)... I'll check the SuperH4 CPU next...

[brainstorm]

The processor RESET line is high and there's a constant 33,3MHz waveform on EXTAL pin, but it's seemingly struggling to boot since the RDY spits out a train of repeated waveforms, goes silent for a few seconds and repeats (see attached SuperH4-RDY.png).

[analogRF]

Hello @AnalogRF,

I now have a proper lab PSU that can do up to 30V and 6A (ITECH triple output IT6302)... it is definitely a big improvement over the dodgy chinese wall wart I had before XD

I have been chasing the voltage rails you mentioned under the Anritsu tin can:

You must have the 12.2V (I think at two of them IIRC), 1.8V,3.3V, 5V, 4V

I have attached a few of them in this post, it would help a lot if you could verify that those are the same you are seeing on your board. I'm powering the main board with 15V and it barely consumes 350mA, no chip gets hot AFAICT and I've disconnected *everything* (no screen attached, no cold tube board, no CF card, etc...). Please let me know if there's any critical rail that I should specifically check, I have "The Signal Path" youtube video screenshot as a reference, but since that video is from the "A" model (attached below, image with red post-it stickers), there are a few differences.

There's a very small "PWR_FAIL" via that reads 3.3V... but since it's close to the battery charging circuit, I doubt it's an "overall" diagnostic for the instrument's power supply, but just a battery present/not present type of check?

@AnalogRF, I could not locate the 12.2V rail you suggested. The closest seems to be the input voltage (using 15V input via the barrel jack, with 0.2V voltage drop for the cable leads).

As I mentioned a while ago, the processor seems to be alive (3.3V and RDY/RESET signals) and the screen does flicker on boot, but doesn't get very far. When I connect the screen, it oscillates very slowly between 300 and 400mA, which suggests a bootloop.

I'll be taking a closer look at the RAM chips soon since I have some suspicion that one of them is not behaving exactly as the other does, but if anybody has other good troubleshooting suggestions, I'm all ears

i dont have that spectrum analyzer anymore. I fixed it and everything worked perfectly before I sold it.
however, if you watch Shahriar's video about MS2721B (or perhaps MS2721A which has a similar power supply anyway) he will show the voltages
on the board briefly. But there are lots of them clearly marked on the main board and you dont need any reference. All of them are clearly marked
2 or 3 of them are outside the PSU section (1.8V and 24V and perhaps one more 3.3V)
all of them must be stable and there was no pulse or noise or ripple on any of them as I recall. However, 24V only comes on when the system is booted (24V is the supply for the RF deck)

Vsys is 12V as I recall, that's what I was referring to. it is clearly marked on the board.

[analogRF]

Hello @AnalogRF,

I now have a proper lab PSU that can do up to 30V and 6A (ITECH triple output IT6302)... it is definitely a big improvement over the dodgy chinese wall wart I had before XD

I have been chasing the voltage rails you mentioned under the Anritsu tin can:

You must have the 12.2V (I think at two of them IIRC), 1.8V,3.3V, 5V, 4V

I have attached a few of them in this post, it would help a lot if you could verify that those are the same you are seeing on your board. I'm powering the main board with 15V and it barely consumes 350mA, no chip gets hot AFAICT and I've disconnected *everything* (no screen attached, no cold tube board, no CF card, etc...). Please let me know if there's any critical rail that I should specifically check, I have "The Signal Path" youtube video screenshot as a reference, but since that video is from the "A" model (attached below, image with red post-it stickers), there are a few differences.

There's a very small "PWR_FAIL" via that reads 3.3V... but since it's close to the battery charging circuit, I doubt it's an "overall" diagnostic for the instrument's power supply, but just a battery present/not present type of check?

@AnalogRF, I could not locate the 12.2V rail you suggested. The closest seems to be the input voltage (using 15V input via the barrel jack, with 0.2V voltage drop for the cable leads).

As I mentioned a while ago, the processor seems to be alive (3.3V and RDY/RESET signals) and the screen does flicker on boot, but doesn't get very far. When I connect the screen, it oscillates very slowly between 300 and 400mA, which suggests a bootloop.

I'll be taking a closer look at the RAM chips soon since I have some suspicion that one of them is not behaving exactly as the other does, but if anybody has other good troubleshooting suggestions, I'm all ears

you are measuring the MSOFET switching signals in some of these pictures. Just measure the output of each converter (at the output capacitor or even better at test points that are clearly marked on the board with voltage values)

also that 535mV is definitely suspicious . Does not make sense
 

[brainstorm]

Alright, @AnalogRF, my bad.

I hope that the attached photo is much clearer. I annotated the "clean" outputs of the coils as Shariar did in his video with postits (for the "A", mine is "B" series). Here's Shariar's postits for reference:

https://www.eevblog.com/forum/testgear/anritsu-ms2721b-internal-cf-card-missing/?action=dlattach;attach=1096304

My intention was to supply some of the voltage rails on both sides of the coils, but I understand that the switching (MOSFET, or more specifically [LT1765](https://www.analog.com/media/en/technical-documentation/data-sheets/1765fd.pdf) side is not helpful and it looks like healthy switching anyway so not very informative overall.

Please ignore the 535mV figure, that's just the DC Vpp measurement, that's also confusing, sorry about that.

Also, the DC barrel jack has an input voltage range of 12-15V DC, that's why I was confused with your 12V rail... that's just V_SYS, also seen in some of the coil inputs.

In any case, at least 4 of those coils are off... do you think that's a product of the power sequencing/early boot or is some rail is cooked?

The 15-0V postits (2 of the coils) indicate that there is 15V (barrel jack input) present in one side and 0V on the other side.

[analogRF]

Alright, @AnalogRF, my bad.

I hope that the attached photo is much clearer. I annotated the "clean" outputs of the coils as Shariar did in his video with postits (for the "A", mine is "B" series). Here's Shariar's postits for reference:

https://www.eevblog.com/forum/testgear/anritsu-ms2721b-internal-cf-card-missing/?action=dlattach;attach=1096304

My intention was to supply some of the voltage rails on both sides of the coils, but I understand that the switching (MOSFET, or more specifically [LT1765](https://www.analog.com/media/en/technical-documentation/data-sheets/1765fd.pdf) side is not helpful and it looks like healthy switching anyway so not very informative overall.

Please ignore the 535mV figure, that's just the DC Vpp measurement, that's also confusing, sorry about that.

Also, the DC barrel jack has an input voltage range of 12-15V DC, that's why I was confused with your 12V rail... that's just V_SYS, also seen in some of the coil inputs.

In any case, at least 4 of those coils are off... do you think that's a product of the power sequencing/early boot or is some rail is cooked?

The 15-0V postits (2 of the coils) indicate that there is 15V (barrel jack input) present in one side and 0V on the other side.

1-did you check all the "test points" (not just the coils) that are marked on the board with various voltages? there are a few test points outside the PSU section for 3.3V and 1.8V and I think a couple of others, too. Those must exist in order to boot.

2-do not inject power to the coils from outside! you can try to supply outside voltage if you desolder the coil first and then use a current limited supply and slowly increase the current limit to check but if there are several rails missing, this becomes tedious...

3-what do you mean by "15-0V" in those stickers?

4-why are there no negative voltages anywhere? I remember there were one or two negative rails in there.

5-those rails that are zero, did you check for any shorts in their outputs? or in their mosfet and diode?

usually it is unusual that 4 rails fail at the same time together but as I recall some rails were the primary for other rails, so if one fails, 1 or 2 others may fail as well. With the help of datasheets you should be able to trace each dc-dc converter to its source/primary.

6-w.r.t. your last question, I wish I could remember exactly how the rails behaved but as far as I remember those power rails under the hood
were present right after power on (maybe except for charging) but the 24V which is marked somewhere outside the shield (near the ribbon connector) will turn on much later. so I believe the voltages under the shield should be present during boot. Now if they are dead, it's either a short in their load or a defect in the dc-dc converter itself.
I would start by checking each dc-dc converter separately from its input to output by following their datasheet. I think some of them had shut down for over current protection and if you look at datasheet you can check if over current has happened

I will try to locate my pictures of the ms2721b which I had taken with voltages written on them. I cannot find them in my laptop so
they are probably on one of the ssd backups... but i remember it was similar to what Shahriar had shown but with a little more detail

[brainstorm]

Thanks for the advice and pointers!

1- Yeah, 3V3, 5V0 and 1V8 are also present on silkscreen marked vias.
2- Not yet, I will poke at the SHDN (Shutdown) pins for the LT1765's and see if other ICs are keeping those deactivated (or if they are blown or inactive via some other legitimate means).
3- 15V on some of the pins, 0V on the rest... so you can take those as effectively 0V output I reckon, need to study the LT datasheet and see what's going on with those.
4- Good question! the -15V0A rail is not present (0V)... but I guessed that rail just comes later on when powering up RF deck(s)?
5- I checked all diodes with the multimeter and they seem fine, I will proceed checking the LT1765 and LT1377's and their surrounding components next.... if there was a short somewhere, I guess that this thing wouldn't just consume 350mA and there would be something getting hot?
6- I hope it's indeed an overcurrent condition from some of the passives because otherwise I'll have to see how the TI IC immediately on the back of the board (TI TY1543) monitors and controls all of the LT's on the power supply can... a bit of a rabbit hole there, I hope I can find the fault sooner than that

[analogRF]

Thanks for the advice and pointers!

1- Yeah, 3V3, 5V0 and 1V8 are also present on silkscreen marked vias.
2- Not yet, I will poke at the SHDN (Shutdown) pins for the LT1765's and see if other ICs are keeping those deactivated (or if they are blown or inactive via some other legitimate means).
3- 15V on some of the pins, 0V on the rest... so you can take those as effectively 0V output I reckon, need to study the LT datasheet and see what's going on with those.
4- Good question! the -15V0A rail is not present (0V)... but I guessed that rail just comes later on when powering up RF deck(s)?
5- I checked all diodes with the multimeter and they seem fine, I will proceed checking the LT1765 and LT1377's and their surrounding components next.... if there was a short somewhere, I guess that this thing wouldn't just consume 350mA and there would be something getting hot?
6- I hope it's indeed an overcurrent condition from some of the passives because otherwise I'll have to see how the TI IC immediately on the back of the board (TI TY1543) monitors and controls all of the LT's on the power supply can... a bit of a rabbit hole there, I hope I can find the fault sooner than that

2-monitor the on/off pins of LT1377(s) and LT1765(s) "during the boot" with oscilloscope to see if and when they are on line.
3-just measure the pin that goes to the big filter capacitor. I think those rails are OK
4-as I remember it, voltages under this shield were all present at the beginning. The voltage for RF deck that comes on much later is a 24V
5-....no, not necessarily. Simply check the resistance to ground at those power rails that read 0V to see what might be going on

try to power it on with the RF deck disconnected. In a normal unit, it will boot.

[brainstorm]

Thanks @analogRF,

I re-checked the rails as you indicated (via the output cap instead of the coils), I hope it makes a bit more sense now, I've attached an updated post-it screenshot.

2- I monitored the two "unresponsive" rails on power-on but there's little difference in the S/S or SHDN pins (LT1377 and LT1765 respectively)... the input is just 0V while on the working rails it reads somewhere in between 1.9V and 3.7V, which seems to match the spec.
3- The two non-postit-labeled rails: upper -15V and lower unknown (since I cannot see any nearby silkscreen indicating expected voltage) are totally silent... but since both are driven by different buck/boost ICs, I find it weird that it's not driven by external signals? I mean, I find it unlikely that both rails have failed at the same time... sounds more like a power sequencing/firmware/other_ICs issue?
4- I would very much appreciate that image in your backups to know which voltages should be present
5- Both IC series seem to be on the Mega-Ohm ranges (and both "healthy" and non-working show similar values) according to my multimeter.


I have *everything* disconnected, it's just the bare board sitting on the desk with no screen/backlight circuit/tweeter or anything else.

I followed the SHDN traces for the LT1765 to see if having ~3.3V present there would "wake up" the IC, but no switching activity happens on the other pins... I'll brainstorm a bit on what to do next, but followup suggestions/thoughts and info are super welcome! Thanks for the attention and effort, this is fun

[brainstorm]

I'm also attaching a picture clarifying a bit my thinking while the tracing of the LT1765's SHDN signal (in red, following it via both sides of the board). Since it was 0V on that pin, I tried "bridging" (direct blue line) it with a wire in an attempt to "wake it up" (unsuccessfully). Here's the datasheet for that component:

https://www.onsemi.com/pub/Collateral/NC7SZ14-D.PDF

It just converts that curvy waveform into a square one by the looks of it... thinking it through that was not a good idea since the healthy rails show a 2.5-3.3V **constant** DC voltage fed on that particular pin and IC (LT1765). On the other hand, I noticed that my "injected" 3.3V input signal got attenuated to around 1.9V, so that makes me think that the line is being actively pulled down somewhere else in the circuit, probably via firmware/software.

[analogRF]

your lucky day 
I found my stash of photos when I was troubleshooting and gathering notes on this device.
Here are the pictures that I had taken and annotated at that time.
Strangely the -15V never comes on. maybe it is used with some options like GPS or something....
anyways, I hope this helps

based on my notes, all rails start right at the beginning except the 24.6V which comes on only a short time after power on (still during boot process)
and -15V never came on.

I think the unit will not boot at all if you disconnect the screen, too. at least have everything connected except maybe just the RF deck

even without RF deck it does not boot as I just learnt from my notes. I was under impression that it booted without RF deck but apparently it didnt

[analogRF]

...more pics...

[analogRF]

based on what I just posted, I think your PSU rails are probably ok. You are stuck very early in the boot
and most probably the problem is somewhere else...maybe the RAM chips...

what exactly are the symptoms? what do you see on screen when you power it on?
 

[brainstorm]

Woah, thanks for those pictures and hints @analogRF!

I went through all your annotations and all of them cross-check right on my end **except** the -6.1V **and** the one that has an annotation down below stating that "comes on after a few seconds of power on. not right from beginning"... I suspect that the latter supplies power to the "RF mini-deck" (not the big RF deck instrument half), so I'm not too surprised now that it's not powering on yet since it might be too early in the boot process.

Also, I went ahead and hot-gunned and substituted the RAM ICs with fresh ones I had on stock (see attached), to rule out faults there... same effect, unfortunately, but at least I can now state that it seems unlikely to be a RAM's fault.

This instrument used to work and indeed it hung up on the "Application started" you point out, with working screen and all. The number of "successful boots" up until that "Application running" point decreased until the current situation: **you can see the pixels of the screen getting "active", but no backlight illumination nor any pattern or image"**... this behavior seems consistent with a slowly dying flash memory perhaps? I've heard Teslas go black screen due to dead eMMCs

In any case, all those tests we went through, plus thits last IC swap and your images gives me very valuable information:

1) The fault is **VERY** early on the boot process.
2) The processor works fine, clocks and address lines on the RAM are asserted but there doesn't seem to be data/activity.
3) The RAM ICs do not seem to be the main issue and power consumption remains the same pre/post RAM IC swap, that is ~300mA @15V DC.

For the reasons stated above I'm tempted to believe that the next most likely candidate for troubleshooting could be the Flash ICs (256P30T) since the program might not be successfully read anymore and copied to the RAM perhaps?:

https://www.dataman.com/media/datasheet/Intel/P30Family.pdf
https://www.aliexpress.com/item/32838590465.html

I would like to be extra sure that this is the next step though since a 64 "easy" BGA package can be a bit of a pain to work with :/ So I went ahead and looked at the datasheet above and noticed that there's a silk screen near the 256P30T IC marked as "WAIT" with a VIA, which seems to be a prominent signal for this IC according to the datasheet since on page 20 of the P30Family.pdf it states that:

In synchronous array or non-array read modes, WAIT indicates invalid data when asserted and valid data when deasserted. In asynchronous page mode, and all write modes, WAIT is deasserted.

Probing it with the oscilloscope, it seems like it is asserted (high) all the time at 3.3V... there could be many other glue logic involved here, but I'm trying to think this out loud, feedback welcome as always!

[analogRF]

No, I was not talking about those two RAM chips. I have yet to see them fail in these units. The RAM chip that I had to replace once (also Shahriar replaced in one of his videos) was one of those 6 chips that are on the lower right side of the board (top and bottom side).

i think there was more DC=DC converters on the backside. you can check them too. I have no picture. If there is no backlight, you should check the inverter and its input voltage.

flash chips would be the very very last thing I would touch really. besides I am sure there must be a serial console port somewhere on this board
I tried a little bit to figure it out but I gave up. If you can find that, you can probably force it to boot from a usb or tftp and bring it back to life
if it is indeed the flash corruption. yours seems to stop very early, so i dont think you still have LAN activated but it's worth checking
if you can telnet to it.


by the way, have you tried to power it on in recovery mode as per service manual?


But the symptoms you describe, point to a hardware failure rather than a flash corruption which I consider a software failure. So I would stll investigate hardware issues like other DC DC converters and RAM chips

[codex0]

No, I was not talking about those two RAM chips. I have yet to see them fail in these units. The RAM chip that I had to replace once (also Shahriar replaced in one of his videos) was one of those 6 chips that are on the lower right side of the board (top and bottom side).

Could you describe the instrument behavior and how you diagnosed the RAM chip as bad in your case? Shahriar's chip was hot and the unit did not boot fully, I'm curious to know if yours was the same or different in both identifying the bad chip and how the instrument behaved.

[brainstorm]

@analogRF: those SRAM chips you mention (6 of them on one corner and both sides of the board, near the DSPs) were fine when the instrument was functioning and going all the way towards "Application loaded!"... I did buy and substitute all them by fresh SRAM ICs (3 on each side) and the result was exactly the same: all good all the way up to "Application loaded" (with or without RF deck attached)... so those are also unlikely to be the issue either I guess :/

The Ethernet port is the one I was using back when the instrument was working and how I wrote my initial blogposts as well (dumping the RAM via metasploit against VxWorks debug functionality w/ telnet):

https://blogs.nopcode.org/brainstorm/anritsu-ms2721b-spectrum-analyzer-repair-part-2/

At present, ethernet's link doesn't go up at all, I bet it doesn't even reach anywhere near the so-called "emergency mode" (TFTP) either... and USB software recovery never worked either back then, actually. I have not poked serial ports on the SuperH4, but I doubt I can get anything meaningful there either, it very much seems like pre-boot electrical issue, but I'll check them out anyway.

by the way, have you tried to power it on in recovery mode as per service manual?

Yes indeed, no effect :/

When you say "other DC-DC converters" do you mean those inside the PSU can or elsewhere?

@codex0: The ICs were never hot as Shariar's video. When I received the instrument I substituted those ICs almost right away because I suspected that it was a common fault mode, but it doesn't seem to be the case with mine :-S

The current behavior is 15V@300mA on power on, pushing the button next to the red LED turns in on (according to ON_OFF_FLAG silkscreen via next to the RAM ICs, going from 0V to 3.3V). Pushing that button does NOT turn the screen's backlight on, but you can see how *all* pixels change (from default "off yellowish" color of the screen to a darker color as a result of the pixels being turned on). That's all really, unfortunately :-S... under the hood it's interesting because most of the rails are up, reasonable signals are happening all across the board but there's something buggering it all XD

Thanks much for following along, much appreciated

[analogRF]

No, I was not talking about those two RAM chips. I have yet to see them fail in these units. The RAM chip that I had to replace once (also Shahriar replaced in one of his videos) was one of those 6 chips that are on the lower right side of the board (top and bottom side).

Could you describe the instrument behavior and how you diagnosed the RAM chip as bad in your case? Shahriar's chip was hot and the unit did not boot fully, I'm curious to know if yours was the same or different in both identifying the bad chip and how the instrument behaved.

those chips are 512Kx8 byte 3.3V SRAM. It's a tedious work really but in my case I monitored the chip control pins (CS,  OE, WE) along with data bits (I/O) and address bits (4 channel Lecroy 2GHz scope with AP020 FET probes)
and luckily on the second chip that I tried I noticed the data coming out of the chip in read cycles looked very crappy (well others didnt look good either but on this one the data was very crappy). but for that you really need very low capacitance probes otherwise the signals look very bad no matter what

[analogRF]

@analogRF: those SRAM chips you mention (6 of them on one corner and both sides of the board, near the DSPs) were fine when the instrument was functioning and going all the way towards "Application loaded!"... I did buy and substitute all them by fresh SRAM ICs (3 on each side) and the result was exactly the same: all good all the way up to "Application loaded" (with or without RF deck attached)... so those are also unlikely to be the issue either I guess :/

The Ethernet port is the one I was using back when the instrument was working and how I wrote my initial blogposts as well (dumping the RAM via metasploit against VxWorks debug functionality w/ telnet):

https://blogs.nopcode.org/brainstorm/anritsu-ms2721b-spectrum-analyzer-repair-part-2/

At present, ethernet's link doesn't go up at all, I bet it doesn't even reach anywhere near the so-called "emergency mode" (TFTP) either... and USB software recovery never worked either back then, actually. I have not poked serial ports on the SuperH4, but I doubt I can get anything meaningful there either, it very much seems like pre-boot electrical issue, but I'll check them out anyway.

by the way, have you tried to power it on in recovery mode as per service manual?

Yes indeed, no effect :/

When you say "other DC-DC converters" do you mean those inside the PSU can or elsewhere?

@codex0: The ICs were never hot as Shariar's video. When I received the instrument I substituted those ICs almost right away because I suspected that it was a common fault mode, but it doesn't seem to be the case with mine :-S

The current behavior is 15V@300mA on power on, pushing the button next to the red LED turns in on (according to ON_OFF_FLAG silkscreen via next to the RAM ICs, going from 0V to 3.3V). Pushing that button does NOT turn the screen's backlight on, but you can see how *all* pixels change (from default "off yellowish" color of the screen to a darker color as a result of the pixels being turned on). That's all really, unfortunately :-S... under the hood it's interesting because most of the rails are up, reasonable signals are happening all across the board but there's something buggering it all XD

Thanks much for following along, much appreciated

oh OK, I didnt know you had replace those SRAMs already. Let's hope they are indeed all OK though.

No, I meant I think there were some more DCDC converters on the back of the board. I cannot remember exactly. I might be wrong

the fact that you do not have the -6.1V (which is designated by -5V8 on the board and in the instrument self test) might be a clue.
as I said, all rails except that 24V come online right after power on. Even 24V comes on very shortly after (even with no RF deck attached)

[brainstorm]

Alright, almost one year later, I'm not giving up on this baby, this repair is gonna be EPIC if and when it works again: persistence is not futile, sunk costs do not exist in hobbies kind of thing

Jokes aside, I now have access to a thermal camera, I'm attaching the photos... The detected components when powering up are clearly not shorting since the temperature is very reasonable (around 31degC tops) and the board is currently only drawing around 330mA according to my lab PSU. At least this information underlines the fact that since only that IC is "lightning up" on the camera, there's clearly something wrong with the power sequencing for the other chips? So I'll see how the other rails are brought up, please let me know if my logic is flawed...



That LT1765 IC and accompanying diode shown in the thermal picture are VR1001, as can be seen on a previous post picture: 

https://www.eevblog.com/forum/testgear/anritsu-ms2721b-internal-cf-card-missing/?action=dlattach;attach=1096280

Now, I was tracing SHDN (shutdown) signal from that IC, which is 3,3V at the moment, which means that it's active (inverted logic according to the datasheet?):

https://www.analog.com/en/products/lt1765.html

This rail seems to be operating fine, with an arguably clean, switching 14V on the output.

I'll now compare the shutdown signals for the other LT1765 ICs and rails, I'll keep you folks posted as I progress in this, troubleshooting ideas/hints welcome as always

[brainstorm]

I've now figured out the circuit/topology of VR1001 (one of the LT1765 regulators):



Which is slightly different from the topologies exposed in the official datasheet on quick peek:

https://www.analog.com/media/en/technical-documentation/data-sheets/1765fd.pdf

But anyhow, now I know that VR1000, VR1001 and VR1002 are all connected through the same SYNC signal... unfortunately I couldn't figure out where those SYNC signals are connected on a quick and dirty continuity "copper braid scan" across other neighboring components for both sides of the board:



Similarly, VR1004 and VR1003 are connected to each other via their SYNC signal, but do not share that one with the other VR group mentioned above... which might suggest two independent "blocks" of power regulators to sequence/turn on?

Question to @analogRF and others: any idea about which IC could be orchestrating those two sets of power rails?

[brainstorm]

> No, I meant I think there were some more DCDC converters on the back of the board. I cannot remember exactly. I might be wrong

Hm, I can't remember any DCDC converter at the back of the board but will check... Right now I wonder which IC does the coordination between those DC converters inside the metal can so I can follow the power-up chain.

[analogRF]

> No, I meant I think there were some more DCDC converters on the back of the board. I cannot remember exactly. I might be wrong

Hm, I can't remember any DCDC converter at the back of the board but will check... Right now I wonder which IC does the coordination between those DC converters inside the metal can so I can follow the power-up chain.

this is all controlled directly by the CPU (or the FPGA). I dont think the issue is "power up chain", in fact i am pretty sure it isn't...if all converters are ok, then you should look somewhere else. can you put the unit in bootstrap mode? is there anything at all appear on screen when powered on? have you tried to telnet (very quickly after power on)? are you sure the CF card is ok and FW is Ok? there is a chance that during a FW upgrade someone screwed up. That can be solved by putting the unit in bootstrap mode..
if it is totally dead, then check the signals around the memories and CPU. are they showing any activity? dont waste too much time on chasing the power up chain...if the dc dc converters are ok, then power supply is working and problem is somewhere else really. right now I am working on a 2721B with tons of RF issues (bad attenuators + LO unlock) all are fixable easily but I can check some signals if you need...

EDIT: the bare minimum you need to have in order to see the unit powering up is 1.8V, 3.3V and the backlight voltage (i dont remember which supply line goes to backlight driver but you can figure it out easily) if those are all there then you can forget the power supply.

[brainstorm]

Thanks for the response and the hints! I've checked the 1.8V, 3,3V and backlight voltage (seems to be same as VIN on a couple of pins of the connector, 14V and 3.3V on another two, GND on the rest). Unfortunately no, there's no telnet nor bootstrap mode possible, AFAICT :/

When the unit was "working" (boot sequence until "Application package: null" prompt), it did boot even without ANY CF card inserted. So I'm trying to trim down all possible external factors here and thus I just have the bare board which draws around 300mA at 14V at the moment on my desk... could you do the same experiment and let me know how much it draws? Disconnect *everything* (including backlight an display) and see how much it consumes and if it seems to boot by eyeing power consumption fluctuations (mine hovers around 300-350mA from power on)?

If I connect the display, no backlight appears, just a brief noticeable change of state from the LCD pixels. I see plenty of activity on the SH4, the flash chip's WAIT signal (btw, can you probe the E4050 and E4049 near those flash 256P30T IC's?) and the RAM ICs too (addresses latching and data coming in/out).

Reading this thread, my last hunch was about the Flash chips but I'm still uncertain :/ ... I guess that putting some logic analyzer probes on the SRAM and try to see where addresses are could help determine how many instructions are being fetched/executed by the SH4?... any other simpler checks I can run before that?

Thanks a ton in advance @analogRF!

[brainstorm]

Poking a bit more on the WAIT signal for the flash chips, I'm quite convinced that it is stuck in a "boot loop". It shows a static pattern followed by a few bursts and rinse and repeat... another user of this forum has sent me a video where the same signal goes through very varied stages/patterns during boot (for a healthy/working unit).

So yes, it could very well be a corrupted firmware (or Flash IC) issue... if I connect the CF there's exactly the same effect, so there's that.

@AnalogRF, do you know why there are two flash chips on board? One for emergency bootstrap and the other for the full application? I'm thinking on building a fitting socket for that 256P30 BGA IC for my FlashCAT and try to dump the firmware from there, sounds like a reasonable next step to you or you'd try something else?

[analogRF]

Poking a bit more on the WAIT signal for the flash chips, I'm quite convinced that it is stuck in a "boot loop". It shows a static pattern followed by a few bursts and rinse and repeat... another user of this forum has sent me a video where the same signal goes through very varied stages/patterns during boot (for a healthy/working unit).

So yes, it could very well be a corrupted firmware (or Flash IC) issue... if I connect the CF there's exactly the same effect, so there's that.

@AnalogRF, do you know why there are two flash chips on board? One for emergency bootstrap and the other for the full application? I'm thinking on building a fitting socket for that 256P30 BGA IC for my FlashCAT and try to dump the firmware from there, sounds like a reasonable next step to you or you'd try something else?

frankly i dont know how the flash mem is structured but since the full FW is always boots from the CF card
my understanding is that the flash chips only have some kind of bootrom in them (which is either the same thing as bootstrap or bootstrap is just part of it) Those flash chips were updated in one of the older firmwares I remember but after that the update is always included in all FWs and unit will check if the bootstrap needs updating. The reason there are two chips, my guess is that they needed a larger flash and perhaps at that time
having two smaller chips were cheaper?! with the way they are marked and coded, it seems that the content of one is continuation of the other.

But those are BGA chips, how do you want to dump them by removing them??!
I would never do that, never but that's just me.

Try to find a jtag or UART on the board maybe that will help. there are a few suspect connectors on the board although 2 of them are very likely the jtag for FPGAs but I think there is one that might be a uart or jtag for the Flash chips. Generally Anritsu devices that i have worked on (bench top or handheld) dont have UART (or it is not enabled by default) but jtag sometimes can be found available...

the problem you are describing still very much looks like the memory (RAM) issue that I had some time ago...the symptoms were very similar to what you describe although I didnt do that much deep measurements as you have but i did measure "bad looking" signals on the memory chips
and started changing them randomly (starting from the bottom) and after the second chip the unit came back to life...maybe with deeper dive you can even pinpoint which memory it might be, i just had a strong suspicion by the general look of the signals on the data lines..changing those chips is relatively easy...maybe you have already done that?


as a general rule, I have come to the conclusion that when an instrument stops so early in the boot process, usually (i am not saying always) my first suspect is the RAM and then the bootrom wherever it is. this has been the case in multiple occasions in various instruments at least for me...

[brainstorm]

Replying "inline"...

frankly i dont know how the flash mem is structured but since the full FW is always boots from the CF card
my understanding is that the flash chips only have some kind of bootrom in them (which is either the same thing as bootstrap or bootstrap is just part of it) Those flash chips were updated in one of the older firmwares I remember but after that the update is always included in all FWs and unit will check if the bootstrap needs updating. The reason there are two chips, my guess is that they needed a larger flash and perhaps at that time
having two smaller chips were cheaper?! with the way they are marked and coded, it seems that the content of one is continuation of the other.

Yeah, good call, two flash chips to hold all the firmware in series makes sense... I guess I'd have to locate and flash only the section from the updates/firmware that does the bootrom part on those chips, not too hard to locate with radare2/ghidra (after the analysis I did already on my blogposts a while ago).

But those are BGA chips, how do you want to dump them by removing them??!
I would never do that, never but that's just me.

I have a FlashCAT Mach1 with some adapters: https://www.embeddedcomputers.net/products/FlashcatUSB_Mach1/

I already dumped flash TSOP56 flash chips successfully in the past, but certainly not BGA (yet). After a brief email exchange with the FlashCAT author, those chips will only require a slight modification on top of the BGA sockets he already has on store, so win-win: he gets a newly supported socket, I gain the capability to read those.

Try to find a jtag or UART on the board maybe that will help. there are a few suspect connectors on the board although 2 of them are very likely the jtag for FPGAs but I think there is one that might be a uart or jtag for the Flash chips. Generally Anritsu devices that i have worked on (bench top or handheld) dont have UART (or it is not enabled by default) but jtag sometimes can be found available...

Fair enough, I can try that before going hardcore with the BGA chips... there are a few quite beefy connectors on the board, I'll have to study pinouts, datasheets and see what I can do, thanks for the tips! If you already traced those as part of your job/repairs (or have an informed guess), please do share, that'd save me a ton of work!

the problem you are describing still very much looks like the memory (RAM) issue that I had some time ago...the symptoms were very similar to what you describe although I didnt do that much deep measurements as you have but i did measure "bad looking" signals on the memory chips
and started changing them randomly (starting from the bottom) and after the second chip the unit came back to life...maybe with deeper dive you can even pinpoint which memory it might be, i just had a strong suspicion by the general look of the signals on the data lines..changing those chips is relatively easy...maybe you have already done that?

At this point I'd need to ask which RAM chips are you referring to? The 2 closer to the SuperH4 processor or the 6 SRAM chips at the edge of the board (top and bottom sides of the board)?

Yes, I've changed all of them already in the past (both types), but admittedly I could have butchered them via wrong temperatures of the hot air station and/or improper ESD protection of my gear (not a professional)... I'll definitely try to do better next time since I have access to higher quality equipment nearby my workplace.

I can definitely post a few pictures of some of the RAM (closer to the SH4 IC) and you get to judge them? Or are the 6 SRAM ICs at the edge more fault-prone? I really thought those 6 SRAMs were just for acquisition storage, not for executing code... to me it makes sense that the ones to be targeted first are the 2 closest to the SuperH4 processor since they seem better candidates to affect code execution (guessing)?

Thanks a ton again @analogRF, your input is invaluable!

[analogRF]

I was referring to the 6 ram chips on the bottom right corner. but yes the other two ram chips could also be the culprit
even though you have replaced them to be honest they are still the first suspect for me

I just had another look at the FW and actually there appears to be no bootstrap (or bootrom) code in there. I think it was
included in some earlier FWs or maybe that part is not really programmed by FW update process and different versions
that I have seen were just different out of factory. In any case I doubt that taking the BGA chips out and programming them
would be successful really and you dont have the content anyways. But I really doubt that flash chips are bad or corrupted
I would still bet on the ram chips. One other thing that might be worth investigating is that whether the CPU is trying to
communicate with a hardware and is not getting the response let's say such as the usb or lan etc...I had that issue in a S331E once
where the USB contrller was a separate chip and turned out to be defective preventing the cpu to continue to boot...not having a UART boot log
(common in many Anritsu instruments) makes it hard to diagnose...

[brainstorm]

JTAG for the SuperH4 processor identified and mapped out. Will connect a probe there next and try to enumerate/halt

[analogRF]

JTAG for the SuperH4 processor identified and mapped out. Will connect a probe there next and try to enumerate/halt

great work 
I just hope the debug interface is not disabled. Or at least if it is disabled, it can be enabled by moving some pull-up/down resistors on the board that can be identified (like in Keysight 3000A scopes)

by the way, can I ask how you identified the pins? just by tracing to the CPU pins?

I always suspected that empty pin header but never really dug into it...a lot of things now can be done through jtag 

[analogRF]

still a UART debug console would have been more useful at this point for troubleshooting but Jtag can also be useful to some extent
did you check for any UART port? such as P4000 pin header? or specially J5001 right next to the jtag header?

[brainstorm]

JTAG for the SuperH4 processor identified and mapped out. Will connect a probe there next and try to enumerate/halt

great work 
I just hope the debug interface is not disabled. Or at least if it is disabled, it can be enabled by moving some pull-up/down resistors on the board that can be identified (like in Keysight 3000A scopes)

by the way, can I ask how you identified the pins? just by tracing to the CPU pins?

I always suspected that empty pin header but never really dug into it...a lot of things now can be done through jtag 

Thanks! Just good old DMM continuity test and datasheet (page 11 of 1074): https://datasheet.octopart.com/HD6417750F167V-Renesas-datasheet-11770390.pdf

Also the GND row was an immediate giveaway, all JTAG connectors seem to have that ground row to interleave with the signals for better signal integrity and avoid coupling.

I'm a bit concerned about its real utility though since there's that weird non-JTAG signal (ASEBRK/BRKACK) from Renesas H-UDI proprietary (debug) protocol (https://www.farnell.com/datasheets/1513948.pdf)... in the datasheet they say that they implement a "subset of the IEEE 1149.1 JTAG standard" but in renesasrulz.com there are empty threads of users not able to operate the JTAG at all (as it was normal/standard JTAG), we shall see... if you have a $1500 E10A-USB or E20 "emulator" Renesas probe, can you connect it there and let me know?

Thanks for the hint of the serial header on P4000, I'll definitely poke that too!

By J5001 I guess you mean J50014? I suspect that's a superset of the JTAG connector that supports these Lauterbach probes?: https://www.lauterbach.com/frames.html?pro/pro_sh7047f_alt01.php

[analogRF]

i am not an expert on this matter but I dont think you need the Renesas emulator. Segger J-Link that I do my jtags with and is excellent, does support this cpu here and I dont think that extra pin needs connecting...

[brainstorm]

i am not an expert on this matter but I dont think you need the Renesas emulator. Segger J-Link that I do my jtags with and is excellent, does support this cpu here and I dont think that extra pin needs connecting...

Yeah, that's my hope, I have a Glasgow interface explorer, which should do for this usecase... I just probed the P4000 header with the oscilloscope, but I couldn't find any trace of serial activity or any waveform, just high at 3.3V on all the pins (except one GND). No activity during powerup/bootloop in any of the pins,  I suspect that it's too early in the boot process and not even the UART is initialized yet :-S

Could you please put your oscope probe there and let me know if you see anything?

[brainstorm]

the problem you are describing still very much looks like the memory (RAM) issue that I had some time ago...the symptoms were very similar to what you describe although I didnt do that much deep measurements as you have but i did measure "bad looking" signals on the memory chips
and started changing them randomly (starting from the bottom) and after the second chip the unit came back to life...maybe with deeper dive you can even pinpoint which memory it might be, i just had a strong suspicion by the general look of the signals on the data lines..changing those chips is relatively easy...maybe you have already done that?


as a general rule, I have come to the conclusion that when an instrument stops so early in the boot process, usually (i am not saying always) my first suspect is the RAM and then the bootrom wherever it is. this has been the case in multiple occasions in various instruments at least for me...

I just received fresh RAM chips... I see some jitter on some of the address lines, but I'm not sure if it's just a bad trigger setting or legit. How did you determine "bad looking" signals, @analogRF?

[analogRF]

the problem you are describing still very much looks like the memory (RAM) issue that I had some time ago...the symptoms were very similar to what you describe although I didnt do that much deep measurements as you have but i did measure "bad looking" signals on the memory chips
and started changing them randomly (starting from the bottom) and after the second chip the unit came back to life...maybe with deeper dive you can even pinpoint which memory it might be, i just had a strong suspicion by the general look of the signals on the data lines..changing those chips is relatively easy...maybe you have already done that?


as a general rule, I have come to the conclusion that when an instrument stops so early in the boot process, usually (i am not saying always) my first suspect is the RAM and then the bootrom wherever it is. this has been the case in multiple occasions in various instruments at least for me...

I just received fresh RAM chips... I see some jitter on some of the address lines, but I'm not sure if it's just a bad trigger setting or legit. How did you determine "bad looking" signals, @analogRF?

i think since it is not periodic signal it is hard to distinguish jitter. But what I clearly saw was (1) runt pulses with either top not reaching the HI or the bottom not reaching the LO level (2) pulses that were much narrower than they should be
if there was any jitter I could not distinguish...it is not periodic so I could not trigger on them...

[brainstorm]

Thanks, that makes sense, did not realise jitter does not matter as much when addresses (the pins I was probing: A0, A1, A2...) can just latch randomly.

While flipping the board on the table, I've noticed that the LAN91C111 IC (https://ww1.microchip.com/downloads/en/DeviceDoc/00002276A.pdf) was rather hot to the touch (not painful but uncomfortable)... thermal cam says 52C.

If you still have the board around, would you mind touching that IC on boot? It could be that this one is bringing rails down and triggering PWR_FAIL signal (which is high at 3.3V on my board).

[analogRF]

i dont have the board anymore but that is DEFINITELY a big find. Has there been any sign of water damage on the board?
the LAN chip should not be that hot...what if you let it run for like 5-10min and monitor temps?

I once repaired an anritsu S331E that could not boot and there was water damage on the board
I repaired the power supplies and they were all ok and it still could not boot until thermal camera
came in and told me that the the USB controller chip was about 55-60C but all voltages were ok
so I replaced that chip (unobtainable except from china) and it worked 
so why dont you also try to probe around that chip...
cpu getting to 50-55C maybe is ok but the lan chip ?? I dont think that's normal at all....specially when it is not connected to ethernet

I now suspect the FW is stalled because at one point it must initialize the LAN interface and it can't ...

[brainstorm]

Fortunately that IC is really cheap and seems like it's obtainable

After running for 5min the temperature stays stable at 53C at 14V and 300mA... that's a bit more than 4W and it seems that it might be taking almost all of the current state's power budget since all other ICs are hovering 30C

Thanks for the hints and experience with those things! I think test some of the pins (any recommendations on what I should see?).

I think I'll order one of those LAN91C111 anyway and replace, looks like a winner... I hope no other passives around it are toasted and/or cause it to fail that way.

[analogRF]

Fortunately that IC is really cheap and seems like it's obtainable

After running for 5min the temperature stays stable at 53C at 14V and 300mA... that's a bit more than 4W and it seems that it might be taking the power budget since all other ICs are hovering 30C

Thanks for the hints and experience with those things! I think test some of the pins (any recommendations on what I should see?).

I think I'll order one of those LAN91C111 anyway and replace, looks like a winner... I hopve no other passives around it are toasted and/or cause it to fail that way.

Absolutely looks like  a winner. I would definitely change it with no hesitation.That temp and power consumption is not normalfor that chip. Looks very similar to what had happened in my case to the usb controller chip. For signals i dont know, you can look the datasheet and pick some pins that you can guess what they should look like...i think cpu is trying to communicate with it and isnot getting the proper response back

[fenugrec]

I'm on the edge of my seat reading this, and I don't even own one of these !

Unfortunately that SH4 cpu doesn't have the "AUD" debug interface that the older / smaller SH2 devices have, which can be used to view PC value on every branch/call - useful to find out if it's looping a small section of code...

That ASEBRK pin doesn't look like it should interfere with JTAG ? datasheet says "leave open" when not using an emu.
Were you able to look at the reset code on this thing or is it still part of that undumped flash BGA ? I quickly checked the STBCR registers and not sure if it's possible to disable the HUDI module at all, but if so : you can look at early-early boot code (I'm talking reset vector) to see if it's soft-disabled.

[brainstorm]

I'm on the edge of my seat reading this, and I don't even own one of these !

Unfortunately that SH4 cpu doesn't have the "AUD" debug interface that the older / smaller SH2 devices have, which can be used to view PC value on every branch/call - useful to find out if it's looping a small section of code...

That ASEBRK pin doesn't look like it should interfere with JTAG ? datasheet says "leave open" when not using an emu.
Were you able to look at the reset code on this thing or is it still part of that undumped flash BGA ? I quickly checked the STBCR registers and not sure if it's possible to disable the HUDI module at all, but if so : you can look at early-early boot code (I'm talking reset vector) to see if it's soft-disabled.

Thanks for joining into this repair party

After seeing that the network IC was that hot I decided to order it and wait for it to come on the mail, which should be just a few weeks away now (just picking my battles and allocating time accordingly here )... I still have to poke at its signals and see if it's really misbehaving.

I'd really like to try that IC swapping first and if that fails, I'll go down the JTAG rabbit hole. @fenugrec, if you have working OpenOCD configs for that SH4 processor, hints or other suggestions I can readily use, I'd be happy to incorporate them as part of this journey.

IIRC from https://blogs.nopcode.org/brainstorm/anritsu-ms2721b-spectrum-analyzer-repair-part-2/, there was early boot(loader?) code on those binaries and check out the reset vector, so I could also see if there are further pre-Application/Usercode JTAG/debugging facilities. The debug options that are available once the user code is running are astonishingly helpful, btw, check the blogpost out... thinking out loud and getting ideas on which flanks to attach first as I go, thanks for chiming in

[fenugrec]

After seeing that the network IC was that hot I decided to order it and wait for it to come on the mail

I think it's a good next step. Although looking at the DS, it says it can draw "up to 140mA" ? on 3.3V right ? that's a fair amount of power, probably only in certain cases, but if the CPU is leaving that IC in a weird state (or spamming some function inside it that draws more power) it could be another wild goose.
How about removing it altogether in the meantime ? See if that affects the boot sequence at all ?

if you have working OpenOCD configs for that SH4 processor

Sorry, haven't much to add. HUDI/JTAG wasn't easily accessible on the board I worked on but AUD was, and that provided what I needed.

JTAG should give you at least boundary scan according to the DS... Is it realistic to write some massive bitbanging code to read the external memory that way ?
Otherwise I'm not sure what else it provides if there's no support code in the fw...

The debug options that are available once the user code is running are astonishingly helpful

Oh do you still have access to the vxworks console ?
IIRC you can even load + run arbitrary code that way, right ?

[brainstorm]

Hi folks, I've started a new thread on this over:

https://www.eevblog.com/forum/repair/anritsu-ms2721b-component-level-repair/new/#new

Since I think that the topic does not reflect what's going on with my instrument anymore, I hope you don't mind?

@analogRF and @fenugrec, please subscribe over there for further updates

[brainstorm]

After seeing that the network IC was that hot I decided to order it and wait for it to come on the mail

I think it's a good next step. Although looking at the DS, it says it can draw "up to 140mA" ? on 3.3V right ? that's a fair amount of power, probably only in certain cases, but if the CPU is leaving that IC in a weird state (or spamming some function inside it that draws more power) it could be another wild goose.
How about removing it altogether in the meantime ? See if that affects the boot sequence at all ?

if you have working OpenOCD configs for that SH4 processor

Sorry, haven't much to add. HUDI/JTAG wasn't easily accessible on the board I worked on but AUD was, and that provided what I needed.

JTAG should give you at least boundary scan according to the DS... Is it realistic to write some massive bitbanging code to read the external memory that way ?
Otherwise I'm not sure what else it provides if there's no support code in the fw...

The debug options that are available once the user code is running are astonishingly helpful

Oh do you still have access to the vxworks console ?
IIRC you can even load + run arbitrary code that way, right ?

So I removed the IC but unfortunately little has changed... I do need to go through the JTAG rabbit hole it seems because the screen is not giving any hints whatsoever :_S

Please do tell me more about that AUD support you worked with, sounds you have experience with SuperH4 targets (and possibly debug probes/equipment I could borrow? )

I do wish I still had access to the vxworks console, unfortunately that's not the case anymore since it fails very early in the boot sequence, no telnet access is feasible... for now... stay tuned on the new thread

[radef]

However, the only problem that I have right now is that the tracking generator option is nowhere to be seen 
my instrument passes all self tests and works perfectly but the tracking gen is not anywhere...

Did you have any luck getting the tracking generator option to reappear?

[analogRF]

However, the only problem that I have right now is that the tracking generator option is nowhere to be seen 
my instrument passes all self tests and works perfectly but the tracking gen is not anywhere...

Did you have any luck getting the tracking generator option to reappear?

it's been a long time since then...yes, I got a destroyed main board from a ms2721b with TG, and transferred its EEPROM chip to mine and then changed the S/N in service menu

[radef]

it's been a long time since then...yes, I got a destroyed main board from a ms2721b with TG, and transferred its EEPROM chip to mine and then changed the S/N in service menu

Excellent - thank you. I'm in a similar situation and this helps with my plan of attack. 

[nexus]

Hi All,

Reviving this thread bc I also am working on an MS2721B and encountered what I believe to be a firmware related issue.

I had my MS2721B opened up to repair an intermittent LO1 unlock. This issue is common with the VCOs in the SA due to cold solder joints. I was able to touch up the solder in and around the VCO and fixed the LO1 unlock issue. I had the instrument running for a while and checked the SA and TG operation. Everything was working fine.

I checked the FW version and it was 1.32. I saw on the Anritsu website that the latest FW is 1.51. I downloaded the USB thumb drive installer, prepped a new flash drive, and put the firmware package on the thumb drive. I put it in the instrument and followed the instructions as per the firmware update manual.

The instrument began with copying the files, then it was on the "Operating system loading" page for a while. I thought perhaps the instrument is just slow and takes a while, so I left it alone overnight.

In the morning, it was just on the initial "Anritsu" boot screen with no loading bar present. It must have been sitting there for hours. I pressed the power button and it turned off normally. I tried turning it back on again, and it just kept flashing the white "Anritsu" screen and turning off. It does this perpetually; the "Anritsu" screen turns on for 1 second, then goes black for a second, then on again.

I opened the unit up again and removed the firmware CF, just to try powering on. It does the same exact thing with or without the CF installed.

I ordered a CF reader since I don't have one, as well as a few NOS 512mb CF cards.

What should the unit do without the CF installed? I downloaded Anritsu Master Software Tools and I tried the "1-3-5" key combo on power up as well, the unit does not respond to this. Are there any other boot sequences or key combos I can try while I wait for a CF reader? Anyone else had this issue before?

Also, if anyone has a CF OS image they could share for reference, that would be great as well. I'm not 100% clear on what the contents of the CF should be, if I were to try and format it in my PC before reinstalling in the unit.

[analogRF]

most likely this is a hardware issue. I have had a number of of these with FW problem and I have never seen this blinking splash screen. Besides it must respond to the bootstrap mode booting (1-3-5 key) otherwise even the bootloader is not running which has nothing to do with the CF card. If you boot with a blank CF card you can still go to bootstrap mode (I have done it and so did Shahriar I think). So I think it must be a hardware issue. Maybe that HW issue was there before you upgraded and even though the unit was "working" with the old FW, but when it came to upgrading FPGA's or the fash memory, it failed and got stuck.

As for the  content of the CF card, it is just the unpacked FW, that's it. Nothing else. If you just unpack the FW file on a blank CF card (FAT format) it works
However the version must match with what is residing on the flash memory on the board and also the fpga's, therefore you still need to use MST software to load the FW into the unit or it wont boot on its own (unless you had the right FW unapacked on the CF card).

my advice is that the best and safest way to upgrade these old units is to use MST software (LAN connection) Even if it fails, and it sometimes does, it is easily recovered by MST on the next try. USB method of upgrading is faster but is not really reliabel on these old instruments. Newer models like s331/332e ms2712E etc....are fine.

[nexus]

I see. I can't believe the thing would suicide if it was working before just because of a bad firmware update. I'm sure the files I downloaded and the flash drive were not corrupted.

One thing I could try maybe is to load FW 1.32 onto the CF from my PC and see if it will boot even with old fw. I did not copy the CF before the update, but hopefully 1.32 is online somewhere.

If it is not reaching the bootloader, is it truly borked? I'm not sure which HW components are updated between fw 1.32 and 1.51. Does it actually update CPLD, FPGA, or other software driven devices besides main fw between these versions?

[nexus]

Also, what should the behavior be if there is no CF installed on power on? Which screens, etc does the unit show?

[nexus]

Assuming that the onboard flash is corrupt ( 2 x (RC28F256P30B85)), would trying to get these ICs from a parts unit be a good strategy? Perhaps the non-corrupt chips could be read and new copies could be programmed?

I can find new ones on eBay: https://www.ebay.com/itm/334463856043?hash=item4ddf996dab:g:gXcAAOSwvrRfvcFu
Plus stencils: https://www.ebay.com/itm/193122926047?var=493309027882

Has anyone been able to read or successfully transfer images from these ICs? I see that there were two versions of firmware stickers on mine. Not sure if it went back to Anritsu at some point and was updated.

Also, my ethernet IC was also 50C + like another person had experienced. I removed it but the unit's behavior has not changed. Nothing else sticks out on thermals.

Remember that this unit was fully operational before the attempted firmware update that killed it. I would hope that if it is as simple as corrupt flash, then salvaging the image from another analyzer and replacing the bad memory could fix it.

[nexus]

Ethernet controller getting hot. Now removed but no changes.

[analogRF]

Ethernet controller getting hot. Now removed but no changes.

no that chip always gets too hot. it's normal

[analogRF]

Assuming that the onboard flash is corrupt ( 2 x (RC28F256P30B85)), would trying to get these ICs from a parts unit be a good strategy? Perhaps the non-corrupt chips could be read and new copies could be programmed?

I can find new ones on eBay: https://www.ebay.com/itm/334463856043?hash=item4ddf996dab:g:gXcAAOSwvrRfvcFu
Plus stencils: https://www.ebay.com/itm/193122926047?var=493309027882

Has anyone been able to read or successfully transfer images from these ICs? I see that there were two versions of firmware stickers on mine. Not sure if it went back to Anritsu at some point and was updated.

Also, my ethernet IC was also 50C + like another person had experienced. I removed it but the unit's behavior has not changed. Nothing else sticks out on thermals.

Remember that this unit was fully operational before the attempted firmware update that killed it. I would hope that if it is as simple as corrupt flash, then salvaging the image from another analyzer and replacing the bad memory could fix it.

I assume you are sure there is (was) no LAN connection and also bootstrap mode didnt work, right?
if that is the case, I can only assume the flash is corrupted. I am sure anritsu has a way of writing them in place
but since we dont know how, copying from a working flash or replacing the flash chips with working ones should work.

My understanding is that the bootloader resides on those flash memories, so if it is not starting, they are corrupted during the update.
unless there is a hardware failur that just happened during the update even though the unit was ok before.
so make sure all voltages on all the chips are present.

IIRC the unit with no CF card will just sit on the Anritsu logo screen
I have one laying around here, I will take out the CF card and see what happens but I am pretty sure it just sits idle on the splash screen

[nexus]

understood, thank you for confirming this

Ethernet controller getting hot. Now removed but no changes.

no that chip always gets too hot. it's normal

[nexus]

I assume you are sure there is (was) no LAN connection and also bootstrap mode didnt work, right?
if that is the case, I can only assume the flash is corrupted. I am sure anritsu has a way of writing them in place
but since we dont know how, copying from a working flash or replacing the flash chips with working ones should work.

My understanding is that the bootloader resides on those flash memories, so if it is not starting, they are corrupted during the update.
unless there is a hardware failur that just happened during the update even though the unit was ok before.
so make sure all voltages on all the chips are present.

IIRC the unit with no CF card will just sit on the Anritsu logo screen
I have one laying around here, I will take out the CF card and see what happens but I am pretty sure it just sits idle on the splash screen

I tried recovery mode with no connections, with LAN, and with USB all separately. No changes in that respect.

I see some parts units on eBay. If they are not missing the flash chips I will try getting one of those for cheap.

Interestingly, once in a while the unit will just sit at the splash screen. No green bar or other text, just "Anritsu" white screen without blinking. This is with no CF.
Maybe once I get a CF reader and can unpack and load FW, perhaps it may be able to keep booting. Would be interested to know what your good unit does with no CF.

I wonder if the "1-3-5" recovery mode should be accessible without CF installed?

[analogRF]

ok I was a little wrong but not by much  . Without CF card in the unit, this is what I get (see the pictures)

The fault red light is always on. After turning on, the boot process is exactly like normal and right after the brief selftest message at the bottom
the unit gets stuck at the image shown here complaining about OS. But up to this point it behaves exactly like normal.

1-3-5 bootstrap mode works exactly as normal. It does not care about CF card at all. It is also able to connect to LAN and I can see it on MST software

[analogRF]

so, except for any other hardware fault (RAM, power rails, etc...), I think most likely your flash memories are corrupted in a "bad" area which prevents the bootloader from running.
Possibly the upgrade was updating the bootloader and something went wrong during that period...

[nexus]

Copy that; thank you! I'm going to see if I can find a cheap parts unit or main board online. Hopefully replacing the flash chips should restore bootloader function.

Let this be a lesson; do not update using the thumb drive application! 

[analogRF]

be very careful about part units on ebay (all of them but particularly those from alltest)
most of these have all of their memory chips (of all kinds even SDRAM) and sometimes even their FPGA and CPU cut off from the board by cutters

[nexus]

Yup, I saw that alltest has a few for sale. The ICs they indicated as removed (well, more like ripped off brutally) were the SDRAM chips on the top side.

I asked them if the two chips of interest are still on the board.

[nexus]

BTW if anyone has a parts unit or a motherboard laying around feel free to PM me

[nexus]

Update

I bought a parts MS2721B from alltest that had the suspect flash ICs with the bootloader on them.

I also bought a Xgecu T48 universal flash programmer with the BGA64 socket.

I removed both BGA flash IC's from the parts unit, popped them into my programmer. Downloaded the contents from the flash and saved them. (I will post the flash contents on my website (neonkev.com), but if you need sooner please PM).

I then removed the flash ICs from the bricked unit. First, I read and compared the contents to the "good" parts unit. Indeed they were different.

So I erased flash from corrupted unit, and reflashed them with the contents I grabbed from the parts unit.

Reballed the BGAs, put them back on the board, and viola! Unit was able to reach bootstrap.

I use Anritsu MST to do an emergency recovery over LAN to reinstall OS. And everything is working again.

I learned a lot and it was a good experience. Hopefully if anyone else has a bricked bootloader, you can make use of this.
Of course, BGA reballing isn't the easiest type of soldering, and you need to spend some $$$ on the programmer. So not a quick fix.. but once you have the tools, the next repairs will only cost you time

[zeaman]

I was able to revive my MS2721B today. (SDRAM removed , NO CF connector, 3/6 SRAM taken off with pads, no CR1225 battery holder)

The last problem was that it was stuck forever with message "Application is running!" (input : 700mA @ 15V).

From the log it looks that the problem happened right after loading DSP memory. (see telnet log file attached)
I carefully checked all 6 SRAM chips (I replaced 3 of them) and found unsoldered SRAM address pin.  After fixing that I saw my input current jumped to 1.4-1.6A @15V  and in 20 sec I've got the functioning screen.  There was a warning once on  the bad EEPROM first time it loaded.

[Ko]

Could someone advise me about the option installation?
Recently I got a ms2721b without TG option and broken ms2721b w/ TG.
I move this TG into first ms2721b.
But TG couldn’t be enabled on this ms2721b which might not have configuration of the TG.
Can I enable TG w/ some method?
It is very helpful for someone to teach it.

[Ko]

Could someone advise me about the option installation?
Recently I got a ms2721b without TG option and broken ms2721b w/ TG.
I move this TG into first ms2721b.
But TG couldn’t be enabled on this ms2721b which might not have configuration of the TG.
Can I enable TG w/ some method?
It is very helpful for someone to teach it.