SPI flash HOLD pin

[osresearch]

In #10 @Jerome-PS points out that that the SPI flash HOLD pin needs to be driven high oe else the flash doesn't operate. This might be why the small remotes are somewhat flaky with their flash chips. Marco's reverse engineered schematic above doesn't have this pin marked, although it was generated from one of the SiLabs modules, while the 2-pin remotes are custom by Ikea.

[osresearch]

Is there a way to detect which board the firmware is running on? If so then PF3 could be a GPIO for the Gecko boards, but dedicated SPI pin for the two button remotes.

[Jerome-PS]

Actually PF3 is not only SPI FLASH HOLD, but also SPI FLASH VCC for the remote (I supposed it is in order to be able to save its power when the remote is sleeping, since it operates on battery).
Also on the remote, the resistor in series with SPI_MISO is marked R5.

Also I could not at all format the FLASH without driving PF3 high. I could barely read 2 bytes of the identifier (power flowing through CS, SCK and MOSI's protection diodes), after that MISO always stayed at 0...

[osresearch]

That's the same behaviour I saw with the two button remotes -- the flash was almost functional for reporting its ID, but would never format or read correctly. Thanks for tracking down the HOLD/VCC wiring!

[Jerome-PS]

Is there a way to detect which board the firmware is running on? If so then PF3 could be a GPIO for the Gecko boards, but dedicated SPI pin for the two button remotes.

Well, one not very efficient way could be to try and talk with the SPI FLASH and if it does not respond, activate PF3 and try again...
I don't know where the LED(s) is(are) on other boards, but maybe it could be detected too? Although it could cause problems depending on what is connected to the pin by the user...