Cannot program BCM20737S, I2C problem

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

cross mob
KoM_2154881
Level 3
Level 3
First like received First like given

I tried to use the I2C bus to communicate with an external device (accelerometer). I followed the i2c temperature sensor example and tried to write to a register.

After that I can't program the bluetooth anymore. My problem is exactly the same as in Re: cannot recover or program BCM20732S B1 After that error happened, I am getting an error stating "BluetoolDownloadMinidriver failed!".

Then I followed the instructions in Re: Downloading problems with BCM20736S but I am getting an error stating "Failed to execute HCI Reset".

I noticed that someone in the first post that had the exact same problem as me said that he had a problem with the I2C bus, although he didn't give any more details.

Do you have any ideas on what is happening here? I am sure that it has something to do with the i2c bus but so far nothing I tried really worked.

Thank you in advance.

0 Likes
1 Solution

Hi kmichalopoulos​,

Given that your sensor is a bus slave, it shouldn't be occupying the bus and preventing 20737 from booting. *unless you, as the master, started some large data transfer from the sensor then immediately tried to reboot only the 20737--that could cause problems. 

Can you elaborate on how you separated the power supplies? Would the sensor and the 20737 chip still exist on the same voltage bus, just with a switch in the middle? Or are they truly separate voltage buses? And with this separation, where did you pull the i2c lines up to? The sensor's bus or the 20737?

If you tried to put them on entirely different buses this could certainly introduce problems if there is a voltage difference between the two buses. The only way I know to isolate voltage levels on an i2c bus is via i2c expander or level shifter. Without either of these, master, slave, and pull ups should all be on a common bus.

For an example implementation of an i2c expander, see the WICED Sense schematic (U4 on page 1): WICED Sense Reference Design Schematic (PDF)

If you want to send your schematic, I can take a look at it and see if anything sticks out to me.

Jacob

View solution in original post

10 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

1. This could be an addressing issue. What are the addresses of the peripheral devices on your i2c bus?

2. What value pull-ups do you have on the line?

3. How many i2c devices are on the bus? -> what's the total pf load?

4. What frequency and voltage are you running the bus? And does this meet the spec of the devices you have on the bus?

One valuable approach would be to scope the voltage on the i2c bus during boot. If I'm understanding correctly, it seems that the boot process is being corrupted by signals or voltages present on the i2c bus. Alternatively, it could also be corruption of the EEPROM through noise or conflicting addresses.

Jacob

We are looking now at the voltage of the I2C bus. One difference that we noted from before is that SDA is now low all the time. Maybe that is the problem, although I am not sure why it's low now.

I only have one external device on the I2C bus. There should be no conflict with the address (it's 0x1C). I will look for the rest of your suggestions and let you know.

Regards,

Kostas

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

The problem is certainly a result of the low voltage on the bus. That will send the chip into recovery mode, but if the SDK isn't recovering the fw then everything will fail.

I'm not sure what could be causing the low voltage besides a short or a bad i2c device.

Jacob

0 Likes

Yes, it sounds reasonable. We are using a 10k resistors for the pullup but it doesn't seem to be enough. Do you have any recommendations for the pull up resistors?

We are also looking if we have something else there that may pull the line down.

Regards,

Kostas

0 Likes

10k should be the maximum value of pull ups and should be sufficient for almost any sensor. I don't believe that this issue could be a result of pull-up value.

Do you have the ability to rework your board? If so, a good test will be removing the sensor and seeing if the bus voltage comes back up. If the voltage comes back up then you can narrow it to either incorrect wiring of the chip or a bad chip all together. If not, probably a short somewhere.

Jacob

0 Likes

Ok, thank you. I will let you know how the outcome.

Kostas

0 Likes

We weren't able to recover the board. We had to replace the BLE chip with a new one. I have a couple of questions though.

We moved to the BLE evaluation kit (TAG3) and we attached the accelerometer there. Everything worked fine for a couple of rounds.

I was able to program the tag and get the values from the accelerometer. I moved the accelerometer to its own power supply to emulate the board setup. In the board as soon as you plug the serial everything powers up. Using this setup, I was able to program the tag the first time, but I failed every time after that, until it bricked and I had to do the recovery procedure.

So, I guess that the after the first time, the accelerometer is active and working and since it was never turned off (never took the serial cable off the usb), it is still occupying the I2C line preventing us from further programming the BLE. Do you think that this is the problem that we are facing? If that is the case then we just have to make sure that the accelerometer is reset before programming the BLE.

Kostas

0 Likes
Anonymous
Not applicable

Hello.

Have you tried programming the tag without the accelerometer connected? i.e. can you program TAG3 multiple times without any peripherals connected?

If so, you know for a fact that the accelerometer is the problem.

These comments might help you to understand the process better.

Re: firmware programming through FTDI VCOM 22 to BCM20736S

Re: firmware programming through FTDI VCOM 22 to BCM20736S

Things to make sure:

1. Turn off any peripherals in your software when done using it. (you should be able to turn the accelerometer on/off in your software)

2. When programming:

     a. Assert HCI UART RX high (i.e. pin2 on SW4 is ON. In fact, when you are programming, make sure all of them are ON)

     b. Don't forget to press reset button to go into programming mode before you actually program the device.

James

0 Likes

Hi kmichalopoulos​,

Given that your sensor is a bus slave, it shouldn't be occupying the bus and preventing 20737 from booting. *unless you, as the master, started some large data transfer from the sensor then immediately tried to reboot only the 20737--that could cause problems. 

Can you elaborate on how you separated the power supplies? Would the sensor and the 20737 chip still exist on the same voltage bus, just with a switch in the middle? Or are they truly separate voltage buses? And with this separation, where did you pull the i2c lines up to? The sensor's bus or the 20737?

If you tried to put them on entirely different buses this could certainly introduce problems if there is a voltage difference between the two buses. The only way I know to isolate voltage levels on an i2c bus is via i2c expander or level shifter. Without either of these, master, slave, and pull ups should all be on a common bus.

For an example implementation of an i2c expander, see the WICED Sense schematic (U4 on page 1): WICED Sense Reference Design Schematic (PDF)

If you want to send your schematic, I can take a look at it and see if anything sticks out to me.

Jacob

We do not have any more problems with that. It looks to me that when we tried to program, data were transferred. The problem was that we shared the same supply line and when the programmer was attached both devices are powered up. We could program the board many times without problems but once in a while what I described could happen. I suspect the reason is that we weren't taking  the programmer cable out, so the line was active when we were programming. As you said that caused problems. Now, we make sure that everything is unplugged and powered off before programming and we haven't face any new problems.

Thank you for your help,

Kostas