CC1352R: A strange I2C problem on a custom board

Hi Moshe,

Let me understand the issue:

1. Does it mean I2C lines are pulled down or pulled up but no communication is happening?

moshe jacobson18 said:

IF I NOW cycle power to the board i notice that there is NO communication on the I2C lines.

2. Is the rest of the application running or everything is halted when you don't use the debugger?

3.Is everything powered when not using the debugger?

4. Could you share a code snipped where you initialize the I2C drivers, and the your SysConfig?

5. Could you try it running it without the debugger and the oscilloscope? Does it work?

Best Regards,

Daniel

Hi Daniel

Thanks for responding..herewith answers.

1. I2C lines are pulled up & remain so..no comms happen.
2. rest of application runs fine.
3.everything is powered.
4. I2C_Params i2cParams;
I2C_Params_init(&i2cParams);
i2cParams.bitRate = I2C_100kHz; //I2C_400kHz; //I2C_100kHz;
i2c = I2C_open(CONFIG_I2C_0, &i2cParams);
sysconfig - see attached.

5. the only reason i ran it with the scope was because it wasn't working.

The question i really have is what is the connection between the jtag lines (& MCU pins) and I2C???

regards

moshe

Hi moshe,

I'm not sure yet.

Are you calling I2C_init() before I2C_Params_init ?

Can you check this case (+) CC2640R2F: I2C operates well while connected to the debugger but now while powered externally - Bluetooth forum - Bluetooth®︎ - TI E2E support forums

This sounds like some sort of sleep related issue. When you have the debugger connected, the chip is not able to go down to sleep due to the JTAG connection/ active debugging. 

But when you power cycle, the chip is probably able to go down to sleep. I would test how this impacts the I2C driver and the GPIOs set up by the driver. 

Hi Daniel

yes.. I2C_init() called in main.

I looked at that case, unfortunately not applicable here.

kind regards

moshe

Hi 'theGhostOf'...unfortunately i have both LEDs & UART comms that function completely after a power cycle so that precludes the chip going to sleep.

However, there must be some connection between debugging and I2C, but damned if i know where to even start looking.

[edit update]
I noticed that there is a difference when connecting the LP1352R vs LPXDS110 which may shed some light on the issue...
With the LP1352R, so long as the LP is connected to the XDS110 on the LP (CC1352 completely isolated) i can recycle the power on my custom board and I2C will function.
However, if i have the LPXDS110 connected, i have to power up the LPXDS110 when i recycle power on my custom board before the I2C will function.

So can the debug chip itself have a role to play in this??

Hi moshe,

Sorry, I think I'm not following your latest update.

If your custom board is connected to the 1352R Launchpad (through the JTAG connector?), while the LaunchPad is not powered, it will work alright? and the XDS110 jumper connections to the LaunchPad are open?

Best,

Daniel

Hi Daniel

Yes..in the case of the 1352R LP all jumpers (except the XDS pwr/Extern pwr which has XDS pwr jumpered) are removed & i use the JTAG connector my custom board I2C correctly.

But something that may shed light on the issue...Pin TDI
With the 1352R LP TDI is at 3.2V
With the XDS LP TDI is at 0V
However, if i REMOVE the XDS pwr/Extern pwr jumper on the 1352R LP then TDI remains at 0V after a power cycle & I2C does NOT function thereafter (just like the XDS LP)....yet when i REINSERTED that jumper whilst my custom board was powered, i noticed that my custom board performed a reset (I have LEDs to indicate that) and I2C functioned correctly - i did not perform a physical power cycle in this instance.

So...TDI has some kind of effect but it is NOT resolved if i simply supply the TDI pin with 3.2V because i tried that with a jumper wire...or is it that the TMC on the 1352R LP is getting power via the JTAG and sending a signal to my CC1352R via TDI???

regards
moshe

- Are you using 2- or 4 pin JTAG? (typically the JTAG start up as 2 pin and then you have to set in the tool that you want 4 pin)

- By default, GPIO17 is used as an IO, but as 4 pin JTAG, this pin is used as TDI. Have you double checked that you are not using this GPIO for something else on the board?

- The LP-XDS110 and the the top part of the CC1352R LP are conceptually equal, the JTAG part is the same. Hence by first look it doesn't make sense that they behave differently. Would you be able to provide some pictures that clearly shows the working and non working connection between the debugger and your board? A (partial) schematic of your board that shows the JTAG connection and the I2C part could also help. 

the debugger is not powered up so the question of is it 2 pin or 4 pin should not be relevant. As it is, when i have used the debugger (both of them) i have never set whether the connection is 2 pin or 4 pin....in fact it never ocurred to me & imagined it was 4 pin because the provided connection was 4 pin..

All the pin assignments were performed in ccs-sysconfig & it didn't report any conflict...all peripherals used retained their default pin assignments & the GPIOs that were specifically assigned as I/O certainly dont use DIO17.

I agree that the whole situation doesn't make sense.

see attached for schematic.

my take is that TDI is the centre of the problem...now to read up on it.

[edit] perhaps i'm looking at this all wrong...perhaps i should be asking "can i leave the JTAG tracks floating when no debugger/loader is connected"...in which case where i can i find information on how the JTAG traces should be routed/connected/powered?

[further update] i have just discovered something which may shed light on the issue....
1. i DISCONNECTED the dubgger.
2. i cycled power, and as expected I2C didn't function after that.
3. I then cycled the 'reset' pin (the board has a jumper to GND) and THAT resulted in the I2C FUNCTIONING thereafter!
Power is supplied from USB to a LDO that outputs 3.3V to the 3.3V net, the RESET jumper merely routes the 3.3V net to GND.
Is it possible that the I2C must only be brought up AFTER a minimum startup time?

Hi moshe,

Did you follow the LAUNCHXL-CC1352R1 schematic for reference?

Does the issue also happen when you have the XDS110 power jumper in the other position?

There is a system reset when you activate a debug connection. So maybe it is related to the startup. Have you tried running the I2C drivers examples from the SDK?

Best,

Daniel

Hi Daniel
unfortunately, in the process of doing all the various jtag pin testing i now have a 'locked' CC1352 & cant download any further code to the chip.

(https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1549160/cc1352r-oops-i-locked-my-mcu/5960182)

regards

moshe

Hi moshe,

That's unfortunate. I'll work with Marie on the other thread so we can come back to this.

1. Could you send a photo of your setup?

2. As I understand, there is no issue with the LaunchPad running the same code? The LaunchPad is powered through the XDS110, could you disconnect all jumpers in between CC1352 and XDS110, and power the CC1352 from the 3.3V header? Conceptually I think this is the same as your custom board.

Best,

Daniel

Hi Daniel

I actually cant run the same code on the launchpad as the pin assignments are different....but....what i now suspect is that the I2C issues are due to timing issues...

on powerup the mcu is ready & i send a query to the i2c device before it has actually got itself together....but...
when using my reset jumper; whilst that brings the reset pin down to 0V, the 3.3V to the I2C device remains 3.3V so the device never powers down & is now  ready as soon as the MCU came up.

Somewhere along the line i did use that reset jumper yet still had a problem with the I2C device. However, that must have been an aberration & resulted with my going down the rabbit hole of debuggers & their reset actions.

So i now suspect i've been wasting everyone's time & appologise for that, and in the process i've disabled my chip...alas, such is dev life.

once i get a working board i'll be able to test my timing suspicion & i'll report back.

on another note, 'the ghost of' asked me 4 days ago "Are you using 2- or 4 pin JTAG?"..as it turns out i discovered today where that setting is in the ccxml file via CCS, it had been set to 2 pin all the time...but as it is, when i developed the board i catered for a 4 pin connection.

regards
moshe

Hi moshe,

No worries! Let us know how it goes.

Best,

Daniel