Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
According to the BCM20732TAG schematic (page 13 from 920732TAG00-HWUM100-R), doesn't the SW5 (Boot from ROM push button) connect to VDDIO when pushed? But I do find it strange that the push button connects to VDDIO, since the SDA is pull-up anyway.
The answer to your question must lie in the means by which the pin is sampled in firmware during the boot process. I believe this to be the case because the I2C spec requires a pull up on SCL and SDA. In addition, I am told that the internal pull up is not sufficient because it will not be "configured" until an I2C slave is detected.
If VDDIO is present on SDA, then the part bypasses the step where it looks to the EEPROM for a valid image and goes directly into programming mode. However, the previous entries in this post seem to imply that you can also GND the SDA pin and see the same behavior.
I will ask someone from the Apps team to add some clarity to this behavior.
I Looked into this and as it turns out, connecting SDA to Vdd/Vio to recover is not optimal.
SCL and SDA are both open-drains and the internal pull-ups are actually pulling the signal high while the hardware drives it low (i.e. hardware never drives the pin high, but it floats the output pad leaving the pull-up to pull the line high). If you were to put a scope to either of these signals during firmware access, you will see high to low transitions that are very sharp while the low to high transitions will be fairly slow due to the intrinsic RC.
If you connect SCL/SDA to Vdd, when the hardware block drives SDA low, there will be a direct short (though momentary) between Vdd and GND, which is not ideal (even if the recovery works fine). This will happen pretty early during boot process because the ROM always uses 0xA0 as the slave address of the EEPROM and you will be able to see that there are repeated 0s in this sequence (and the shorts) which may cause issues with the supply or the chip itself.
Shorting to GND on the other hand is safer because that's precisely what happens when there is a 0 bit on the bus and there is a 10K pull-up, which will limit the current to something within the max ratings of all components on this line.
The reason recovery works under this scenarion is because the data on the i2C bus is invalid when its shorted to GND. When the ROM tries to read from slave 0xA0, the actual data bytes on the bus are overridden to 0x00, which is not a valid slave. Once this occurs, the ROM immediately gives up on the EEPROM and goes into download mode if uart is also connected.