(Topic ID: 235445)

Stern Spike Node Board Schematics Troubleshooting and Discussion

By JodyG

5 years ago


Topic Heartbeat

Topic Stats

  • 478 posts
  • 109 Pinsiders participating
  • Latest reply 21 days ago by HDBrian
  • Topic is favorited by 70 Pinsiders
  • Topic is sticky in its sub-forum

You

Linked Games

No games have been linked to this topic.

    Topic Gallery

    View topic image gallery

    520-5318-00C Schematics.pdf (PDF preview)
    520-5321-00C Damage (resized).jpg
    20231219_014212 (resized).jpg
    520-5321-00C-Schematic-ELG-Node-Board.pdf (PDF preview)
    pasted_image (resized).png
    distri 48 (resized).png
    power distri (resized).png
    520-5321-00 Rev C Damage (resized).jpg
    520-5321-00C-Schematic-ELG-Node-Board (1).pdf (PDF preview)
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    pasted_image (resized).png
    449c7152735c92a1d5955972e59e167599aec98f (resized).jpg

    Topic index (key posts)

    4 key posts have been marked in this topic

    Display key post list sorted by: Post date | Keypost summary | User name

    Post #147 Link to individual Stern PDFs of Spike schematics Posted by HighVoltage (5 years ago)

    Post #171 PDF of the available schematics. Posted by PinMonk (5 years ago)

    Post #411 Fault and current measurements go to the microcontroller. Posted by mbwalker (1 year ago)


    Topic indices are generated from key posts and maintained by Pinside Editors. For more information, or to become an editor yourself read this post!

    There are 478 posts in this topic. You are on page 1 of 10.
    38
    #1 5 years ago

    Stern has now released schematics for the Spike system node boards. Please refer to the the key post index for updates. Vireland's post #171 has a condensed PDF with all node board schematics released to date.

    Screenshot_20190205-165528_Chrome (resized).jpgScreenshot_20190205-165528_Chrome (resized).jpg

    #2 5 years ago

    Finally!

    Now those more knowledgeable than me, can tell us if they can be fixed

    #4 5 years ago

    Yea!! And I don't even own one.

    #5 5 years ago

    So what are the odds that they are actually released in February?

    #6 5 years ago
    Quoted from TheLaw:

    So what are the odds that they are actually released in February?

    Didn't say which February.

    #7 5 years ago

    I sincerely wish for this to be true.

    I am still waiting for the GB code update that was promised for last September.

    10
    #8 5 years ago

    Call me sarcastic, but I'll believe it when I see it.

    #9 5 years ago

    All generation of Spike Schematics would be greatly appreciated.

    This would give more confidence to purchasers and sales for Stern pinball.

    There is nothing super secret about Pinball board setts.

    I like the direction that Spike takes

    Low maintenance and easy change

    Good call by Stern

    Serial BUS systems is the only way to go for modern pinball !

    Yes they can be fixed
    Schematics will make repairs possible

    The trick part is silicone component identification
    If Stern chooses not to share well,,,,,,,,,,,,,,,,,,,,,,,

    #10 5 years ago
    Quoted from RA77:

    All generation of Spike Schematics would be greatly appreciated.
    This would give more confidence to purchasers and sales for Stern pinball.
    There is nothing super secret about Pinball board setts.
    I like the direction that Spike takes
    Low maintenance and easy change
    Good call by Stern
    Serial BUS systems is the only way to go for modern pinball !

    whaaaatttt? good call? maybe for their pocketbook.

    #11 5 years ago

    IF this is like the code update promises; I wouldn't hold my breath.
    Stern promising to do anything other that take your money; is to be taken with no warranty what-so-ever.

    #12 5 years ago

    I wonder if they will be specific schematics for each version of each board. Eg, Spike 1 node 8 vs spike 2 node 8. Or spike 1 cpu vs spike 2 cpu.

    Or will they only release spike 1 schematics and say spike 2 are coming soon.

    #13 5 years ago
    Quoted from Luckydogg420:

    I wonder if they will be specific schematics for each version of each board. Eg, Spike 1 node 8 vs spike 2 node 8. Or spike 1 cpu vs spike 2 cpu.
    Or will they only release spike 1 schematics and say spike 2 are coming soon.

    I guess TBD. Watching this with interest; if some previously "unfixable" boards are now able to be repaired that will be great news.

    There is a bit of my mind that is in the "I will believe it when I see it" camp, but at this point it is on Stern to step up and deliver. I am willing to give them that chance; the worst case scenario for pinball owners is come March 1, 2019 we have as much information as we do now.

    It is definitely good news they have come out and stated some intentions here.

    #14 5 years ago

    I hope they release them and some qualified electrical engineers weigh in with their opinions of the design and reliability. Maybe it'll be possible to make some daughter boards which could add redundant safety measures to prevent one node board from taking out others.

    #15 5 years ago

    Following

    #16 5 years ago

    Do we believe that the criticisms about Spike voiced here on Pinside somehow motivated Stern now to take action?

    #17 5 years ago
    Quoted from branlon8:

    Do we believe that the criticisms about Spike voiced here on Pinside somehow motivated Stern now to take action?

    When the community is considering to send your boards to China to have them reverse engineered, you have little options left. People will figure out these boards with or without help from stern. But schematics and a parts list would make it a whole lot easier

    #18 5 years ago
    Quoted from branlon8:

    Do we believe that the criticisms about Spike voiced here on Pinside somehow motivated Stern now to take action?

    I certainly hope so. However, there are some other things which *should* be included in this forthcoming "manual":

    Schematics for Spike 1 and Spike 2 boards.

    Schematics for all of "The Pin" models (Transformers, Avengers, and Spiderman).

    Full listing of the Spike system menus and adjustments. Game specific adjustments should be included too for games where this information was left out of the original game manual.

    Rant on other Stern stuff:

    How about code updates for "The Pin" series?

    Why aren't "The Pin" machines even listed or mentioned on Stern's website?

    How about manuals for "Pabst Can Crusher" and "Primus" ? These machines aren't even mentioned on Stern's website except under code updates.

    How about revising the Whoa Nellie manual? I've found a bunch of errors and omissions in it.

    #19 5 years ago
    Quoted from KenLayton:

    How about manuals for "Pabst Can Crusher" and "Primus" ?

    Are they different enough from Whoa Nellie! Big Juicy Melons that they need their own manuals? Seems like you could add a few pages with game specific parts and use one manual for all three.

    #20 5 years ago
    Quoted from branlon8:

    Do we believe that the criticisms about Spike voiced here on Pinside somehow motivated Stern now to take action?

    Without question. Stern is not stupid. They may not participate much on Pinside, but you can bet your ass they read everything here that's related to their company. The node board thread has undeniably lead to an erosion of confidence in the Spike system. That is clearly not good for Stern's bottom line, and this is their way of addressing the problem.

    #21 5 years ago

    Do game updates cause nodes to brick?

    If yes I have more to say...

    #22 5 years ago
    Quoted from YeOldPinPlayer:

    Are they different enough from Whoa Nellie! Big Juicy Melons that they need their own manuals? Seems like you could add a few pages with game specific parts and use one manual for all three.

    Cabinets are physically different. Playing/scoring is different. Backglass is different. Cabinet decals are different. Switches/controlled lamps would be different. They could combine all that information in one manual.

    #23 5 years ago
    Quoted from benheck:

    Do game updates cause nodes to brick?
    If yes I have more to say...

    Yes and no. Some people have had problems right after an update.

    #24 5 years ago
    Quoted from KenLayton:

    Yes and no. Some people have had problems right after an update.

    I'll narrow it down - have node boards stop working completely after an update for anyone?

    #25 5 years ago

    Does anyone know what to do with them when they do get released?

    Just kidding. I’m sure someone does, but it sure as hell isn’t me.

    #26 5 years ago
    Quoted from branlon8:

    Do we believe that the criticisms about Spike voiced here on Pinside somehow motivated Stern now to take action?

    Of course.

    The moment Stern heard that the masses were about to find out that those $219 boards cost $12 to manufacturer they decided to get out in front.

    Those reverse engineering houses always give you a quote for them to build you replacement boards, so it would be a no brainer to run a batch of replacement boards - every Spike owner would buy a few.

    #27 5 years ago
    Quoted from benheck:

    I'll narrow it down - have node boards stop working completely after an update for anyone?

    yes

    #28 5 years ago
    Quoted from benheck:

    I'll narrow it down - have node boards stop working completely after an update for anyone?

    also, code related issues with early code seems to be more prone to causing issues that later code updates.

    Multiple operator friends which get early games/code are more likely to have experienced problems.

    There are often cases when a code push is quickly followed with another push the day after due to node issues from the original.

    #29 5 years ago

    The SPIKE node boards would cost a lot more than $12 to reproduce... but still miles less than the retail cost.

    Also (and pertaining to my conversation with Hilton above) they have microcontrollers (MCU) on them. It's possible the system update also updates the firmware on the node boards MCU's which could cause failure or in some cases "brick" them.

    Thus even though the boards are certainly repairable that won't help if the MCU itself needs re-flashing. You could buy a replacement but without the right code to flash back onto it it's still a doorstop.

    I kind of doubt Stern would release the source because then there's nothing stopping people from making clones. Even if they released the compiled source as a HEX just for flashing it could still be reverse-engineered.

    #30 5 years ago

    Great news..stern releases schematics.
    Bad news..paper flock is administering the release.

    #31 5 years ago
    Quoted from benheck:

    The SPIKE node boards would cost a lot more than $12 to reproduce... but still miles less than the retail cost.
    Also (and pertaining to my conversation with Hilton above) they have microcontrollers (MCU) on them. It's possible the system update also updates the firmware on the node boards MCU's which could cause failure or in some cases "brick" them.
    Thus even though the boards are certainly repairable that won't help if the MCU itself needs re-flashing. You could buy a replacement but without the right code to flash back onto it it's still a doorstop.
    I kind of doubt Stern would release the source because then there's nothing stopping people from making clones. Even if they released the compiled source as a HEX just for flashing it could still be reverse-engineered.

    I thought someone looked up the data sheet for the MCU and it comes with a generic boot loader, although Stern may have a proprietary firmware installed. It’s beyond my skill level, but hopefully someone will figure it out.

    16EAB82C-0081-4A7A-A2BA-36F8E29A2AB3 (resized).jpeg16EAB82C-0081-4A7A-A2BA-36F8E29A2AB3 (resized).jpeg
    #32 5 years ago
    Quoted from benheck:

    It's possible the system update also updates the firmware on the node boards MCU's which could cause failure or in some cases "brick" them.

    I looked at one of the .spk with a hex editor and see comments here and there. You might be able to parse out if any of them update MCUs.
    # link to display processor image
    DISPLAY_LINK=display.hex

    # serial device for node bus
    NODEBUS_DEV=/dev/ttyS4

    #33 5 years ago

    The biggest issue for repair I can see is all those big Molex connectors blocking access to the surface mount stuff.

    Good luck snaking an iron or heat gun in there!

    #34 5 years ago
    Quoted from benheck:

    The biggest issue for repair I can see is all those big Molex connectors blocking access to the surface mount stuff.
    Good luck snaking an iron or heat gun in there!

    Aw, come on man. You know too that it's pretty hard to brick a modern setup that has a built in bootloader.

    With your skill set I'd love to see you be a champion for helping people work this stuff out, not bringing the whole thing down. Just my 2 cents.

    #35 5 years ago
    Quoted from Luckydogg420:

    I thought someone looked up the data sheet for the MCU and it comes with a generic boot loader, although Stern may have a proprietary firmware installed. It’s beyond my skill level, but hopefully someone will figure it out.
    [quoted image]

    No, these are programmed with spike specific boot loader code either from the manufacturer (how stern explained it to me) or by the in circuit programming header on the board. What I was told last year that along with schematics, pre-programmed parts would be available for replacement.

    Quoted from YeOldPinPlayer:

    I looked at one of the .spk with a hex editor and see comments here and there. You might be able to parse out if any of them update MCUs.
    # link to display processor image
    DISPLAY_LINK=display.hex
    # serial device for node bus
    NODEBUS_DEV=/dev/ttyS4

    The microcontrollers need to know the basics of how to communicate on the spike bus before they can be programmed and updated by what's in the .spk file.

    #36 5 years ago

    Surface mount parts are totally replaceable. You remove them by heating them up (either with more solder or an air gun) then pick them off when molten.

    Putting them back same thing. You don't have to solder every pin. You just glob on solder or Flux and heat again to flow all the solder then wick up the excess.

    Those molex connectors would get in the way. Also when device is built they are added last and with a different process because they'd melt in the same over used to reflow the surface mount. So theyd also melt if exposed to the temps of a rework air gun. Not an issue with larger boards but here everything is very tightly packed.

    So you'd be best off removing all molex in your way and then swapping surface mount chips. Some of the molex will be tough to remove if they have through hole ground planes (sucks up heat requiring more) and this will be compounded by the fact it is lead free solder (again, more heat required)

    From what Robf says above Stern will not release firmware. Makes sense as then the boards could be cloned. That's why they'd send you a chip pre-flashed. There's also ways to read-protect a chip so even if you have the right dev tools you couldn't just hook up and dump the flash.

    #37 5 years ago
    Quoted from benheck:

    I'll narrow it down - have node boards stop working completely after an update for anyone?

    That happened with me on my Batman66. It seems weird that a FW update would damage a nose board but it's happened with multiple people.

    Since the code on each of the node boards is getting reprogrammed during the update I wonder if the board hardware is fine but the code getting loaded into it gets corrupted somehow and just bricks the board. People assume the board is electrically fried but maybe it just programmed incorrectly.

    #38 5 years ago

    To program a blank MCU you need special devices. Atmel has the Dragon/ICE/AVR-ISP, Microchip has the Pickits. These plug into the programming/JTAG ports of MCU's and get them set up. This is done when the PCB's are built or you can order chips pre-programmed. But all of this is too expensive to build into a retail product that needs to update itself.

    That's where bootloaders come in. Using the above tools at the factory, you put a small bit of code at the start of flash memory, the "bootloader". This code can then program the rest of the flash memory using standard I/O built into the MCU (USB ports, serial RX TX or in the case of SPIKE the CAN bus).

    Using Arduino as an example: The board has a USB-serial converter chip, making it easy to plug into a PC. When the Arduino starts the bootloader code executes. It waits 1 second to see if any commands come in over serial bus (are you trying to program it?) If not, the main code is executed. If commands do come in, it enters programming mode.

    Programming mode is part of the bootloader. It receives commands over serial such as "fill this area of flash with this data" and "check data". It only re-programs the flash memory above itself so in theory it can't be bricked unless it somehow erases itself. That should never happen. It's like Chapter One of a book being able to rewrite every other chapter but itself never changes.

    Which then begs the question "how could a node board become bricked?" Here is my theory. Looking at the above example we see the bootloader only executes when the system boots (or the MCU is manually reset) If the system is already powered up then the node boards themselves are also pass the bootloader stage and also running (waiting for commands from the main processor)

    The game asks "UPDATE?". You select YES. OK great. So assuming the node board(s) must be re-programmed as part of the update how do they re-enter bootloader mode if they've already started?

    My guess is the main processor sends them a command to reset themselves / vector back to bootloader code. Then the main processor would proceed to send the re-programming commands as described above.

    Here is where the problem comes in. If for some reason that programming process fails, and the main code area is corrupted, then the node board would lose the ability to respond back to the main processor and re-enter bootloader mode. That doesn't mean it can't be re-programmed, but it lacks to ability to receive commands to put itself into that state.

    Again this is just my theory. It could be fixed with with code and failsafe flags that ensure the node MCU always can revert to a programmable state. I'm just speculating the conditions under which it could enter an UN-programmable state.

    #39 5 years ago
    Quoted from benheck:

    That's where bootloaders come in. Using the above tools at the factory, you put a small bit of code at the start of flash memory, the "bootloader". This code can then program the rest of the flash memory using standard I/O built into the MCU (USB ports, serial RX TX or in the case of SPIKE the CAN bus).

    Spike is not CAN. It is RS-485. That means non standard protocol.

    #40 5 years ago

    When I get infinitely bored … without a day job; Maybe I'll plug an oscilloscope to the RS-485 buss and try to snoop on the data being sent.
    With recent MPF support:
    http://docs.missionpinball.org/en/latest/hardware/spike/
    it'd probably be a lot easier to program a test pattern that would enabled reverse engineering of the proprietary protocol.

    #41 5 years ago
    Quoted from Zitt:

    When I get infinitely bored … without a day job; Maybe I'll plug an oscilloscope to the RS-485 buss and try to snoop on the data being sent.
    With recent MPF support:
    http://docs.missionpinball.org/en/latest/hardware/spike/
    it'd probably be a lot easier to program a test pattern that would enabled reverse engineering of the proprietary protocol.

    If they have already wrote software that can communicate with the node boards they must already know all the commands. You don't even need the firmware from stern you could technically just simulate what it does and write your own. It might not have all the fancy self updating features but can at least do all the basic functionality. Would be easier if stern did sell pre loaded micros though but would most likley charge a lot.

    Certainly looks more promising making after market boards though.

    #42 5 years ago

    The node board hex files can easily be pulled from the game .spk file. Just extract the Linux image from them using the pyhton script from here. In the game directory there are these files for GoT 1.34: coil4node-LPC1112_101-0_19_1.hex
    coil4node-LPC1112_201-0_19_1.hex
    coil4node-LPC1313-0_19_1.hex
    game
    image.bin
    lcdnode-LPC1113_302-0_19_1.hex
    pinnode-LPC1112_101-0_19_1.hex
    pinnode-LPC1112_201-0_19_1.hex
    pinnode-LPC1313-0_19_1.hex

    "game" is the elf executable, that can be dissected using IDA. There is the update routine, the node board list and the firmware suffixes inside. What I have not yet understood is which the files for the same MCU type goes to which boards (xx-LPCyy-101-zz or 201).
    And there is the risk that these firmwares might not be the complete content of their flash and there is another bootloader in there which is NOT in the spk.. However node boards dying during updates speaks strongly against that - and also speaks against Stern using NXPs bootloader/protocol.
    Regarding the NXP bootloader, has anybody with a broken node board ever tried replacing the MCU and just plugging it back in?

    You can also check out some more details on spike from the other scripts in the firmware, notably the /etc/init.d/ directory has game, game_monitor and update files which are just shell scripts for the startup. In there you can also see that the spike node bus is just a plain simple UART...
    Note that if "game" isn't there, startup continues to a pretty large "spike menu". I wonder what that is?

    #43 5 years ago
    Quoted from cynric:

    Regarding the NXP bootloader, has anybody with a broken node board ever tried replacing the MCU and just plugging it back in?

    Yes. I attempted to fix a dead node board (the one the shaker plugs into) and found the uC was dead and was pulling down the 3.3v rails. I replaced it with a new part and while that fixed the voltage measurements, it was unable to be found on the bus. It is only an educated guess, but my conclusion was the parts required a base level of firmware (perhaps even above a bootloader) to be pre-programmed in order to do basic spike discovery and acceptance of commands and updates.

    #44 5 years ago

    If you can pull the hex files from that update has any one tried installing the hex onto the micro via its programming port? (is it exposed on the spike boards?)

    #45 5 years ago

    I am reaching the conclusion reading this thread that even with schematics, Spike games will not be repairable for most of us.

    #46 5 years ago
    Quoted from RobF:

    Yes. I attempted to fix a dead node board (the one the shaker plugs into) and found the uC was dead and was pulling down the 3.3v rails. I replaced it with a new part and while that fixed the voltage measurements, it was unable to be found on the bus. It is only an educated guess, but my conclusion was the parts required a base level of firmware (perhaps even above a bootloader) to be pre-programmed in order to do basic spike discovery and acceptance of commands and updates.

    Thanks for the info! Yup, then they use a custom update mechanism. Maybe the original NXP bootloader does even listen on the node bus uart, but that does not seem fit to talk to it with the other nodes in between.
    However if the programming port is present on the node boards as @russdx said, then you could try flashing the MCU via JLink or some other ARM programmer with one of the hex files from the update archive. Still don't know if 101 or 201 is the right one, but chances are they are for different revisions of the boards. I have not yet disassembled and compared them, but judging from the hex files there are differences, but most of the content is identical. Maybe there is a revision printed on there? Also the filenames indicate that the 4 driver nodes were also made with the LPC1313..

    #47 5 years ago
    Quoted from cynric:

    Thanks for the info! Yup, then they use a custom update mechanism. Maybe the original NXP bootloader does even listen on the node bus uart, but that does not seem fit to talk to it with the other nodes in between.
    However if the programming port is present on the node boards as @russdx said, then you could try flashing the MCU via JLink or some other ARM programmer with one of the hex files from the update archive. Still don't know if 101 or 201 is the right one, but chances are they are for different revisions of the boards. I have not yet disassembled and compared them, but judging from the hex files there are differences, but most of the content is identical. Maybe there is a revision printed on there? Also the filenames indicate that the 4 driver nodes were also made with the LPC1313..

    In the other thread are some photos of the boards and right near the micro is a very small connector i suspect might be the programming interface not sure what type though. It might be how stern get the firmware on there in the first place if the chips are not coming pre flashed.

    #48 5 years ago

    Likely the base code is loaded wherever the boards are made. In almost every PCB there are unpopulated pins or pads present for re-programming.

    Custom bootloader or no, it sounds like a failed program attempt can leave these boards in a state of being unresponsive. This could be a power brownout, or your kid tripping over the power cord.

    These HEX files... are they Intel HEX or binary? If Intel, then they contain pointers to which area of memory they should be written to. This could tell you if they're being placed above a bootloader or not.

    #49 5 years ago
    Quoted from benheck:

    Likely the base code is loaded wherever the boards are made. In almost every PCB there are unpopulated pins or pads present for re-programming.
    Custom bootloader or no, it sounds like a failed program attempt can leave these boards in a state of being unresponsive. This could be a power brownout, or your kid tripping over the power cord.
    These HEX files... are they Intel HEX or binary? If Intel, then they contain pointers to which area of memory they should be written to. This could tell you if they're being placed above a bootloader or not.

    Does stern make you buy a new board if its bricked? And all they do is reflash it then sell on?

    #50 5 years ago

    Yes there is an in circuit programming port. From the little homework I did, it looks properly connected to be used with the fully populated board. I had planned on building a reader to see if the code could be extracted and loaded onto a new part. The hope is, it isn't read protected. I just haven't found the spare time for that yet. But for those thinking this could be great for building cheap knock offs, keep in mind this is copyright protected code, any attempt to redistribute could be infringement without proper license.

    To be clear this part of the conversation is only relevant for repair when the uC needs replacement. Schematics and a little experience is all that is needed for everything else. Overall this is a great step forward.

    There are 478 posts in this topic. You are on page 1 of 10.

    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-schematics-coming-this-month 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.