Jump to: navigation, search

Difference between revisions of "OPP Autofire Workaround"

(Issue:)
 
Line 8: Line 8:
  
 
'''NOTE:''' If you are going to test for this bug or any workarounds for this bug, try it first with coil power off. If you are using CobraPin products, use the yellow LEDs to verify correct operation with no stuck-on outputs prior to applying coil power.
 
'''NOTE:''' If you are going to test for this bug or any workarounds for this bug, try it first with coil power off. If you are using CobraPin products, use the yellow LEDs to verify correct operation with no stuck-on outputs prior to applying coil power.
 +
  
 
==Am I Affected?==
 
==Am I Affected?==
Line 13: Line 14:
  
 
The board firmware version is reported as something like "0x20300050". If you have 0x20300000 or 0x20300050, this bug could affect you.
 
The board firmware version is reported as something like "0x20300050". If you have 0x20300000 or 0x20300050, this bug could affect you.
 +
  
 
== Options: ==
 
== Options: ==
=== A) Flash new OPP version 2.x.x.x ===
+
=== A) Flash OPP version 2.4.0.0 or newer ===
A new firmware fix is currently in the works, but in the meantime, consider one of the other workaround options.
+
This bug was fixed in OPP version 2.4.0.0. Consider flashing 2.4.0.0 or later to your STM32 processors.
 +
 
 +
Pros:
 +
* Regression tested version
 +
* No config changes or vulnerabilities
 +
 
 +
Cons:
 +
* Flashing new firmware requires an STM32 programmer, STLINK software, and python 2.7 setup to run OPP configuration
 +
 
 +
 
 +
==== Instructions for loading firmware: ====
 +
Be sure to use the '''OppStm32.2.4.0.0.hex''' file or later from here: [https://sourceforge.net/p/open-pinball-project/code/HEAD/tree/trunk/Stm32Workbench/Gen3Images/ Gen3Images]
 +
 
 +
There are a couple versions of these instructions:
 +
 
 +
# [[Beginner's Guide to STM32 flashing]]
 +
# [https://openpinballproject.wordpress.com/2020/11/03/11-3-2020-loading-stm32-firmware/ Loading STM32 Firmware]
  
  
Line 32: Line 50:
 
* Could unintentionally fire coils from the dummy device if you accidentally connect the dummy switch to something
 
* Could unintentionally fire coils from the dummy device if you accidentally connect the dummy switch to something
 
* There could be a form of config where this does not prevent the bug from appearing
 
* There could be a form of config where this does not prevent the bug from appearing
 +
  
 
==== Example: ====
 
==== Example: ====
 
Check here for an example config with dummy devices: [https://github.com/cobra18t/CobraPin/blob/main/Errata/OPP_AutoFire_Workaround.yaml OPP_AutoFire_Workaround.yaml]
 
Check here for an example config with dummy devices: [https://github.com/cobra18t/CobraPin/blob/main/Errata/OPP_AutoFire_Workaround.yaml OPP_AutoFire_Workaround.yaml]
 
=== C) Revert to OPP version 2.2.0.0: ===
 
This bug did not exist in OPP version 2.2.0.0. Consider flashing 2.2.0.0 to your STM32 processors if you do not use the following features that were introduced after 2.2.0.0:
 
# Coil pulse power (kick PWM)
 
# RC servo support
 
# SPI LED support (APA102, SK9822, etc.)
 
 
Pros:
 
* Regression tested version
 
* No config changes or vulnerabilities
 
 
Cons:
 
* Flashing new firmware requires an STM32 programmer, STLINK software, and python 2.7 setup to run OPP configuration
 
* No longer have the most recent firmware features
 
 
==== Instructions for loading firmware: ====
 
Be sure to use the '''OppStm32.2.2.0.0.hex''' file from here: [https://sourceforge.net/p/open-pinball-project/code/HEAD/tree/trunk/Stm32Workbench/Gen3Images/ Gen3Images]
 
 
There are a couple versions of these instructions:
 
 
# [[Beginner's Guide to STM32 flashing]]
 
# [https://openpinballproject.wordpress.com/2020/11/03/11-3-2020-loading-stm32-firmware/ Loading STM32 Firmware]
 

Latest revision as of 00:03, 29 December 2022

Issue:

A bug was introduced in OPP firmware version 2.3.0.0 (November 2021) and persisted through 2.3.0.5. Under certain conditions, when you reconfigure an autofire coil, the coil can get stuck on.

The most common instance of this bug is when a dual coil flipper is configured with 100% hold power. If the flipper button is held while the ball drains, the flipper autofire device is disabled and the state of the flipper is frozen instead of reset to off. So after a drain, the flipper remains on even after the flipper button is released. When the next ball starts, the flipper device is re-enabled and all goes back to normal.

Similarly, if you have single coil flippers with 8% hold power, you have an 8% chance of seeing the bug if you hold the flipper button as the ball drains. While less likely than the dual wound case, this single wound condition is much worse since a coil intended for an 8% hold could get stuck on at 100% power. This will likely blow a fuse, transistor, coil, etc.

NOTE: If you are going to test for this bug or any workarounds for this bug, try it first with coil power off. If you are using CobraPin products, use the yellow LEDs to verify correct operation with no stuck-on outputs prior to applying coil power.


Am I Affected?

Run "mpf hardware scan" from your machine's folder with the hardware connected.

The board firmware version is reported as something like "0x20300050". If you have 0x20300000 or 0x20300050, this bug could affect you.


Options:

A) Flash OPP version 2.4.0.0 or newer

This bug was fixed in OPP version 2.4.0.0. Consider flashing 2.4.0.0 or later to your STM32 processors.

Pros:

  • Regression tested version
  • No config changes or vulnerabilities

Cons:

  • Flashing new firmware requires an STM32 programmer, STLINK software, and python 2.7 setup to run OPP configuration


Instructions for loading firmware:

Be sure to use the OppStm32.2.4.0.0.hex file or later from here: Gen3Images

There are a couple versions of these instructions:

  1. Beginner's Guide to STM32 flashing
  2. Loading STM32 Firmware


B) Add Dummy devices in MPF:

If you can prevent disabling an autofire device, you will not see this bug. One method of doing this is to setup a dummy autofire device in MPF. This method requires one unused direct input (two if your autofire devices span across both STM32 processor boards). You must create a dummy autofire device for each autofire device in your machine but all the dummy devices can use the same switch.

Pros:

  • No firmware flashing
  • Simple MPF config change

Cons:

  • Requires an unused direct input (potentially two if your autofire devices span across both STM32 processor boards)
  • Requires user to account for each autofire coil so the user could accidentally miss one in the MPF config
  • Could unintentionally fire coils from the dummy device if you accidentally connect the dummy switch to something
  • There could be a form of config where this does not prevent the bug from appearing


Example:

Check here for an example config with dummy devices: OPP_AutoFire_Workaround.yaml