YOU MAY HAVE NOTICED...
..that da Bomb has an array of 32 RGB LEDs which flash in a number of fanciful patterns. The LEDs themselves are controlled by an ISSI IS31FL3736 LED controller chip. For the curious, we have a copy of the datasheet for it here: [datasheet]
The LEDs themselves are just tri-color devices: each package has a red, green and blue LED, all tied to a common ground pin. The LED controller adjusts the brightness of each color using pulse width modulation (PWM) of each LED's power supply.
This chip is controlled by the main CPU using an I2C (Inter-Integrated-Circuit) bus. I2C is a two-wire bus consisting of a data line and a clock line, and the design allows for up to 127 slave devices to be connected in parallel to the same clock and data lines (this assumes 7-bit mode -- it's also possible to have 10-bit addressing mode). It's even a multi-master bus, meaning that in theory any of the 127 devices on the bus can issue requests to any other device (though in practice this isn't often used).
In order to function correctly, every device attached to an I2C bus must have a unique device address, which is really just a number between 1 and 127. The address is encoded into the I2C read or write request that's sent over the bus. This is called in-band addressing, By contrast, the SPI bus design also uses shared clock and data lines, but requires that each slave be enabled or disabled using a chip select pin. (This means that for SPI, you need one extra wire for each device attached to the bus.)
Since there's only 127 possible addresses, and since there are many different kinds of I2C devices, most devices provide a way to customize the address to which a given device will respond, typically by setting the state of one or more address "strapping" pins. Connecting the pins to ground or voltage can change the state of one of the bits in the address. So while the manufacturer may design the chip to respond to a default address, the strapping pins allow the board designer to adjust it slightly. It's up to the board designer to ensure that if they connect multiple I2C slave devices to the same bus that they set each one to have a different I2C address so that they don't conflict with each other.
YOU MAY ALSO HAVE NOTICED...
...that our badge has these funny 6-pin connectors at the top and bottom edges of the screen. These are Shitty Add-On (SAO) connectors. There are various Shitty Add-Ons available from different builders which can be plugged into these connectors to add extra flair to your badge. The Shitty-Add On specification calls for 6 lines: 3.3V power, ground, I2C clock, I2C data, and two GPIO pins.
Not every Shitty Add-On uses all these pins: some just have blinky lights on them and only need the 3.3V power and ground pins. Some are more elaborate and can be controlled from the badge's CPU via the I2C bus. Of course this requires that the badge software have support for a given SAO, and not all of them do.
So why does this matter?
Well, as it turns out, da Bomb uses the same I2C bus for both its LED control chip and the SAO plugs. This was deemed a reasonable design choice since I2C can support multiple slaves: as long as no SAO uses the same I2C address as the LED control chip, everything should work just fine. What could possibly go wrong?
YOU MAY FINALLY HAVE NOTICED...
...that something has gone wrong. The 31FL3736 LED controller chip uses a default I2C bus address of 80 (0x50). As it turns out, this is the same address can conflict with other commonly used devices, such as I2C EEPROM chips, some of which have been used on some DEF CON 27 Shitty Add-On designs. This is a problem, because da Bomb is constantly sending out I2C write requests to the bus in order to generate the LED patterns, and any other I2C device using the same address may receive these commands and act erratically as a result. In the worst case, an EEPROM might mis-interpret these as commands which can overwrite the EEPROM contents.
This particular problem has been observed with the "Doom Guy" SAOs. It may also affect other "smart" SAOs.
Unfortunately it's not possible to fix this conflict with a firmware update to da Bomb. Changing the I2C address of the LED controller chip would require physical modifications to the board.
With that in mind, here's what you can do to work around the problem:
Q: I don't plan to put any SAOs on my badge. Do I have to do anything?
A: No. Just relax and breathe normally.
Q: I have an SAO and I want to connect it to da Bomb. What should I do to avoid any problems?
A: Before you plug the SAO into da Bomb, turn the LEDs off by performing the following steps:
- Go to the launcher screen and start the "Setup" app (it's the one with the ship's wheel icon)
- Look for the "Led Pattern" selection at the top of the screen with two arrows to the right of it
- Press one of the arrows to scroll through the patterns and select the one that says "Off" (the LEDs should all turn off)
- Press the "Save" button at the bottom right of the screen to exit the Setup app
This will halt all I2C traffic from the CPU. You should now be able to safely connect the SAO.
Q: I set the LED brightness control all the way down. Is that ok?
A: No, it is not. Setting the brightness to minimum reduces the LED current to 0, but if the pattern is not set to "Off," the CPU will continue to send commands to the LED control chip via the I2C bus.
Q: What if I do both?
A: That's fine. As long as you set the LED Pattern to "Off," the state of the brightness control doesn't matter.
Q: Am I guaranteed to have problems with the Doom Guy SAO?
A: Not necessarily. The builders of the Doom Guy SAO are aware of this problem and are working on a patch to avoid this issue.
Q: Why didn't you guys catch this sooner?
A: We never expected a sort of I2C inquisition. Also, it's called da Bomb: with a name like that, it shouldn't come as much of a surprise if it blows something up.