Just wanted to update our status after a full day wasted on this issue. This has stalled our development and putting the whole project at risk, so I would really appreciate any help you can provide.
In order to simplify the variables we have tried to use one of our working (no-bricked) boards and a pristine SDK 2.2 release:
1. Hit RESET and execute:
./make hello_sensor-BCM920736TAG_Q32 download BT_DEVICE_ADDRESS=random UART=/dev/ttyUSB0 DEBUG=1 (...) Downloading application... Download complete Application running
2. Verify application us running by observing advertisements and reading characteristics over BT
3. Hold SDA-high, RESET, release SDA.
./make proximity-BCM920736TAG_Q32 recover BT_DEVICE_ADDRESS=random UART=/dev/ttyUSB0 DEBUG=1 (...) Creating OTA images... Conversion complete OTA image footprint in NV is 5111 bytes Recovering platform ... **** Recovery failed - retry ****
After this the board can still be programmed.
We also tried to modify the recover_using_chipload target in the makefile to not use minidriver by removing the argument:
Recovery also fails, but with a different error. This second log is also attached.
We are really out of ideas here. Any suggestions?
Ah, I should say we are using a FTDI-1.8 USB-to-UART cables for programming. I see from other users (userc_7511) that:
"I think we had a 1.8 volt problem when programming with the TAG board as the middleman. Since I am using a 3.3V FTDI USB to UART cable now instead of the Tag board, the voltage looks fine and we are getting data/program into the Sip module." (Source: Programming the BCM20736S on a custom PCB)
I don't know why a 1.8V cable would successfully program a board and yet, be unable to recover it. But we have ordered a 3.3V cable and we'll try with that...
1 of 1 people found this helpful
For us the problem with 1.8 volts was that it is at the bottom edge of what the voltage regulator will tolerate on our custom board. (wish we had known that sooner ).1.8 volts may be fine for you.
One possibility that comes to mind. What is the voltage on the SDA pullup? What is the voltage you are operating the BCM module at? I understand from the BCM20736 datasheet that minimum voltage for logic high is your operating voltage minus 0.4 volts. So if your BCM has VDD at say 2.5 volts, then you need at least 2.1 volts on SDA for it to be seen as a 'high'. Take this with a grain of salt though, because my field is software, not hardware.
I see in your log files that there seems to be a problem writing to the BCM's EEPROM memory which is connected to the SDA/SCL lines of the module. A couple of things come to mind... not sure if any of these apply to you.
1. If the SDA were somehow still high after you released it, could that interfere with writing to memory.
2. Does your schematic have the pullup on P1 ?
3. In our case we had an external memory chip on the SDA/SCL I2C bus and it just happened to have the same address as the BCM's internal memory EEPROM, and we believe there was a conflict which manifested as a CRC error on dowload. Do you have any other devices connected to SDA/SCL?
4. ? last and probably least... bad BCM module? I think you said you tried multiple boards.. so probably not.
hope this helps. I know how you feel. We were spinning wheels too and under the gun to make progress. If you contact your Broadcom rep they can put you in touch with more personalized support if the forum is not getting you what you need. We got some great help from 79rpm and with some minor schematic changes might be back on track soon.
Oh... one more thought. On the off chance that your "Reset" button is not working, maybe try to hold the SDA high during power up and release it only after the device is recognized in the computer (for windows it shows up in the device manager COM section).
Thanks for taking the time to offer advice. I believe I've covered all the issues you mention (some of them I learned from your responses in other threads). Namely:
1. Regulator. We don't use one and the 20736S seems to allow as low as 1.65V, so I don't think we are facing the same issue you saw witht hat.
2. For recovery reset, we short SDA to 1.8V, which is the same as VDD, so I think it is driven high.
3. SDA is properly released after reset.
4. Yes, we have a pull up on P1.
5. No additional devices connected to SDA/SCL, only a test point.
6. Bad module? Hard to tell, but I have 6, but bricking them rapidly...
Did you help? YES. As I said, your answers in other threads were very useful, and your moral support, even more!
1 of 1 people found this helpful
Sorry, made a mistake in the post above regarding logic high level. The one I gave was output HIGH. The HIGH for the input is 0.75 times VDD. So at 2.5 volts, login high for input is 1.875 (meaning 1.8 probably would give a high, but not guaranteed). Here is the snapshot of the page.
Noted, but in our design VDD is 1.8, so SDA should be high.
I also run a quick experiment: run a make recovery after a plain reset, and then repeated the process after sda-high + reset, then compare the output logs. Both fail, but the errors differ, so it seems as if SDA is doing something.
SDA-High + RESET Error:
21:35:14.312 ERROR: Failed to execute HCI Reset
21:36:52.396 ERROR: Download minidriver error trying to write 251 bytes to address 0x002010FB
Anyway, I should better stop before I lose all my hair...
Where are you guys getting instructions to drive SDA high for recovery mode? I've seen this now in several posts recently but the instructions I received a while back were the exact opposite -- Short SDA to GND (Re: Unable to (re) program BCM20736):
0. Remove UART connection to PC
1. Short SDA to GND
2. Power up the chip and wait for a couple of seconds or so.
3. Remove SDA to GND short.
4. Connect HCI UART for programming.
5. Try downloading with -NODLMINIDRIVER
That was direct experience. On earlier prototypes, we had never succeeded in entering recovery mode by following the instructions above. We were only able to do so by holding SDA high, which learned from the TAG3 schematics.
Hmm.. I never looked at the recovery section in the user manual. I guess I don't understand what the recovery mechanism is -- SDA is already pulled up on the TAG3 board. Does SW5 just prevent any data from getting sent on the bus forcing a timeout?
Can one of the Broadcom guys clarify?
Either technique should work.
If VDDIO is present on SDA during boot up, then the firmware bypasses the step where it looks to the EEPROM for a valid image and goes directly into programming mode (Re: 20732S-Recovery from FW download failure)
However, the previous entries in this post seem to imply that you can also GND the SDA pin and see the same behavior: Re: How can BCM20732S boot from ROM?
Connecting SDA to Vdd/Vio to recover is probably not optimal for the following reason provided to me by one of the senior firmware engineers.
SCL and SDA are both open-drain configuration and the pull-ups pull the signal high while the HW drives it low (never drives high, but floats the output pad leaving the pull-up to pull the line high). If you put a scope to either of these lines on the board when the firmware accesses these, you will see that high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC.
If you connect SCL/SDA to Vdd, then when the HW 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 because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip.
Shorting to GND on the other hand, is safer because that is 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.
Thanks for the explanation. Even though I have never seen a grounded SDA to work on our boards, I just tested that on a TAG3. Instead of pushing the BOOT_ROM button, I connected the SDA side of the switch to ground, and I was able to complete a recovery. So that confirms your explanation.
But there is something more: On the TAG3 holding the BOOT_ROM button + RESET with any of the dipswitches 1 to 3 off fails to enter recovery mode. So, after reverting the dipswitches to ON, 'make ... recovery' will fail. Could you run that experiment on your end? Should just take you a few minutes.
This would reveal that the ROM is doing something more than just checking for a valid EEPROM before entering recovery mode.