Quoted from TheLaw:So what are the odds that they are actually released in February?
Didn't say which February.
I sincerely wish for this to be true.
I am still waiting for the GB code update that was promised for last September.
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,,,,,,,,,,,,,,,,,,,,,,,
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.
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.
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.
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.
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.
Do we believe that the criticisms about Spike voiced here on Pinside somehow motivated Stern now to take action?
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
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.
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.
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.
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.
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.
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?
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.
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.
Quoted from benheck:I'll narrow it down - have node boards stop working completely after an update for anyone?
yes
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.
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.
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).jpegQuoted 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
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!
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?)
I am reaching the conclusion reading this thread that even with schematics, Spike games will not be repairable for most of us.
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..
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.
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.
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?
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.
Wanna join the discussion? Please sign in to reply to this topic.
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.