More BCM20737S recovery problems

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

cross mob
Anonymous
Not applicable

Per this thread here: Re: BCM20737S recovery problems

I'm in the completely same trouble using a FTDI 3.3V torelant UART bridge. Really hoping to get any solution.

1 Solution
Anonymous
Not applicable

Thanks for the comments everyone, and sorry for the mixing up.

As mwf_mmfae mentioned, I use multiple sensors and I found that caused the problem.

One of the I2C device was un-powered  at the resetting moment because it is a multi power source circuit, then the u-powered device sunk the I2C bus power.

We solved all the issue.Thanks a lot!

View solution in original post

14 Replies
Anonymous
Not applicable

Hello 章愛 田中

Which FTDI 3.3V UART Bridge are you using?

Thanks

JT

0 Likes
Anonymous
Not applicable

I'm using TTL-232R-3V3 (cable type).

http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm

Thanks

Aki

0 Likes
Anonymous
Not applicable

No, our battery is 3Volts. And the problem occurs even without battery.

I have 3 different cases for our (same design) 3 boards.

1. HCI Reset Error

2. CRC mismuch

3. Chip Erase Error

Do you know some previous discussion?

0 Likes

Just to confirm, you are programming a custom BCM20737S based board using SDK 2.2 on Windows and the FTDI USB to Serial cable described above (this is powering the chip, not the battery). You are attaching to the HCI UART and have the appropriate pull-up on HCI Rx to ensure that the part comes up in programming mode as described here: Re: Programming the BCM20736S on a custom PCB

I am also assuming that when you program the TAG3 board with your application, everything works fine.

0 Likes
Anonymous
Not applicable

Thanks. I thought HCI Rx is already pulled low by 10k, isn't it? Should p18 be pull-ed up?

FTDI USB-Serial cable's TX is already pulled-up internally.

How much the pull-up resistor should I put?

Best,

Aki

0 Likes

can you attach the download log in the build directory?

0 Likes

Are there multiple sensors on the I2C bus (i.e. loading issue)?

Essentially, with regards to I2C on boot, 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: How can BCM20732S boot from ROM?)

However, the previous entries in this post seem to imply that you can also GND the SDA pin and see the same behavior: Re: 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.

0 Likes
Anonymous
Not applicable

I use that same cable successfully.  It comes 4 feet long or so.  When it was 4 feet long it did not work.  I tried lots of things but the only thing that worked for me was when I cut the cable down to about 1 foot long then it works every time.  Hope this helps.

ehoffman

0 Likes
0 Likes
Anonymous
Not applicable

Great to hear you solved the problem.  Thanks for sharing the solution.

For the sake of completeness I would like to add one thing to my comment above about that 4 foot cable issue (even though it was not your issue).  After reading another thread yesterday about some issue with recovery failing every time where download was working just fine,  I remembered this:

With my 4 foot FTDI 3.3Volt USB cable I WAS able DOWNLOAD successfully every time... I was just NOT ABLE to do RECOVERY with it.  It wasn't until I cut the cable down to 1 foot or less that I was able to recover.  Once that was done I was able to do recovery without any issues.

So it seems true, as speculated by the other forum contributor, that there is some significant difference between Recovery and Download with respect to the demands on the hardware that sometimes results in successful download but failed recovery using the same setup.  It's a mystery what exactly that difference is, but it can be useful to know it exists.

Anonymous
Not applicable

It's really great to know that. Thank you so much.

0 Likes
Anonymous
Not applicable

Thanks for the comments everyone, and sorry for the mixing up.

As mwf_mmfae mentioned, I use multiple sensors and I found that caused the problem.

One of the I2C device was un-powered  at the resetting moment because it is a multi power source circuit, then the u-powered device sunk the I2C bus power.

We solved all the issue.Thanks a lot!

Thanks for sharing the solution!