| Products > Test Equipment |
| Anritsu MS2721B internal CF card missing |
| << < (10/18) > >> |
| 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:
--- Quote from: brainstorm on October 05, 2021, 11:56:49 am ---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? --- End quote --- 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"... ;) --- Quote ---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. --- End quote --- 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). --- Quote ---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. --- End quote --- 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. --- Quote ---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... --- End quote --- 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! ;) --- Quote ---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? --- End quote --- 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 :) |
| Navigation |
| Message Index |
| Next page |
| Previous page |