What's new
Pinball info

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

In Progress Node board repair

The CPU being waiting for parts, I return to the cabinet node worked on previously. As a reminder, some kind of damage had happened around the NAND gate controlling the TXEN signal of the node bus. Whilst I had managed to hack it back together with the original chip, I had the feeling that it wasn't very robust, and I didn't really trust that chip either as it may well have been the cause of the damage! I wanted to write a bit of software to test the bus. Couldn't immediately find an echo command so I settled on just querying the switches 20 times per second.
C:
int main(int argc, char** argv)
{
  if (argc < 2) {
    printf("Usage: %s node_id\n", argv[0]);
    return 255;
  }
  int node_id = strtol(argv[1], NULL, 10);
  if (node_id < 1 || node_id > 15) {
    printf("Invalid node id: %d\n", node_id);
    return 1;
  }

  if (NODEBUS_Restart())
    return 2;

  uint64_t prev_state = 0;
  uint8_t  last_poll = 0;
  struct timespec last_change = {};
  clock_gettime(CLOCK_MONOTONIC, &last_change);
  while (1) {
    uint8_t poll = NODEBUS_Poll();
    if (poll != last_poll) {
      printf("Poll %d\n", poll);
      last_poll = poll;
    }
    uint8_t data[INPUTSTATE_BYTES];
    int rc = NODEBUS_GetInputState(node_id, data);
    if (rc != 0) {
      printf("GetInputState failed with %d\n", rc);
      return 3;
    }
    uint64_t state = *(uint64_t*)data;
    if (state != prev_state) {
      struct timespec now = {};
      clock_gettime(CLOCK_MONOTONIC, &now);
      float diff = diff_ns(last_change, now);
      printf("Node %d input state: changed from %llx to %llx after %f sec.\r\n",
             node_id, prev_state, state, diff / BILLIONF);
      prev_state = state;
      last_change = now;
    }
    usleep(50000);
  }
}

Now I forgot to capture the log at the time, but basically it was flaky. Sometimes the data would read correctly and then after a random interval (tens of seconds) the line would turn to garbage, returning 0x55EEEEE5555EEE5E5E5E55E5EE... This is consistent with the TX enable signal not registering. I probed it a bit and tried to patch things back together but it was too far gone and quite frankly in a right mess! 🫣

IMG_4155.JPG

So I decided to replace the chip with a new one, which posed 2 problems: (1) the original footprint was destroyed beyond repair (fubar), and (2) the replacement chip I got had an even smaller footprint, being SOT353 instead of SOT23-5 (that's down to 0.65mm pitch - yay).

For the first problem I had got a breakout board which unfortunately used the larger footprint but it was close enough to work. I transferred the decoupling cap onto there although due to the pinout had to use a wire, still better than nothing I guess. Used a short length from a cut pin to bridge the 2 inputs together as on the schematic, this will let me wire that net to both the source IC as well as the pull-up using separate wires. On the left you can see the cleaned up footprint and also were I cut the traces in case there was any funny business going on where the IC used to be.

IMG_4162.JPG

Here's a closer look. Not pretty. You can see on the left where I scratched the soldermask away to make a ground pad. The dumbells on the right is our VIN, and we'll also be reaching to the resistor above which is the input pull-up. The 2 remaining connections will be directly to the legs of the partner ICs.

2023-04-04-211805_1347x965_scrot.png

With that I proceeded with the enfuriating task of stripping very short, thin gauge wires, at both ends 🤬 and created a little spider. I then fixed the board using CA to some kapton tape on the conveniently-placed RJ45 jack, and soldered all the tentacles to where they needed to go. A couple of them broke and I had to remake some of these horribly fiddly wires...

2023-04-05-211956_1920x1200_scrot.png

This is obviously quite fragile especially against a handling point like the ethernet jack so I will add some mechanical protection asap (hot snot). But first it needs a test! This time I did remember to capture the output...

IMG_4163.JPG
Code:
root@stern-spike2:~# ./monitor_inputs 1
Scan: node 0, next 1
Scan: node 1, next 0
Node 1 input state: changed from 0 to ffffffffffffbf9f after 0.002818 sec.
Poll 1
Node 1 input state: changed from ffffffffffffbf9f to ffffffffffffff9f after 3.972641 sec.
Poll 0
Poll 1
Node 1 input state: changed from ffffffffffffff9f to ffffffffffffbf9f after 4.981831 sec.
Node 1 input state: changed from ffffffffffffbf9f to ffffffffffffff9f after 0.053427 sec.
Node 1 input state: changed from ffffffffffffff9f to ffffffffffffbf9f after 0.053425 sec.
Poll 0
^C

Notice the orange wire jumping 2 pins together: these are GND and PLUMBTILTSW. This lets me fake a tilt and is the cause of the bit toggling seen in the output above. We can even check this using a game manual:
2023-04-05-213616_1009x24_scrot.png

Switches are numbered from 0 and (1<<22) = 0x40_0000. Now we're running on a 32-bit little-endian system (iMX6) and my silly program is printing the data as a u64, indicating that we're seeing a change of bit 0x40 in byte[1], which suggests a big-endian u32 representation. That doesn't make a lot of sense so I've probably got something wrong - endianness always makes me confused!! (And it's late 🍺 !)

To end on a more useful note, how did I know which pins to bridge for that switch? Here's a handy dandy reference pinout which seems to be somehow absent from the official online docs ;)

PXL_20230325_175454659.jpg


Much happier with the state it's in now. As I said it needs a bit of protection - will use some hot glue, tape and maybe a bit of liquid rubber. But that's enough for tonight - it's time to enjoy a few games on Getaway! 🚨
 
The CPU being waiting for parts, I return to the cabinet node worked on previously. As a reminder, some kind of damage had happened around the NAND gate controlling the TXEN signal of the node bus. Whilst I had managed to hack it back together with the original chip, I had the feeling that it wasn't very robust, and I didn't really trust that chip either as it may well have been the cause of the damage! I wanted to write a bit of software to test the bus. Couldn't immediately find an echo command so I settled on just querying the switches 20 times per second.
C:
int main(int argc, char** argv)
{
  if (argc < 2) {
    printf("Usage: %s node_id\n", argv[0]);
    return 255;
  }
  int node_id = strtol(argv[1], NULL, 10);
  if (node_id < 1 || node_id > 15) {
    printf("Invalid node id: %d\n", node_id);
    return 1;
  }

  if (NODEBUS_Restart())
    return 2;

  uint64_t prev_state = 0;
  uint8_t  last_poll = 0;
  struct timespec last_change = {};
  clock_gettime(CLOCK_MONOTONIC, &last_change);
  while (1) {
    uint8_t poll = NODEBUS_Poll();
    if (poll != last_poll) {
      printf("Poll %d\n", poll);
      last_poll = poll;
    }
    uint8_t data[INPUTSTATE_BYTES];
    int rc = NODEBUS_GetInputState(node_id, data);
    if (rc != 0) {
      printf("GetInputState failed with %d\n", rc);
      return 3;
    }
    uint64_t state = *(uint64_t*)data;
    if (state != prev_state) {
      struct timespec now = {};
      clock_gettime(CLOCK_MONOTONIC, &now);
      float diff = diff_ns(last_change, now);
      printf("Node %d input state: changed from %llx to %llx after %f sec.\r\n",
             node_id, prev_state, state, diff / BILLIONF);
      prev_state = state;
      last_change = now;
    }
    usleep(50000);
  }
}

Now I forgot to capture the log at the time, but basically it was flaky. Sometimes the data would read correctly and then after a random interval (tens of seconds) the line would turn to garbage, returning 0x55EEEEE5555EEE5E5E5E55E5EE... This is consistent with the TX enable signal not registering. I probed it a bit and tried to patch things back together but it was too far gone and quite frankly in a right mess! 🫣

View attachment 198566

So I decided to replace the chip with a new one, which posed 2 problems: (1) the original footprint was destroyed beyond repair (fubar), and (2) the replacement chip I got had an even smaller footprint, being SOT353 instead of SOT23-5 (that's down to 0.65mm pitch - yay).

For the first problem I had got a breakout board which unfortunately used the larger footprint but it was close enough to work. I transferred the decoupling cap onto there although due to the pinout had to use a wire, still better than nothing I guess. Used a short length from a cut pin to bridge the 2 inputs together as on the schematic, this will let me wire that net to both the source IC as well as the pull-up using separate wires. On the left you can see the cleaned up footprint and also were I cut the traces in case there was any funny business going on where the IC used to be.

View attachment 198564

Here's a closer look. Not pretty. You can see on the left where I scratched the soldermask away to make a ground pad. The dumbells on the right is our VIN, and we'll also be reaching to the resistor above which is the input pull-up. The 2 remaining connections will be directly to the legs of the partner ICs.

View attachment 198563

With that I proceeded with the enfuriating task of stripping very short, thin gauge wires, at both ends 🤬 and created a little spider. I then fixed the board using CA to some kapton tape on the conveniently-placed RJ45 jack, and soldered all the tentacles to where they needed to go. A couple of them broke and I had to remake some of these horribly fiddly wires...

View attachment 198567

This is obviously quite fragile especially against a handling point like the ethernet jack so I will add some mechanical protection asap (hot snot). But first it needs a test! This time I did remember to capture the output...

View attachment 198565
Code:
root@stern-spike2:~# ./monitor_inputs 1
Scan: node 0, next 1
Scan: node 1, next 0
Node 1 input state: changed from 0 to ffffffffffffbf9f after 0.002818 sec.
Poll 1
Node 1 input state: changed from ffffffffffffbf9f to ffffffffffffff9f after 3.972641 sec.
Poll 0
Poll 1
Node 1 input state: changed from ffffffffffffff9f to ffffffffffffbf9f after 4.981831 sec.
Node 1 input state: changed from ffffffffffffbf9f to ffffffffffffff9f after 0.053427 sec.
Node 1 input state: changed from ffffffffffffff9f to ffffffffffffbf9f after 0.053425 sec.
Poll 0
^C

Notice the orange wire jumping 2 pins together: these are GND and PLUMBTILTSW. This lets me fake a tilt and is the cause of the bit toggling seen in the output above. We can even check this using a game manual:
View attachment 198568

Switches are numbered from 0 and (1<<22) = 0x40_0000. Now we're running on a 32-bit little-endian system (iMX6) and my silly program is printing the data as a u64, indicating that we're seeing a change of bit 0x40 in byte[1], which suggests a big-endian u32 representation. That doesn't make a lot of sense so I've probably got something wrong - endianness always makes me confused!! (And it's late 🍺 !)

To end on a more useful note, how did I know which pins to bridge for that switch? Here's a handy dandy reference pinout which seems to be somehow absent from the official online docs ;)

View attachment 198569


Much happier with the state it's in now. As I said it needs a bit of protection - will use some hot glue, tape and maybe a bit of liquid rubber. But that's enough for tonight - it's time to enjoy a few games on Getaway! 🚨
I understood the occasional word there 😂
What you just wrote sounds like Skynet telling a witty story after a few beers.
 
Right, after a pleasant Easter break it's time to have some more "fun" with node boards! Need some parts to rebuild the LED section on that tenacious CPU board, and to try and save on the £20 handling fee (for £2 worth of parts!) I'm trying to accumulate a slightly larger order. (Anyone want to do group buys?!)

Conveniently, another brave soul has sent me a node board to fix, and one I've never laid my paws on before. This was described as a "spike 1 node board" which leads me to believe it was used in titles such as ghostbusters. In any case, the markings on it identify it as 520-6935-10A which corresponds to the "8-COIL PLFD NODE BOARD" schematic on Stern's website. Look how tightly everything is wedged in-between these connectors 🙈

IMG_4167.JPGIMG_4168.JPG

Symptoms I'm told are "not recognised by the CPU". Ok then, let's power it up... And a single red light comes on. Same problem as before: the power rails are all gated on the node bus voltage being present.

2023-04-18-203516_407x225_scrot.png 2023-04-18-203503_584x279_scrot.png

Now I don't really want to hook it up to my spike 2 CPU as I don't really trust it to flash the right firmware onto it. These old boards use a LPC1112 chip which although it's very similar to the LPC1313 in recent ones (such as the cabinet board fixed earlier), are not binary compatible. And Stern did issue a bulletin saying not to mix new code and old boards as their update mech would brick the boards (yes, really)... Anyway long story short I wanted to find another way.

My power supply has an auxiliary output which can do 5V and I figured that would be enough to trigger ISO4. (Another digression: the MP24943DN datasheet says its EN pin needs to see at least 1.8V and its max rating is 6.5V. Now VBBA is basically the 48V input, so I'm guessing that massive R14 is there as a way to step the voltage down to ~3V. Now 45V/470k = ~100uA but I don't see any characterisation of the current sunk by that EN pin... Anyway it doesn't really matter but if someone knows I'd be glad to learn!) OK after a little dig I found a RJ45 breakout board, stuck 5V across VNB and powered the whole thing back up:

IMG_4169.JPG

Wasn't powered on that photo, but basically the status was: red LED on (D37), green LED on but wavering (D10), and D1 resolutely off. I also noticed that my power supply was dropping the voltage due to overcurrent (I had it set at 48V/250mA and it was displaying 10V/350mA). Referring to the handy diagnostics table in the schematic's power page:

2023-04-18-204825_1506x215_scrot.png

It sounds very much like a shorted power rail. A bit of probing later, the 5V rail is indeed a dead short :( Well at least we've found the a problem. The power tree of the board is basically the 48V input (VBB) powers the 6V rail (VLED), which then powers both 5V (VCC) and 3V3 (VDD).

My theory is that the shorted 5V rail is causing the 6V to drop out, thereby also causing 3V3 to go away, which is why the MCU's LED never starts flickering. VCC is mainly used by the switches and LEDs, mostly on p2 of the schematic (which is labelled sheet 5 of 5, hah!) The first thing to try will be removing the caps across 5V. If that doesn't avert the issue, then we will have to go for the various ICs on it... Time to go shopping!
 
new code and old boards is fine ! its old code and new boards that are the issue.
 
Following with intreague as i have a faulty node board here (though i cant remember now whats up with it!)...... Node 8/9 Spike 1 (520-7017-72B -NODE BOARD 48 VOLT 8 DRIVER STERN SPIKE)... I cant do diddly squat with it really as dont have an MPU out of a machine I can test with (unless someone knows of a cheap MPU.... :rofl: )
 
Loving the NODE BUS code, can you share more how the NODE BUS works? What is the protocol? And how are the packet’s structured?
 
Loving the NODE BUS code, can you share more how the NODE BUS works? What is the protocol? And how are the packet’s structured?
It's a variation on modbus with the addition of a checksum. The best source of info is the MPF spike code which has reimplemented most of it. Also if you can get your hands on a pre-IC game executable they still have symbols in which is very handy.
 
I cant do diddly squat with it really as dont have an MPU out of a machine I can test with (unless someone knows of a cheap MPU.... :rofl: )
Pinball life has spike2 CPU in stock at a "reasonable" $400. At some point I might look into putting together a standalone test rig which allows poking them from any PC... All that's required on the hardware side is a RS485 transceiver, a USB-UART and a bit of cabling.

You could still test the various power rails as I have done above.
 
For Stern Schematics I have noticed that they use DNP as opposed to DNF - do not populate - (going back to the first post comment about not being able to see the LEDs on the board) will check the rest of this thread out as it looks really good, but just jumped to the end.

however..... I have noticed errors on most of the Stern schematics that I have looked at to date - usually minor but they can be confusing at times when trying to troubleshoot, and I have found that I have to go to component manufacturers datasheets from time to time to clarify certain issues

I would totally recommend using liquid solder paste and a hot air solder tool - takes a lot of risk away from rework

Jeff
 
I would totally recommend using liquid solder paste and a hot air solder tool - takes a lot of risk away from rework

Jeff
The liquid solder paste was next on my item list to buy.
Supposed to be great for reflow work...
Only thing that worries me as a novice, possible bridging.
Was reading heat gun @ 400 degree C with airflow around 25%
 
I'd check all the transistors first (using diode test) in case one of them has shorted pulling the rest of the board down before going deeper in to board repairs.
 
I'd seen the chip quik stuff before but the price always put me off... £1/g ! Having located and measured all the possible culprits there's definitely a couple buried ones which are going to be a pain to get off. Will try the easy ones first and see how we go.

Failed transistor doesn't explain the symptoms I think, but they are a common failure point - in fact it looks like a few on this board have been replaced already. Quick and easy test though and all reading good no shorts 👍
 
Having been reading up on the mission pinball node bridge which is super cool. How come people are not making replacement node boards? If you know the protocol it should be fairly simple to build replacement ones? Or would it void stern warranty etc.. putting in some aftermarket component.
 
Having been reading up on the mission pinball node bridge which is super cool. How come people are not making replacement node boards? If you know the protocol it should be fairly simple to build replacement ones? Or would it void stern warranty etc.. putting in some aftermarket component.
I don't see the economics working out. They retail for $140 so a clone would need to be cheaper. Reimplementing the firmware would be a ton of work, assuming you don't reuse Stern's of course. Then of course they'd probably sue or something...

You could argue that what @stumblor is doing with his latest FF mod is kind of an aftermarket node board for driving mods. But that's a different goal entirely.
 
Just had a look at a Node board and I reckon around $20 each to manufacture in the volumes they will use - code is definitely the issue here I believe, in terms of preventing an after market part, unless you paid Stern a license fee AND they agreed
 
The code issue has already been mentioned on pinside re what if the LPC1313 is faulty and needs to be changed? The way things are wired up, if multiple nodes are on the bus I don't believe it's possible for the master to leverage the NXP bootloader which sits in ROM. This means that the chip must be programmed at least with a minimal firmware enabling it to be updated. Although game SD card images contain these firmwares they are in some obfuscated format, and the node boards themselves have code read protection enabled. Digging a bit more here is definitely on my list of things to tinker with when I'm bored...
 
As my nan used to say - you win some you lose some. Unfortunately I was not able to mend the original CPU board with the failed backbox illumination and that section of the PCB has seen all the action it can handle. Some of the 48V traces have arced to the second copper layer, melting the fiberglass in the process and creating conductive carbon...not good! I cleaned it up as best I could and sealed the holes with kapton tape and/or liquid rubber but it's just too far gone. Fortunately this section is easy to isolate by removing D7 so the board is still usable but will need an external LED strip if/when it goes back into a game.

Feeling rather down after that failure, I gave the "spike 1 node" a cold hard look. As above, it appears to have a short on the 5V rail and I suspect a failed cap. There are 5 caps on that rail, first task was to make myself a little map:

node.png

Some of them are tiny and wedged tight quite close to delicate plastic connectors. Needless to say at this point I was not experiencing that warm fuzzy feeling, and seriously second-guessing whether I should touch those. Probing around with the multimeter on the 200 Ohm setting, I see that C16 reads 4.8 Ohms across, whereas the others are closer to 5V. A clue?! In any case C16 is the easiest one to get at so clearly the first one to come off. And guess what it was the culprit :D

Quick wick of the pads, new solder, new cap, power on and... D1 blinks! 🥳

2023-04-23-213834_659x1008_scrot.png 2023-04-23-214325_675x686_scrot.png

IMG_4179.JPG

Pretty happy with that - easy fix this time. Replacement component cost 15p!

Next up on the bench we have a 520-7017-72D1 aka the Common Node found in every game coming out of the factory. This one has all 3 LEDs lighting up correctly so the issue must be on the comms circuit rather than power. No obvious damage from a visual inspect so it'll be out with the scope. To be continued...

IMG_4182.JPG
 

Attachments

  • IMG_4181.JPG
    IMG_4181.JPG
    185.7 KB · Views: 13
Two happy forum members will be getting boards back soon :) The first one being the 8-coil pf node which had the failed cap, and the second the CPU board with failed backbox lights. Do you have broken node boards at home too? Let's chat! :)

Those who have been following since the start of the thread and are still around (thanks!), you might remember that this board from the first post was not mine, and considering it ended up beyond repair you might think the original owner wouldn't be too happy! Yeah I wouldn't be, this is what the damage looked like (warning: graphic content lol) -- you can see the 2nd layer of copper in the hole between the left pad & the via:

2023-04-23-162035_889x669_scrot.png

Crikey!! Fortunately I had a spare one which I'd bought for $400 + taxes from Pinball Life (not exactly cheap I thought). The minor detail is that although it works fine for running my test software, the game executables will grump due to region locks. This is just a setting in the board's flash memory (some FRAM on the carrier board) so after a bit of hand waving I ended up with a board in perfect condition ready to return to its owner ;)
The next step is to make some progress on that 4-coil board which seemed to boot alright. Contrary to the cabinet node, this doesn't have a handy 12V rail to power it so it needs to feed from the main 48V supply. Thus I set about to create a pigtail which could be soldered to the CPU board and used to power the slave node... Reminding myself how much crimping is FUN !! :tut:

IMG_4192.JPG IMG_4194.JPG

Aaanyway once that was out of the way some software testing showed no difference whether the node was connected or not. I put my scope onto the MCU's UART pins which are conveniently broken out to test pads, which are inconveniently located underneath the board... Not that that's going to stop us :p

IMG_4195.JPG 2023-04-28-222026_1088x588_scrot.png

Interesting result which is that the RX line shows activity (above) but TX stays blank as well as TXEN. Basically out of the 6 pogo pads 4 are stuck at 3V3 and only RX shows activity :hmm: There is continuity from these pads to the processor's pins and no visible damage to the board so not likely to be a trace. I decide to test just the processor's UART in isolation. Maybe one day I'll build a bed of nails, but for now 6 spots of solder will have to do...

IMG_4196.JPG IMG_4197.JPG

By pulling the ISP pin low the MCU enters the ROM bootloader. On the 2nd pic you can see the yellow wire I've stuck onto a nearby GND pin. By following the instructions in the user manual we can talk to it:
Code:
?
Synchronized
Synchronized
OK
10000
OK
R 0 4
19
2023-04-28-230308_731x343_scrot.png

Right so the UART works fine and CRP is enabled, no surprises. So why isn't it responding to the CPU board?? Stern's firmware is clearly running because the status LED is blinking. Will have to sleep on it for now...
 
Not had a lot of time for this due to life getting in the way, but managed to run a few more diagnostics on this one and it's still got me a bit stumped...

To recap when probing the MCU's RX line we see expected activity but the TX line is mute. Talking to the bootrom is fine, implying that the UART peripheral is working.

I thought maybe a component from the isolation section is scrambling that line? Tried the same but with the 48V and node bus rails present - could still talk to the bootrom.

So I recompiled my input monitoring application to run on my desktop and wired that directly to the UART on the board's pogopads; effectively running the node bus protocol but taking out the whole RS-485 isolation circuitry. Still no TX activity! Trying the same test on a known good board does get its status LED to start flickering so clearly the only difference must be the code? 🤔

Now one (the only?) difference is the node addressing which is controlled by the DIP switches. When I got the board it was set for address 9 (DIP3 ON, others OFF). Checked the corresponding input pins on the MCU and all seemed good (reading 3.2V on the OFF switches and 0V for the ON one). So that doesn't seem to be the problem either...

Will have to sleep on it (again!) but seems like the next step is going to be reflashing the firmware - not so straightforward considering that I don't have any firmware to flash (yet) !
 
Shorts on the 3.3v seems to be the main stumbling block i have come across. As you have noticed, sometimes the multilayers just short internally i think.

Most boards i have had though node driver wise are fixable.

I think cabinet node boards destroy themselves more than playfield ones.
 
Right so I've finally got a bit of time to look at this stuff again... Life just gets in the way doesn't it? To be perfectly honest, my main problem is I spend too much time playing pinball and moving games in & out of my house 😂 Anyway, node boards, I've got a bit of a backlog now...

First step was to label the boards at hand since I'm starting to accumulate a bit of a collection - enough for 2 whole pins actually! Half of them are mine, most are in some state of brokeness...
PXL_20231106_191303237.jpg

From the top-left we have:
  • Cabinet board, shaker output blown
  • Cabinet board, fixed earlier in this thread
  • Node 8/9 board, known good
  • Node 8/9 board, "not initialized" error
  • Node 8/9 board, "not found" error
  • Node 8/9 board, no UART Tx (investigated earlier in this thread)
  • CPU board, dev platform - good except for blown audio circuit
  • CPU board, input issues

The first one in the queue is this CPU board with input issues. Some helpful information was provided by the owner (which is always appreciated) :
Spike CPU from an Iron Maiden LE that's reporting a Power distribution board error as well as 48v and interlock issues, it sort of boots (sometimes) but you can never use the coin door buttons.

The game was in storage for 18 months and wasn't working when it came out (was prior). After getting it going with a replacement CPU, all the flipper shafts were tight against the bushings, leading me to believe that it got VERY hot wherever it was stored.

This points me to an issue with the discrete inputs, which is the long thin header on the right side of the board, between the SD card and the nodebus ports (CN25).
Various things plug in here including the coin door buttons, VBBGOOD which indicates that the 48V is present (i.e. the interlock switch), etc. Fits the symptoms!
2023-11-06-203232_1103x677_scrot.png

On the software side, these inputs are read using the CPU's SPI peripheral. So let's write a bit of code to read that :)
Code:
  spi_fd = open("/dev/spidev1.0", O_RDWR);
  struct spi_ioc_transfer xfer = {
    .tx_buf = (intptr_t) &spi_tx[0],
    .rx_buf = (intptr_t) &spi_rx[0],
    .len    = sizeof(spi_tx),
  };
  int rc = ioctl(spi_fd, _IOC(1, SPI_IOC_MAGIC, 0, sizeof(xfer)), &xfer);

The above is simplified as I've removed error handling and some other stuff but you get the idea - just another ioctl.
Now I could modify my `monitor_inputs` program (see earlier posts) to allow me to monitor these instead of some node switches.
First try it on my dev board!
Code:
# ./monitor_inputs 0
Node 0 input state: changed from 0 to 8ffff1 after 0.003613 sec.
Node 0 input state: changed from 8ffff1 to 8ffef1 after 9.715632 sec.
Node 0 input state: changed from 8ffef1 to 8ffff1 after 4.258284 sec.
Node 0 input state: changed from 8ffff1 to 8ffdf1 after 8.262879 sec.
Node 0 input state: changed from 8ffdf1 to 8ffff1 after 3.387405 sec.
The changes in value are driven by my fat fingers, shorting one of the inputs to ground:
PXL_20231106_203258650.jpg


Now for the same test on the bad board...
Code:
Node 0 input state: changed from 0 to ffffff after 0.001290 sec.
(nothing happens when an input is grounded)

I guess this confirms our theory. Back to the schematics... Now since even the DIP switches aren't reading, the fault can't be upstream of U3 - it's either U3 or something downstream from there.
Scope time... The chip we're going to look at first is a 74HC165D and the datasheet tells us all about its pinout:
2023-11-06-225446_445x726_scrot.png

We're most interested in pins 1, 2, 7, 8, 9, 10, 15, 16.
First the easy stuff: it's getting a good 3.3V, ground seems to be connected, and /CE is also reading low.
The inputs /PL and CP (CS0 and CLK from the SOC) are also happily toggling up and down as my monitor program is running.
2023-11-06-223921_1507x765_scrot.png2023-11-06-224155_1201x427_scrot.png

On the output side though... Things are weird! Q7 (aka QH) is basically floating. Touching it with my probe results in the program suddenly reading all zeroes.
2023-11-06-224338_1491x332_scrot.png

The complementary output /Q7 is not as bad, but it's not exactly good either! The highs are OK but the lows are really wobbly...
2023-11-06-225339_1680x265_scrot.png


Probing the other 2 shift registers U9 & U22 also exhibits flaky behaviour. Furthermore I notice that U22 is fed 5V on its data input line from the CN8 pin - bit cheeky but not out of spec I guess?
U3U9U22
DS1.65V0.23V5V
Q70.5V1.65V0.23V
/Q7HI ok but LO is noisy0V0.05V

Bit perplexing, especially since the inter-chip lines (Q7->DS) are both basically garbage. This leads me to suspect some kind of power supply issue? But the Ethernet port is working fine and that's also running off 3V3...
Or else the middle chip (U9) is toast and taking down its neighbours??

Another interesting note is that, when I touch Q7 on U3, i.e. the SPI2_MISO line going to the CPU, my test program immediately reads all zeroes.
This means that the line is not really being driven by the shift register, just left floating and weakly pulled up somewhere.

As I'm probing around however, I noticed some unwelcome gunk on the board:
2023-11-06-231930_1920x1200_scrot.png

Also on the underside:
2023-11-06-231959_1920x1200_scrot.png

This is not what you want to see on these $400 boards !! Turns out it's a via for the 5V line going to U19, which manages the USB host port. Seems to read fine at 5.02V so don't think it explains the above problems - but something to clean up.

Going to call it a night for now - been a couple hours and not feeling like I've cracked it yet :( This is why these repairs cost a lot of £££ when it's not some amateur in a garage! ;)

Next steps will be to first clean up that gunk, then ... I'm not sure tbh - probably replace the shift registers but I'll need to order some first. But first of all, some sleep 💤
 
Cleaned the gunk off with some diluted vinegar then plenty of isopropyl.
Looks much better now.
2023-11-08-222211_762x800_scrot.png

Also took the module out and noticed some gunk on a couple of the contacts.
Forgot to screenshot the second location but you get the idea. Cleaned that up too.
2023-11-08-210754_1920x1200_scrot.png

However this has made no difference to the issue so I think the next is going to be replacing those shift registers.
This board will go on hold for a bit, whilst I accumulate a slightly larger shopping list to amortise the fees.

Next up we will look at the cabinet board with no shaker...
 
After wasting an evening reinstalling a compatible toolchain after an OS upgrade, I look into this cabinet board with no shaker output.
Again we have some helpful information from the previous owner:
There was a short on the shaker, one which I had taken out of another machine where it worked fine. You can see where it arced across to the frame of the shaker, only difference being on the old machine it hadn't been sat on an earth braid, now stern run an earth braid under where the shaker sits so it worked fine in the old machine but arced to earth in DP cos of the earth braid.

I tried connecting another shaker motor to it but nothing, no shaker output at all but other than that it worked fine so all other functions the board handles work ok.

If I remember rightly when I tested a 2nd shaker connected to it the fuse in the shaker blew

First I try my input monitoring program and that's working fine as expected, so I quickly whip up a coil firing program (the shaker is coil 0 on the cabinet board).
2023-11-20-202124_989x534_scrot.png
C:
#include "node_bus.h"

int main(int argc, char** argv)
{
  int node_id = strtol(argv[1], NULL, 10);
  int coil_id = strtol(argv[2], NULL, 10);
  if (NODEBUS_Restart())
    return 2;
  printf("FIRE !!\n");
  NODEBUS_Coil(node_id, coil_id, 0x80, 0x51, 0, 0);
  usleep(100);
  NODEBUS_Stop();
}

Basically 90% boring stuff, with just one interesting line (yay C). It's worth explaining what the parameters mean here: the first 2 are obvious, but then there seems to be 4 numbers which are the initial power and length, then a secondary power and length (I think).
The power is 8 bits, so 255 is max power (same as we can see in the game's settings e.g. for flipper power), and 0x51 happens to be the value a game I was inspecting used for flippers.
With all that in mind, for those taking notes at home the actual message that goes out on the wire looks like this:
Code:
81 0c 40 00 80 51 00 00 00 00 00 00 00 62 00
^^ ^^ ^^ ^^ ^^ ^^^^^                   ^^ ^^-  length of expected reply (no reply for this call)
 |  |  |  |  |   |                      `----  checksum
 |  |  |  |  |   `---------------------------  length of pulse (unsure what the units are)
 |  |  |  |  `-------------------------------  power of pulse (50%)
 |  |  |  `----------------------------------  coil id (shaker is coil 0)
 |  |  `-------------------------------------  command id (0x40 = CoilFireRelease)
 |  `----------------------------------------  length of this message (12 bytes)
 `-------------------------------------------  destination (0x81 = node 1)
I'm not sure what the last 3 bytes before the checksum are for, but zero is as good a value as any, right? :D

Anyway, running the above code does show the shaker output being taken low, so clearly that bit must be working?
2023-11-20-203402_532x267_scrot.png
(for sanity checking: the initial ~18V state does seem to be floating since it moves significantly if I touch my finger to it)

Back to the schematic, I'm guessing that the current sensing circuit could be at fault... I'm not running any code on the node boards themselves (yet!) so I'll have to either probe the I_SENSE and /FAULT lines, or figure out which node command they map to...
There is one promising-looking command name, OCGetFault, however the node board won't respond to it.
The I_SENSE line is going to be a bugger to probe due to only coming on the pins of the 2 chips with tiny pitch.
/FAULT is not too bad as it can be probed on R4. Running my dodgy coil test does not cause it to go low.

I think at this point I need to wire something a bit chunkier on the output. I don't really want to use a £100 shaker motor, so let's use some incandescent bulbs I have lying around from the LOTR days (my first pin, 3.5 years ago!)
Of course this is going to be another ghetto setup 😅
But hey it works!!

View attachment MVI_4353.MP4


What to do now, what to do?? ... I'm guessing I could put it in GZ for testing but leave the bulbs plugged in rather than the shaker - will have to mull it over.

Any comments, ideas, feedback, etc. all very welcome :)

Next up on the bench we will have a couple of playfield node boards (nrs 8/9) which are apparently failing to come up...
 
Finally took some time to look at two playfield boards (node 8/9) which have been here for ages.
The parts I wanted to swap out all need hot air and I noticed it's really easy to melt the plastic connectors.
Eventually I acquired some kapton tape and mustered the courage to fire it up (on a hot summer day too - what was I thinking).

The first one after a bit of poking around showed a reading of 0.2V on the 3V3 rail, which powers the MCU.
That rail didn't seem to be shorted across so I put in a new regulator AP7333-33SRG-7.
Got the old one out with the hot air station, cleaned up the pads with some fine wick and soldered a new one back in.
Getting the iron's tip on the pad in the corner of C20 and the plastic connector was a bit of a squeeze!
1719512642072.png

Plugged it back into my bench setup, which is a CPU board running a ssh server on which I run some test programs which communicate over the node bus.
This is important because by default the node bus is powered down, and the game program needs to activate it in order for the node board regulators to switch on.

Started up my switch test program and the orange light started blinking which means we have 3.3V power to the MCU again, and toggling switches shows the expected readings - SUCCESS!! 🥳🥳

------------------

The other board is of the same type and has a fault where the main 6V regulator outputs 0V.
According to a Pinside thread the MP24943 at U9 and the large TH diode next to it (D9) are a common failure point.

That was a bit hard to get out as it's a tight spot to work in! But eventually she came out. 😰
1719514874855.png

I also swapped the diode, this time snipping its legs off and cleaning up the holes separately.
Unfortunately, swapping these 2 components out didn't cure the fault, so it's back to the drawing board, probably going to try replacing some of the passives which are buried in there 🙈

Any bright ideas?? Readings are 48V on VIN, EN is on (3.1V). All the outputs are just 0V. datasheet

1719514776108.png
 
Really interesting thread, can't say I have the expertise to fully understand and apply it.

Appreciate everyone taking the time to write detailed technical information, it will definitely be useful for people.

Out of interest was any of the Ghostbusters spike 1 node boards fixed?
 
Back
Top Bottom