BCM20736S recovery problem - SDA high does not enter recovery mode

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

In our BCM20736S-based design we have noticed that we cannot enter recovery mode.  Our design exposes SDA (pint 22) so we can drive it high when necessary.  But the normal sequence: 1. hold SDA high. 2. reset 3. release SDA does not put the device in recovery mode.  When attempting a recovery, the download logs show the following message:

11:17:29.077  Will be downloading 0 bytes of code and 4931 bytes of data without a minidriver

11:17:29.077  BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp

11:17:29.077  The config data is coming from the following files

11:17:29.077  build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.hex

11:17:29.077 Sending bytes to HW:

4 bytes:  01 03 0C 00

11:17:29.081 Received bytes from HW:

8 bytes:  04 1C 08 04 0C 60 00 F0

(...)

11:17:29.179 Received bytes from HW:

8 bytes:  04 1C 08 04 0C 60 00 F0

11:17:29.179 ERROR: Failed to execute HCI Reset

This happens on boards that we can program normally, so we have ruled out UART/cable problems.

We can also observe activity on SDA on boot, so we know that SDA is properly accessible.  Below is SDA activity on a normal reset.

good-board-sda.png

Anyone out there has experienced similar recovery problems?

Best,

Javier

0 Likes
1 Solution
Anonymous
Not applicable

We finally received the 3.3V FTDI cable and we have recovered all our boards.

Lesson learned:  do not use a 1.8V FTDI cable (TTL-232RG-VREG1V8-WE FTDI, Future Technology Devices International Ltd | 768-1070-ND | DigiKey).  Our 1.8V cable can reliably program devices but cannot recover them.

Thanks for everyone's support!

View solution in original post

21 Replies
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

mwf_mmfae

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.

4. Execute:

./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 ****

Logs attached.

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:

-MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER)

Recovery also fails, but with a different error.  This second log is also attached.

We are really out of ideas here.  Any suggestions?

Thanks,

0 Likes
Anonymous
Not applicable

Ah, I should say we are using a FTDI-1.8 USB-to-UART cables for programming.  I see from other users (ehoffman) 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...

Anonymous
Not applicable

jcardona,

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.

Anonymous
Not applicable

Hi @ehoffman,

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!

Best,

Javier

Anonymous
Not applicable

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).

0 Likes
Anonymous
Not applicable

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. bcmLogic.PNG

Anonymous
Not applicable

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

RESET Error:

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...

Cheers,

Javier

Anonymous
Not applicable

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

Anonymous
Not applicable

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.

Cheers,

Javier

0 Likes
Anonymous
Not applicable

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?

0 Likes

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.

j.t touches on this in his blog here as well: I2C Discussion

jcardona ehoffman jose.raffucci gmelcer

0 Likes

Note that I created a new category called "Recovery' and tagged/grouped the threads I felt were relevant to the recovery process as I know these are sometime hard to find: WICED Smart Forums

Anonymous
Not applicable

mwf_mmfae,

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.

Best,

0 Likes
Anonymous
Not applicable

I just re-read myself and I don't think I was very clear.  Let me explain below the experiment I'd like you to conduct:

1. Power up a TAG3 with USB cable.

2. Turn dipswitch 2 off.

3. Press and hold BOOT_ROM switch

4. Press RESET

5. Release BOOT_ROM switch

6. Turn dipswitch 2 on

7. On host, 'make ... recover'

On our TAG3 boards, this FAILS.  And the same happens with dipswitch 1 and 3.

However, if we leave the dipswitches on recovery works.

This recovery procedure looks like a poorly designed (and documented) hackjob from here...

Per the instructions in the WICED Smart Quick Start Guide (SDK 2.1 and TAG3 Board), all of SW4's dip switches should be left on.

0 Likes
Anonymous
Not applicable

Yes, but based on the instructions posted on this thread by a Broadcom engineer:  Re: Unable to (re) program BCM20736 , also reproduced above, the UART must be disconnected (which is the equivalent to turning OFF dipswitches 1-4). 

So I guess the forum instructions are incorrect?

0 Likes

I don't recall the specific context in that thread, but the gentleman who was helping the user in the thread designed the firmware, so it's unlikely that method is incorrect (appears to be another method to achieve the same result for some).  I have not had time to study the schematic and SW4 to determine if the advice given maps directly to all SW4 switch settings = OFF.


Since I am limited in my understanding of how the firmware works internally, I typically refer users to the method in the Quick Start guide as we can support that process without having to get the developers involved.

Anonymous
Not applicable

Thanks, mwf_mmfae,

Right now our only theory is that the 1.8V FTDI cable might be producing voltage levels that marginally work.  If recovery draws slightly more current than normal firmware download, it might be enough to bring the levels on the UART signals below the minimum threshold.  That is the only explanation I can think for why normal download would always work and recovery always fails, with the same board and the same 1.8V cable.  As you see this is a very weak theory but we'll see.

We will only be able to test that theory next week when we receive the 3.3V FTDI cables.

Thanks,

Javier

0 Likes
Anonymous
Not applicable

We finally received the 3.3V FTDI cable and we have recovered all our boards.

Lesson learned:  do not use a 1.8V FTDI cable (TTL-232RG-VREG1V8-WE FTDI, Future Technology Devices International Ltd | 768-1070-ND | DigiKey).  Our 1.8V cable can reliably program devices but cannot recover them.

Thanks for everyone's support!

This is great news! Enjoy the holidays.