(Topic ID: 305088)

Stern Spike bench testing - eg. 520-7017-72D Node board

By Flippers_com

2 years ago


Topic Heartbeat

Topic Stats

  • 28 posts
  • 10 Pinsiders participating
  • Latest reply 1 year ago by AlanJ
  • Topic is favorited by 8 Pinsiders

You

Linked Games

No games have been linked to this topic.

    #1 2 years ago

    Has anyone found a way to communicate with the node boards? You can't use regular Ethernet as the board tries to pump out something like 12VDC on two of the RJ-45 connectors - pins 4 & 5 - which will fry some ethernet hubs or computer ports...
    Of course you could make a cable that has not those two pins used and then play with talking to the board. Might be a somewhat standard protocol, I'm pretty sure they wouldn't want to invent their own when there are a number already out there. Could it be the CAN system used in automotive networks?
    Just tossing this out in case someone is interested it working with me on this fun project! I have a few projects on the go at any one time, why not add another?
    John :-#)#

    #2 2 years ago

    Color me intrigued, I was actually going to post a question on this. I'm surprised no one has looked at it before.

    What would help would be the node board schematics, that would allow to identify the signals.

    If not available, then we'll need to hook up a logic analyzer on the port and try to identify what's being exchanged.

    We can also try to derive that info from the chip used on the most simple node board

    Personally I doubt it's ethernet, I suspect CAN indeed

    #3 2 years ago

    Actually it is Ethernet, not CAN. At least if I understand the schematics (which are, incredibly, available on Stern website).

    Need to dig if there's something we could hook up to

    #4 2 years ago

    I thought I read somewhere it is RS-485.

    #5 2 years ago

    You can definitely replace the bus cables with standard ethernet in the games. I've done it for replacing missing or bad cables. Now, as far as the bench test issues, I'm not sure. It is nice that Stern has released schematics for these, but there is such limited repair resource out there. Hopefully, as a community, a solid build up can be accomplished so we have a chance of working on these things a little more as opposed to thinking of them as manufactured obsolescence and replacing entire node boards and main boards when issues arise like seems to be the main course of action now. I have a main Spike 2 board that fails to boot sitting in my workshop. One of these days, I plan to really sit down and try to figure it out a little more and hopefully make some strides towards repairing it and documenting that, but time is always the big road block.

    #6 2 years ago

    Well, I stand corrected, by myself.

    It's definitely not Ethernet. When taking a look at 4-coil driver node board schematics, you can clearly see that it cannot be ethernet but instead it's a serial bus, with naming convention RS485

    And conveniently, it uses a RS485 transceiver (SN65HVD485ED)

    So... now on to understand the type of commands being sent.

    #7 2 years ago

    The issue with these board is they have a chip with proprietary software. If that chip goes bad, there is no way to fix them.
    Regarding the RS485 protocol, I will not be surprised if they actually modified the protocol to make it non standard.

    #8 2 years ago

    Yes it's RS485 which is basically a UART. The node protocol has been partially decoded, see the MPF spike bridge.

    The easiest way to investigate is from inside the Linux OS by intercepting the serial port.

    For bench testing I suspect it would be best to use an actual MPU in the test/diagnostics menu.

    This video was done by replacing the game software with a homebrew program implementing part of the node bus protocol: https://vimeo.com/501553060

    #9 2 years ago

    @fubar

    Interesting

    i'd be more interested into interfacing between the CPU board and the first node, to actually snoop on data exchange. That would open up possibilities for a mod.

    i'll take a look at Spike MPF bridge source code

    dkeruza

    It would make sense to fully decode the protocol. That way it could be replicated with alternate HW.
    Otherwise, we would need to dump the NXP processor code (which hopefully is doable - need to look into it)

    #10 2 years ago

    I've already done a mod which is game-aware. That doesn't rely on the node bus though. https://github.com/FUB4R/bk3fsl has source code and a link to a video.

    Again, for diagnosing broken node boards I think it would be much easier to power a MPU & cab node on the bench and use the built-in diagnostics menu to test the node board.

    #11 2 years ago
    Quoted from Fubar:

    I've already done a mod which is game-aware. That doesn't rely on the node bus though. https://github.com/FUB4R/bk3fsl has source code and a link to a video.
    Again, for diagnosing broken node boards I think it would be much easier to power a MPU & cab node on the bench and use the built-in diagnostics menu to test the node board.

    Not quite, there is a handshake between the CPU board and the various nodes, with an init sequence. So I'm not sure you can activate the various coils/leds or access game information without a full node chain (or at least the bare minimum, which is likely the first node board in the chain). But I could be wrong, I'll look into various materials available.

    #12 2 years ago
    Quoted from dkeruza:

    The issue with these board is they have a chip with proprietary software. If that chip goes bad, there is no way to fix them.
    Regarding the RS485 protocol, I will not be surprised if they actually modified the protocol to make it non standard.

    What's the proprietary chip you're talking about?

    #13 2 years ago
    Quoted from mdeslaur:

    What's the proprietary chip you're talking about?

    Not proprietary chip, proprietary SW.

    There is a NXP uController on each node board (and on the MCU). These uController have a flashing interface on the board (you can see it on the schematics), and they are flashed in production by Stern.

    Without the code running on them, even if someone duplicates the HW (which is easy given that they provide the schematics), the board is useless

    That said, Stern is still alive and well, and the boards will be available for the foreseeable future. So at least we have some repair capabilities. Granted they are very expensive though, as you can't really repair them (well, you still can repair some of the components if you know what you're doing and you are properly equipped).

    Personnally I'm more interested into understanding the protocol, so as to interact with the machine

    #14 2 years ago
    Quoted from mdeslaur:

    What's the proprietary chip you're talking about?

    This is the chip they use I believe in most of the Node boards.
    https://www.mouser.com/ProductDetail/NXP-Semiconductors/LPC1112FHN33-2015?qs=P1eGD%2F8NI1qwZIdY3Mr37A%3D%3D

    If they update the FW of the node boards on every game update if necessary, the FW code has to be embedded in the game update itself.
    Will look into it. But is probably encrypted and will decrypt in the MCU itself.

    #15 2 years ago

    The MCU they use has a built-in bootloader that allows flashing the code over RS-485 when it boots. While they may pre-load the code at the factory, are you sure it isn't simply re-flashed by the Spike OS when a new node board is plugged in, or when updates are available?

    I suppose they could have implemented their own code to do all of that, with a layer of encryption on top of it, but why bother when the functionality is already built-in? Call me skeptical

    #16 2 years ago
    Quoted from mdeslaur:

    The MCU they use has a built-in bootloader that allows flashing the code over RS-485 when it boots. While they may pre-load the code at the factory, are you sure it isn't simply re-flashed by the Spike OS when a new node board is plugged in, or when updates are available?
    I suppose they could have implemented their own code to do all of that, with a layer of encryption on top of it, but why bother when the functionality is already built-in? Call me skeptical

    The nodes are all daisy-chained, are you sure the LPC bootloader supports that topology? As far as I can tell from the manual, the peripheral's 485 address register is always 0x0 at boot...

    #17 2 years ago

    On the 520-6998 schematics, there are some piece of information, which are somewhat conflicting:

    - On one hand, you can see some programming pads (called POGO pads), and the signals are also connected on CN1. Seems you need to apply a 3.3V voltage, according to the signal naming, to be able to program (to note that the signals used are indeed RS485 signals, plus a few more)
    - On the other hand, in the schematics comments, there are several statements:

    MCU Status Yellow
    10Hz, 50% : power OK, processor in boot mode waiting for runtime update
    1Hz, 90% : power OK, processor in runtime mode but not receiving from CPU

    Both implies two different flashing mechanisms, one through a HW connector, one through RS485

    It would stand to reason that they kept the capability to update runtime code depending on node adress, but then why keep a HW flashing interface. Although mdeslaur point is valid, flashing each node board individually is a pain in production.

    @Fubar, wouldn't the DIP switch define the boot adress ?

    #18 2 years ago
    Quoted from Ashram56:

    why keep a HW flashing interface

    Pogo pins are useful at scale and cost nothing. CN1 is good on the bench so let's be glad they've left it on!

    Quoted from Ashram56:

    signals used are indeed RS485 signals

    Not quite - they are RS-232 (aka "plain old UART"). The RS-485 differential signals are only present on the other side of the transceiver.

    Quoted from Ashram56:

    wouldn't the DIP switch define the boot adress ?

    That is indeed their purpose, but there needs to be some code which reads the DIP switch values and does stuff with them. As far as I can tell, the built-in bootloader doesn't do this. It's possible that they get the chips pre-programmed if they order enough.

    Ashram56 I would suggest you refer to the LPC1313 user manual, in particular chapter 21 (Flash programming firmware): https://www.keil.com/dd/docs/datashts/philips/lpc13xx_11_13_42_43_um.pdf

    #19 2 years ago
    Quoted from Fubar:

    The nodes are all daisy-chained, are you sure the LPC bootloader supports that topology? As far as I can tell from the manual, the peripheral's 485 address register is always 0x0 at boot...

    That's a good point. The manual doesn't seem to indicate there's a way to address them individually.

    #20 2 years ago

    Fundamentally there are two options:

    1/ either Stern is flashing custom code on each board prior to shipping. This implies we need the binary to be able to duplicate a node board, and the board are probably tamper proof

    2/ either they do not, in which case they have a mechanism to flash them when installed in a machine.

    The only way I can see this working is that the CPU board will initiate a communication to a given Node ID board (say node 9), will see if it responds, and if it does not will issue a flash command through RS485 to program node 9 board. This means each board will receive the same code, so they will all update with Node 9 code. The node board then check the ID of the board to the loaded code (ie it's a code for Node 9 so it's mine as I'm indeed node 9), and acknowledge to the CPU board. Other node boards do not have the proper ID so revert to flashing mode.

    Once Node 9 responds, CPU boards moves on to the next board, ie Node 10 for ex, and so on.

    But that's pure speculation, only way to know for sure would be some custom board with a stock NXP part, same HW implementation, to see if it would get updated

    #21 2 years ago

    If I were Stern I would want assemblies tested and delivered in a state ready to be dropped into a game. It is likely that Stern’s contract manufacturer tests the node PCB assemblies before sending to Stern. The MCUs are probably programmed with test firmware. After testing, maybe the memory is reflashed to a common base code that boots the board to a known state and waits to be programmed with game-specific code. If I were doing it, I would try to build that into the test firmware load. It would be an efficient, low-risk way to do it.

    Based on that, I do not think it safe to assume that the MCU on a new node board is blank, or that the on-chip boatloader is used by the game code. This is all speculation so I could be wrong.

    3 months later
    #22 2 years ago

    Has anyone figured out how to program a blank processor ?

    I'm currently debugging a dead node 9 board from a Star Wars LE (I'm referencing the schematics for Stern 520-7017-72D). The main 48V to 6V regulator died and seemed to kill other stuff when it failed.

    I replaced the regulator only to have one of the diodes that drives the input of the 3.3V regulator burn up (D6 in particular) . Stupidly, I did this with the board in the game as I had myself convinced that only the 6V regulator was bad and that the game was going to fire up and work great . A couple of coils energized and I shut the game off as soon as I saw that magic smoke escaped the diode .

    I tried powering the board on the bench to see if I could get the CPU to show signs of life (You can connect ~6VDC to VPROG ... this should get the CPU to boot). Turns out I have a dead short on the 3.3V rail. Connecting 6V to VPROG burned up the other diode (D7) that connects to the 3.3V regulator. I pulled a couple of caps hoping one of them shorted (very rare for that to happen). No luck ... I'm pretty sure the processor was zapped when the 6V regulator died (the 5V regulator lived though).

    Anyway, has anyone had any luck programming a brand new, "blank" processor? I don't think it'd be possible to program the board with a blank processor in-game for reasons others have mentioned in this thread. However, it seems like one *might* be able to program the processor using the programming interface on the board. Stern seemed to leave that white molex connector @ CN1 for this purpose.

    Couldn't one get the node board firmware from the game's firmware? I can't see why they'd encrypt this stuff (aside from topper related node boards of course). It almost looks like you could do it with a UART based on the processor's docs.

    If it isn't available, I wish Stern would provide a "default", basic image we could use to repair these boards ourselves ... that'd make me feel a bit better about owning these machines long term . I cannot find a new node board anywhere and it seems like it's going to be a while before they're available (the coil driver transistors and gate driver chips are sold out on both Digikey and Mouser with a 47 week lead time ... I think those are what's making it harder for Stern to crank out this particular node board).

    #23 2 years ago

    Unfortunately I don't think anyone looked any further on how to program. Based on the way the system is architectured, there is a very strong suspicion there is a basic bootloader installed on a blank board which allows it to interact with the RS485 bus and get programmed with the relevant firmware.

    But I'm not aware of anyone investigating how to read the bootloader to reflash it.

    Given the current supply situation, it would definitely make sense to raise it to Stern. If you need to wait for one year to get a replacement node board, that's NOT cool.

    #24 2 years ago

    megadeth2600 I'm not convinced that your MCU is dead. First you need to solve the 3V3 problem since that rail powers the MCU. Find and remove the short, then confirm that you are getting a stable 3.3V rail. Is the yellow LED1 doing anything?

    To answer your question nonetheless, the node board hex files are included on the game's SD card, however they are crypted.

    The LPC1313 has a bootloader ROM which is accessible via CN1. It may be possible to read the flash contents through that, and then use the result to flash a blank part - you will need a SWD programmer which supports Cortex-M3. But again, I would first sort out the power supplies.

    #25 2 years ago

    Fubar At first, only the 48V LED was on. After I replaced the regulator, the 6V LED came on. The voltages looked smooth on my scopemeter.

    The yellow LED indicating that the CPU is at least limping is out.

    As I mentioned, the two diodes that drive the input of the 3.3V regulator burned up . The one diode driven by the 6V rail burned up when I put the board in the game after replacing the 6V regulator. When that happened, there was some smoke and some coils were enabled/locked on. I shut the game off immediately.

    I moved to the bench (I should have frigging verified everything on the bench at first ... my damn arrogance led me to believe that the problem was fixed and that the game would fire right up ... that's the last time I try and impress my son ... makes me feel like an ass since I have a frigging nice power supply to debug this stuff ... idiot!).

    I powered up the VPROG node with 6V driven by an external supply. This burned up the other diode that is connected to the input of the 3.3V regulator.

    I also removed the 3.3V regulator ... still a dead short on the 3.3V rail. I had pulled a couple of caps off the 3.3V rail hoping one of them may have shorted ... that appears to not be the case. I am reading about 2 Ohms from 3.3V to ground.

    There aren't many other components on the 3.3V rail ... there are some passives, the CPU obviously, a logic gate, and the TX optocoupler IIRC ... I guess I could pull everything else and see what happens. Given where I am at with the board, I was going to put an external 3.3V source on the 3.3V rail on the board and hope to see something smoke a little to give me a hint, but I also don't want to risk burning up any pads on the PCB (these PCBs are *cheap* ... I mean they are just above trash level ... its disgusting that they charge $9K+ for machines now using such shitty PCBs ... I'd expect better in commercial equipment, but I digress ... you cannot so much as go a few degrees over the melting point of solder or else you risk losing pads ... fortunately, I only lost one, and it is really easy to work around it).

    This is frigging ridiculous that Stern won't provide some basic firmware that would allow one to flash the board themselves and allow the game to update it to the appropriate version. The cheapest I've found this particular board is $400 (I refuse to pay that ... I can wait) ... they were able to be had for $130 from some places, but they're sold out everywhere. It seems that the coil driver transistors and the gate driver ICs they use are unobtanium right now (they have a 46 week lead time at Mouser and Digikey).

    From what I understand, Stern uses these same node boards in toppers ... that's probably why they want their code encrypted. If they don't, there'd be a million "interactive topper" options out there. I wish they'd just make a damn encrypted node board for that crap and leave the ones that are required to play the damn thing unencrypted.

    Are you positive that the firmware is encrypted? I've seen people speculate that it is, but your post is the first time I've seen someone confirm it. If it is encrypted, that means that it's worthless to probe the bus and try and capture it.

    #26 2 years ago

    You could try using a thermal camera maybe, see which component gets warm?

    If you pop the game's main SD card in a computer running linux (or macos) you will find .hex files for the node boards. These are encrypted.

    I doubt the actual flash on the node's MCU is encrypted though; it might be possible to lift it via SWD.

    #27 2 years ago

    From what I have determined, the cpu uses 2 x 3.3V rails, one for the core and the other for the I/O.
    The chances are like a few node boards I have here is that the CPU has one of these rails shorted.

    Don't stress the boards with mods and hacks unless you know what you are doing.
    Have seen a lot of cabinet nodes(node1) being damaged from wrong shakers to incorrect wiring of coin mechs.

    You can't get the spike1or2 cpu to programme a blank node CPU, it requires the address of the node to A:know it's there and B:know what code to send it.
    The address dictates what sort of node it is.

    Interesting side project.
    Parts are getting harder to come by to repair them, hopefully the shortage will be over by the time my stock levels require topping up.

    9 months later
    #28 1 year ago

    Did anyone ever decode the Spike 2 node board protocol?

    I wanted to spoof an Stern Insider Connected QR code reader. I cant imagine there is that much comms between it and the MPU board.

    Reply

    Wanna join the discussion? Please sign in to reply to this topic.

    Hey there! Welcome to Pinside!

    Donate to Pinside

    Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!


    This page was printed from https://pinside.com/pinball/forum/topic/stern-spike-bench-testing-eg-520-7017-72d-node-board-?hl=mdeslaur and we tried optimising it for printing. Some page elements may have been deliberately hidden.

    Scan the QR code on the left to jump to the URL this document was printed from.