Anritsu MS2721B internal CF card missing

[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