I had previously posted a question related to this problem here:
BCM20732S refuses to program
but I thought I would start a new thread since the problem may not be related to the EEPROM.
I have a design based on the 20732S that overall seems to work quite well. However, a few boards develop what appears to be a hardware problem with the UART after some period of time in use. Note that these boards are being used for development, so we reprogram them via the UART frequently (whereas in the application this will only happen once).
What we observe is that we will have a board that is working fine for a long time, and then at some point I try to program it via the UART and the board is no longer detected. From that point onwards, I can never get it to program again. There doesn't seem to be any particular event that triggers this, although in one case it happened after the serial line was accidentally disconnected during programming.
In trying to diagnose the problem I put a scope on the RX and TX lines of the UART, and I can see why the chip fails to detect.
Looking at the HCI serial port with a scope, I see unusual spikes on the TX line when the chip is transmitting. That is, I reset the chip with HCI_RX held high to bring it into the bootloader. Then, I use the IDE to detect and program. The IDE first goes through the detection process, and attempts to contact the boot loader over the HCI port by sending a string ‘ 01 03 0c 00 01 4d fc 05 1c d2 00 00 01 ‘. The chip responds with another string, but the response is garbled because of strange spikes that are occurring at exactly 1/10 the baud rate, at 11.52 kHz.
These spikes can be seen in the attached photo of the scope trace. You can see the blue trace is showing a bit on the TX line -- the chip is trying to respond to the detection string. However interspersed with the real bits are weird ramping up and spiking glitches. These are occurring at exactly 11.52kHz.
We are concerned about this problem because we are moving toward production and as yet we don't understand why this happens or what causes it. It might be OK if it is related to programming failure that only happens in development when we are reprogramming a lot from HCI (vs once in production)... but at this point we are nervous.
One more point to consider: we have found that we needed to add the PMU clock warmup time hack to get our boards to work, is it possible that this problem is somehow related to that?
I tried heating up the chip with a heat gun to see if I could program it, but this did not help. I have also attempted to hold down SDA on boot to try to reset the EEPROM, which did not work. I was doubtful that it would help, since the problem seems to be with the UART / bootloader.
So far on our development boards, this has happened on about 10% of the boards overall, which is a pretty high rate.
