O2 motherboard repairs

[ruckusman]

Board #2:...

Now, using my not at all cursed TSOP32 to DIP adapter, I proceed to dump the IC with a TL866 programmer:

View attachment 3724


View attachment 3728

Did you have to rewire (torture) the TSOP32 to DIP adapter to get the pin mapping of the programming socket to coincide with the pin mapping that the software is expecting.

For reference Google Gemini just use the ADP-F48_EX-1* adapter, but that is not an option able to be selected in the software - see my screenshots below.

Recall that I'm 80%+ the way though designing/building an adapter to program the AT29C040A without having to desolder it, which means I need a suitable adapter at the programmer end - the TSOP48* is my preference due to space.

I've just received the T48 (TL866-3G) but need to get a suitable and appropriate adapter - TSOP48 got both the ADP_F48_EX-1 and ADP_F48_EX-2 with the package - I should have verified this in the software first.

But at least I have held off ordering what would have been potentially useless and not at all cheap boards from JLCPCB - phew!

For TSOP32 -> DIP32 adapters:
There is a dedicated one which is only TSOP32 -> DIP32, space is tight and it is quite expensive in comparison to most of the other adapters.

I am now thinking that I should bypass the TSOP48 socket and my adapter in that socket altogether - it was a good learning exercise and cost nothing.

And go straight via FFC cable connectors to DIP32 - like these to possible routing solutions

This is effectively what you have achieved with your adapter rewiring, except that you have an already desoldered chip and TSOP48 socket - correct?

Or like this routing, it doesn't really matter which, except perhaps from a simplicity perspective re: routing - TBD

 

[sdz]

Besides the dysfunctional behaviour of that Dallas chip - Atmel PROM data corruption is emerging as a prime suspect in the non-functioning Mobo category.

I've got a solid red Mobo here, I think that's going to have to be my entry point in diagnosis, the Ateml PROM

From the previous MBs, solid red light doesn't sound like a corrupted PROM.

Did you have to rewire (torture) the TSOP32 to DIP adapter to get the pin mapping of the programming socket to coincide with the pin mapping that the software is expecting.

Indeed, I got the wrong adapter

Recall that I'm 80%+ the way though designing/building an adapter to program the AT29C040A without having to desolder it, which means I need a suitable adapter at the programmer end - the TSOP48* is my preference due to space.

Nice! I made an adapter that plugs in place of the Dallas IC, two FFCs soldered where the flash IC is, with a TSOP 32 socket on top and a socket for the relocated Dallas IC.

This is effectively what you have achieved with your adapter rewiring, except that you have an already desoldered chip and TSOP48 socket - correct?

Yes.

I am now thinking that I should bypass the TSOP48 socket and my adapter in that socket altogether - it was a good learning exercise and cost nothing.

And go straight via FFC cable connectors to DIP32 - like these to possible routing solutions

Do you mean leaving the flash IC on the MB, and then connecting the needed signals to the programmer?

 

[ruckusman]

Hmm - solid red may means something more dire, kaput PROM or something even worse.

The adapter ecosystem around the Xgecu programmers is vast, but so many of the adapters are quite specific, or schematic/pin mappings are either absent, indecipherable or type specific - nothing that I could locate in the software anyway.

Instead I bit the bullet on two cheaper adapters, one which I can solder the FFC connectors to directly, the other with a TSOP48 socket.

I made an adapter that plugs in place of the Dallas IC, two FFCs soldered where the flash IC is, with a TSOP 32 socket on top and a socket for the relocated Dallas IC.

That sound to be a very simple solution, so you've got the FFC soldered to the board, the Atemel socketed, can be easily removed for programming I assume and the Dallas elsewhere out of the way...impressive.

Do you mean leaving the flash IC on the MB, and then connecting the needed signals to the programmer?

Yes.

My plan is to revive a Mobo, or Mobos, hopefully with a PROM re-flash, but I when I devised this idea of flashing the Atmel in place, it was with a view to getting the PROM mods done for the RM7900 without sacrificing Mobos - PROM mods (experimental) could brick a board easily.

Other elements are, PWR_ON jumper (same as pressing the power button) able to be activated externally from the cable connections to the programmer, and the reset button (switched = kept depressed) which should be able to keep the CPU and the rest of the system on, but inactive, in reset, which should allow the programmer signals to avoid collision with the other IC's that would be attempting to read the PROM.


Your solution actually achieves that by the sound of it, makes mine look over-engineered.

 

[siliboi]

very nice ill have to check my two solid reds for that defect

 

[sdz]

@ruckusman @siliboi
For solid red, I'd first check the power rails, CPU connectors, main 133MHz oscillator and the general CRIME area.

@ruckusman
Keeping the system in reset while writing to the FLASH IC might work nicely (if MACE keeps its IOs in high-Z)

 

[ruckusman]

CPU connectors are good candidates as something that went from working to non-booting whilst on the shelf doesn't really point to component failure.


For the flashing, there was the, not really feasible, possibility of flashing it with the system unpowered, but there would have been a lot of parasitic voltage losses on the power rails - I've set it up to be able to keep the power rails from board and programmer unconnected.

Hopefully MACE does keep it's nose out of it.

 

[mapesdhs]

Just a quick mention, please feel free to send me any files you'd like to be included on my Depot downloads page, along with relevant descriptions. I don't use Discord, especially not after their recent changes.

sdz, would an R10K/175 module be of any use?

Ian.

 

[sdz]

@mapesdhs I'll prepare some things and send them!

The 175MHz R10k would be useful for documenting how it's set up/dumping the FPGA bitstream (moving that to the 150MHz R10k will likely allow it to run at 175MHz, since it's a 180MHz R10k CPU inside)/or if it's broken, document what, if it can be fixed etc.