Anritsu MS2721B internal CF card missing

[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.