We have a custom PCB that has a yield problem. Around 10% of all the boards we produce, the boards won't boot. The problem has been identified as an invalid boot mode. We have the boot pins configured for SPI1 FLASH boot. On the bad boards, the boot config register is loaded with 0xFF(which is invalid). It is suppose to be 0x0C for SPI1 boot. A board that is "good" is always good, and a board that is "bad" is always bad. Of course we have verified that the pull down/up resistors on the BOOT pins are correct for the bad boards.
We can emulate from the bad boards, so functionally they are good. We have also verified the power rails, and RESET pulse are good with no glitches. The C6748 is held in RESET for 250mS after all the power rails stabilize.
Scoping the pins, the bad boards have the following behavior: 1.2V ramps to 100%, while the 1.8V and 3.3V regulators are held OFF. 1.8V ramps next to 95%, which then releases the 3.3V rail to start ramping. BOOT[0](which needs to be low for SPI1 FLASH boot) is indeed low for the 1.2V and 1.8V power ramps. As the 3.3V begins to ramp up, as it reaches around 1.2V, the BOOT[0] pin snaps to 1.2V as well. As the 3.3V rail continues to ramp, so does the BOOT[0] pin. The BOOT[0] pin stays HIGH for the entire time RESET is held LOW. Once RESET goes high(and this is where the boot pins are "saved"), the BOOT[0] pin goes LOW(as it should have all along because there is a 20k pull down resistor on the line). Why the BOOT[0] snapped HIGH during power up is the mystery.
According to the C6748 datasheet and tech manual, everything is correct. 1.2V rail ramps first, followed by the 1.8V rail, and finally the 3.3V rail. The 3.3V rail never exceeds the 1.8V rails by 2V(which is one of the power on requirements). The RESET pulse is more than long enough after the rails stabilize. Pull up/down resistors are stuffed correctly for SPI1 FLASH boot(1k pull ups, 20k pull downs).
I see other people on this forum talking about boot problems, but not specifically with the C6748. Are there other C6748 users out there that have experienced a similar problem? If so, did you find a solution? TI experts, is there anything you find wrong with our power up sequence or other things we should check?
- Dean