De-Suicding SSF2T USA Blue Board

PCB problems and fixes
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

Well, I've had very good luck with resurrecting boards, and have helped out others that ran into snags, particularly with the -4 boards. Here, I've run into a brick wall with my SSF2T USA blue board, though.

I wiped the encryption key on this board, to do some testing with decrypted rom sets. I'm now try to get it back to native battery/encryption operation and having no luck.

Below is everything I've done, just to rule out foolishness on my part:

After wiping the encryption key, I re-installed the battery and original roms.
Tested with Raz's suicide tester, and confirmed it was suicided
Reprogrammed board with "SSF2TU" key on Arduino
Booted game to white screen. Power cycling, I get white, green or orange.
Re-checked with Raz's suicide tester, booted to white screen (I believe this is expected, if there is an encryption key present?)
Made sure all roms are seated
Verified original roms against MAME rom set, with GQ-4x4 programmer (all verified)
Tried programming encryption keys for "SSF2T" and "SSF2XJ", with same result as above - game boots to white/green/orange screen, suicide tester boots to white/green/orange screen
Metered many things - power to board while programming decryption key, power to board while testing game, all ground continuity paths, battery voltage, up through EXC1 near roms 03-10 (good at around 3.4V - 3.6V along the entire path), some other things
Re-installed decrypted roms and wiped encryption key again, to ensure I hadn't buggered the board somehow - it booted into the game and played fine
Rinsed and repeated with the suicide tester testing and re-programming the encryption key

I'm wondering if the encryption key that the arduino is uploading for "SSF2TU" is correct. Below is what appears in the Arduino software from Arcade Hacker:

const unsigned char key_value_148[] PROGMEM = { 0x01,0x00,0x02,0x40,0x00,0x08,0x70,0x43,0x80,0x00,0x00,0x13,0xF0,0xA3,0xB8,0xC9,0x02,0x45,0x7C,0xA4}; //ssf2tu

If this helps at all for comparison, this is what MAME source shows that the key is:

"ssf2tu", { 0x5d90c86f,0xd030eb68 }, 0x400000 }, // 0838 0007 2000 btst #7,$2000
Last edited by NoAffinity on September 9th, 2017, 11:35 pm, edited 1 time in total.
User avatar
Pythagoras
Posts: 24
Joined: July 16th, 2017, 12:16 pm
Location: Sweden

Re: De-Suicding SSF2T USA Blue Board

Post by Pythagoras »

NoAffinity wrote:I'm wondering if the encryption key that the arduino is uploading for "SSF2TU" is correct. Below is what appears in the Arduino software from Arcade Hacker:

const unsigned char key_value_148[] PROGMEM = { 0x01,0x00,0x02,0x40,0x00,0x08,0x70,0x43,0x80,0x00,0x00,0x13,0xF0,0xA3,0xB8,0xC9,0x02,0x45,0x7C,0xA4}; //ssf2tu

If this helps at all for comparison, this is what MAME source shows that the key is:

"ssf2tu", { 0x5d90c86f,0xd030eb68 }, 0x400000 }, // 0838 0007 2000 btst #7,$2000
The key values you got from the Arduino software are correct for "SSF2TU". I have verified this by decrypting the roms and the key also works in Mame.

Did you burn the Phoenix Edition on the original eproms? In that case check if the decrypted roms pass the rom check. Just to rule out problems with the eproms or burning process. But it should work since you verified them already against Mame. Very strange. :mad:
User avatar
leonardoliveira
Please Continue...
Posts: 692
Joined: August 30th, 2012, 5:53 am
Location: Brazil
Initials: leo

Re: De-Suicding SSF2T USA Blue Board

Post by leonardoliveira »

Just commenting, I noticed a lot of people have problems with programming the keys correctly at boards with the programming pins at CN2.

The encryption logic at the SPA chip doesn't check what is being input as the hardware which receives the data is just latches and counters, it will store wrong data. Meaning that if the wires are connected in wrong order the board may store erroneous data.
Image
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

Thank you for verifying that. I did not modify the original roms. I burnt decrypted roms on spares and set the originals aside. I guess I can try burning a whole new set with original code. Possibly one of the original roms had gone south but is still testing good on the programmer.

As for the specifics of desuiciding, i am powering the board through cn7. I connect 5v to a25 and ground to a23 and b23. I measure 5v between the pins on the solder side once I apply power to the board. I connect the arduino cable to cn2 per the AH instructions, have re checked that about 10 times now. I ground from cn2 c32 to the arduino ground and have confirmed continuity from the arduino ground to my power supply ground. Anything look weird there?

My only other thought - is it possible that the sram that holds the encryption key or possibly the encryption controller, have gone bad? There have been a couple instances I've read, specifically these -4 boards where no matter what folks do, they cannot get the board to desuicide.
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

Figured I'd post pics of the data cable from Arduino to CN2. I'm doing exactly what the instructions say:

CN2 interface pins:
DATA Arduino #2 → CN2 A32
SETUP1 Arduino #3 → CN2 A30
CLOCK Arduino #11 → CN2 A31
SETUP2 Arduino #12 → CN2 A29
CN7 power pins:
+5V Power supply → CN7 A25
GND Power supply & Arduino GND → CN7 A23
GND Power supply & Arduino GND → CN7 B23

I also noticed a resistor between CN2 A32 and C32, on the solder side. Looking at the component side, A32 goes off somewhere on the board, presumably the capcom custom with the sram that holds the encryption key. C32, however, doesn't appear to go anywhere. But, now as I'm typing, I recall that I tested continuity from Arduino ground to power supply ground, with a jumper between C32 and the arduino ground per the AH instructions, so clearly C32 is grounded via the board. I also tried lifting one of the legs of the resistor and programming the board without that connection between A32 and C32 - no joy. I know I've seen that resistor on other boards too. I pulled and tested the resistor - it is rated 4.6 k ohms with 5% tolerance, it measured at 4.64 k ohms.

Image
Image
Image
Image
User avatar
leonardoliveira
Please Continue...
Posts: 692
Joined: August 30th, 2012, 5:53 am
Location: Brazil
Initials: leo

Re: De-Suicding SSF2T USA Blue Board

Post by leonardoliveira »

I think you might have been power starving the B board. Solder the wires to the top side of the CN2 and connect them to the arduino. Then sit the B board on the A board normally as if you were going to play it. Turn your supergun on and let it power the A+B board combo.

It will boot to a white screen. Once you hit the program button on the arduino, the screen will fade as the arduino will hold the CPS2 in reset state during the key programming. If this is done correctly, once programming is complete the reset state will be removed and the game will boot properly.

The problem is that people are assuming that programming doesn't work with the B board attached to the A board and that is not true.
Image
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

leonardoliveira wrote:I think you might have been power starving the B board. Solder the wires to the top side of the CN2 and connect them to the arduino. Then sit the B board on the A board normally as if you were going to play it. Turn your supergun on and let it power the A+B board combo.

It will boot to a white screen. Once you hit the program button on the arduino, the screen will fade as the arduino will hold the CPS2 in reset state during the key programming. If this is done correctly, once programming is complete the reset state will be removed and the game will boot properly.

The problem is that people are assuming that programming doesn't work with the B board attached to the A board and that is not true.
Well that is pretty cool. I did that, and it did exactly what you said, but after the screen went dark and programming done according to the arduino, it went right back to a white screen. I powered off, disconnected the arduino, and powered on - white screen. Checked voltage at the JAMMA connector, with the B board on the A board - 5.20V. And at CN2 - 5.08V.
User avatar
copados33
Please Continue...
Posts: 538
Joined: March 20th, 2013, 1:30 pm
Location: Uruguay South America
eBay: psycho-q

Re: De-Suicding SSF2T USA Blue Board

Post by copados33 »

Well, if anything, the same thing has happened to my Marvel Super Heroes PCB which I suicided on purpose, I have tried many times to reinsert the keys with the arduino board, CPS B revision 93646B-4, also tried transplanting the masks and eproms to a 93646B-7 then repeat the proccess, same results.
User avatar
leonardoliveira
Please Continue...
Posts: 692
Joined: August 30th, 2012, 5:53 am
Location: Brazil
Initials: leo

Re: De-Suicding SSF2T USA Blue Board

Post by leonardoliveira »

There may be a problem with your arduino setup.

Make sure you check if the pins are actually toggling correctly. The board will only operate if the key is programmed correctly. There is no room for error. It's all or nothing on this case.

Don't worry, it doesn't damage anything if you try. But be aware that messing around aimlessly at other parts of the system you might break something.
Image
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

leonardoliveira wrote: Make sure you check if the pins are actually toggling correctly.
How do I do this?

I've used this setup to desuicide at least 20 boards and haven't changed anything on it. Not to say it didn't develop some issue on its own.
User avatar
leonardoliveira
Please Continue...
Posts: 692
Joined: August 30th, 2012, 5:53 am
Location: Brazil
Initials: leo

Re: De-Suicding SSF2T USA Blue Board

Post by leonardoliveira »

Have you successfully programmed key on boards with the CN2 instead of CN9?

The problem could be the wiring connected to wrong pins. Would work at CN9 but not at CN2.

Btw, just commenting. on boards with CN9 the pins at CN2 are connected to GND so don't try the pins as that could damage the AVR MCU on the Arduino.
Image
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

I have successfully programmed boards via CN2 and CN9. I re-wire the data connection every time I do a new board. I actually have 2 different sets of wiring for the different connectors - one harness with a continuous 5-pin connector that I use for CN9, and one harness of dupont cables for CN2 (this is the one in the pictures).

I am going to go to the next steps:

1) Re-upload the AH Arduino sketch to the Arduino, and try again
2) Program my spare roms with encrypted ST code, check if possibly a rom has gone south even tho they verify on my programmer
3) Program the spare roms with SSF2X:GMC encrypted code, try to convert it successfuly to SSF2X:GMC
4) If I have to get as far as step #3, and #3 works, then try the ST roms and ST key on SSF2X:GMC (rev -7) board

Any other thoughts or suggestions in the meantime?
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

I did #1 last night, with no improvement. #2, 3 and 4 is going to be a bit more time consuming, something I probably won't have time to sit done and run through start-to-finish until this weekend. Fingers crossed.
VectorGlow
Posts: 505
Joined: November 8th, 2008, 11:40 pm
Location: Wales, UK
eBay: realflight

Re: De-Suicding SSF2T USA Blue Board

Post by VectorGlow »

@NoAffinity - have you tried asking the developer, Eduardo Cruz? He has an account of this forum but also posts more elsewhere, here's his profile on Jammaplus:

http://www.jammaplus.co.uk/forum/member ... sp?PF=7133
Arcade game board repairer
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

VectorGlow wrote:@NoAffinity - have you tried asking the developer, Eduardo Cruz? He has an account of this forum but also posts more elsewhere, here's his profile on Jammaplus:

http://www.jammaplus.co.uk/forum/member ... sp?PF=7133
Thanks, VG. I did message Eduardo through these forums. I will try him through jammaplus.

I was able to do #2 last night, with no improvement.

I'm preparing to move to #3 and #4. Contemplating using a spare X-men vs. SF board that I repaired and de-suicided, as a guinea pig - program an incorrect key then repgrogram the correct key. To make sure the problem isn't at the arduino before killing any more ST/SX boards.

I'm also looking at picking up a board with battery corrosion, as a potential donor for a replacement decryption controller. If all of the above fails but the arduino is still working faithfully to programe encryption keys, and there's battery voltage getting to the decryption controller, then the issue has to be within that capcom custom, doesn't it?
User avatar
leonardoliveira
Please Continue...
Posts: 692
Joined: August 30th, 2012, 5:53 am
Location: Brazil
Initials: leo

Re: De-Suicding SSF2T USA Blue Board

Post by leonardoliveira »

I think you might have problems with the B board. Have you checked continuity of the key programming traces from CN2 to the CIF and SPA chips? If the traces are broken the key programming will never work properly.
Image
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

leonardoliveira wrote:I think you might have problems with the B board. Have you checked continuity of the key programming traces from CN2 to the CIF and SPA chips? If the traces are broken the key programming will never work properly.
Would the screen still go dark during the programming, if there were traces broken?

I will check them nonetheless.
User avatar
leonardoliveira
Please Continue...
Posts: 692
Joined: August 30th, 2012, 5:53 am
Location: Brazil
Initials: leo

Re: De-Suicding SSF2T USA Blue Board

Post by leonardoliveira »

one of the four wires which are used to program the board happens to be the board master reset signal. It's like a PC tower you hold the master reset button down. So that working, means you have three wires to check, not four lol.
Image
User avatar
NoAffinity
Posts: 386
Joined: January 8th, 2017, 3:46 pm
Location: Escondido, CA, USA
eBay: noaffinity
Initials: CSG
Contact:

Re: De-Suicding SSF2T USA Blue Board

Post by NoAffinity »

leonardoliveira wrote:one of the four wires which are used to program the board happens to be the board master reset signal. It's like a PC tower you hold the master reset button down. So that working, means you have three wires to check, not four lol.
Nice. I improved efficiency by 25% without even starting. 8-) What do the other 3 lines do? Is there anything to be learned by probing them?
User avatar
leonardoliveira
Please Continue...
Posts: 692
Joined: August 30th, 2012, 5:53 am
Location: Brazil
Initials: leo

Re: De-Suicding SSF2T USA Blue Board

Post by leonardoliveira »

It's a shift register design. Means you push the bits which form the key serially through one wire (CPS2_DATA), a second wire pulses every time you want the board to "gobble" a bit (CPS2_CLOCK) and the other two wires (CPS2_SETUP1, CPS2_SETUP2) put the board on the programming state and stay that way.

Basically programming will only be successful if all four wires are connected correctly. A oxidized trace would count as if one of the wires were not connected.
Image
Post Reply