I2C SDA/SCL toggling when being programmed and connected to a host

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

cross mob
AnBa_330971
Level 2
Level 2

On our custom board, BCM20737S is connected to PIC32 processor over I2C.

BCM20737S is the I2C host as it can only work as a host.

I can send and receive data using the cfa_bsc_OpExtended coomand. 

So the I2C interface is working.

The only issue is that when the BCM20737S gets connected to an Android (BLE host), it seems to send out some packets (NULL characters?) over the I2C to the PIC.

I observed/verified the line toggling by monitoring the SDA/SCL lines on a scope.

Also I can use a debugger in the PIC32 and detect I2C packets.  The content of the I2C packets looks like NULL characters, when falsely transmitted.

I triggerred the detection of I2C packets by setting up an IF statement with monitoring the STOP status. 

However, due to the NULL character transmission, the I2C detection occurs undesirably, overwhelming the true packet detection.

I've added another condition to filter out the undesirable packets when the first byte is a NULL character, and this seems to work reliably.

However, I would like to really understand why getting connected to a host or getting the BCM20737S programmed would cause the I2C bus to be active, making the I2C slave to respond unnecessarily.

Thanks,

Andrew

0 Likes
7 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

I can't see the link...

Did you enable any debug trace? Disable it.

Is it possible to connect to a iphone host using an app like "LightBlue"?

If yes, does the issue still exist?

Do you see the issue if I2C is connected to something else eg a sensor (or nothing for that matter)?

0 Likes

I disabled ble_trace's by adding the BLE_APP_DISABLE_TRACING() .  The problem still existed.

#include "sparcommon.h"

...

APPLICATION_INIT() {

.......

  BLE_APP_DISABLE_TRACING();

}

Then I commented all ble_trace just to be sure.  The SCL/SDA lines are still toggling when getting connected.

I then commented out the I2C read/write commands.  The problem is still there.

And yes, I used "LightBlue" in addition to our custom app.

I've also downloaded the Wiced Sense code.  The same thing.

Attached is an photo of the scope traces (1 for SCL and 2 for SDA), when the BCM20737S gets connected, i.e.when you click on the BLE device name on LightBlue to connect.

i2c_issue.JPG

0 Likes

Is it possible to provide a USBee trace? Btw, what is your external pull-ups on the SDA/SCL? 10K?

0 Likes

I monitored the I2C data that was detected in the interfaced MCU.  The data was 'NULL'.  I believe the I2C address was correct.

Yes, the pull-ups are 10K. 

What I can do is to monitor at the SDA/SCL lines on Wiced Sense kit, which I have.

I supposed I can do something similar with TAG03, which I also have.  But I do not believe the I2C on TAG03 is connected to sensors.

Would it be possible for you to do something similar on your side?  I am just going to solder two wires on SDA and SCL and look at them on the scope.

0 Likes
AnBa_330971
Level 2
Level 2

btta

I just revisited this issue with TAG3 board.

The same thing occurred.  When you press the RESET or reprogram, the I2C signals toggle, similar to what I observed on our custom board.

I think what may be happening is that somehow the BCM20737S is trying to talk to an EEPROM or some configuration device.

Is there anything in the code that may cause this, an automatic search for programming device?

Thanks,

Andrew

0 Likes

Yes. When 20737S boots up, it will start with the boot rom code, followed by discovery of any external storage. It will look out for an eeprom on the I2C, and if one is not found, it will then look for sflash on SPI. In most cases, it will detect the eeprom and carry on from there.

0 Likes

The Boot Sequence is described here in the July 31st, 2015 response: BCM2073XS Boot Sequence: Can't download to board (device not found)

Step 2a.