CC1352P: I2C Drive Strength

...and BTW - please explain how to do this for SPI as well since I need the same for the SPI pins.

Thanks,
Tim

Note that it's not an requirement in the I2C standard (https://www.nxp.com/docs/en/user-guide/UM10204.pdf) that the I2C output reaches ground. 

Also note the "GPIO" section in http://www.ti.com/lit/ds/symlink/cc1352r.pdf which outline what you VOL will be when the DIO deliver current. This is relevant for I2C due to the pull-up.

Do you see voltage numbers that are outside the I2C spec and the datasheet?

Yes I am aware that it does not have to be at ground - that is just what I am normally accustomed to seeing or something close for normal I2C transactions.  As for what I am seeing with the default settings that comes with the SDK - it isn't even close to being within spec.  From using the scope and capturing an I2C sequence, it goes from 3.3V to 2.9 V during the transitions and using 3.3 K pullup resistor - 2 mA drive current ain't cutting it.  I step this up to MAX on the pins and it swings from 3.3 V to around 0.3 V which is good enough to get my I2C peripheral to successfully start operating. 

I really need a simple way to do this from the application with a simple API call and not have to dig into SDK files to figure out how to do this.  Please advise on how to do this without having to modify SDK files and pull them into my CCS project to get this to work.

Thanks,
Tim

Hi Tim,

In the latest SDK release (3.40 as of today), the I2C_Params structure (parameter used to call I2C_open) has a "custom" field. For the devices from the CC13XX / CC26XX family, this custom field can be used to pass a pin configuration to the I2C driver. In this case, custom must point on on a I2CCC26XX_I2CPinCfg structure. If the I2C_Params structure does not provide this custom field (or rather if this field point on NULL), the default pin configuration is used. You will find a code snippet describing how to set the I2C_Params' custom field  in the I2CCC26XX.h file, just above the I2CCC26XX_I2CPinCfg structure definition.

For the moment, the SPI driver does not provide such a convenient possibility. However, you can have look to SysConfig. There is a way to modify the output strength of the SPI pins.

Note: SysConfig also allows to modify the output strength of the I2C pins.

I hope this will help,

Regards,

Hey Clement:

Thanks for your response - understand your directions and will try this out.  This is rather confusing though.  For the CC3220, I can make the following call to increase the drive strength to the I2C pins:

PinConfigSet( 0, PIN_STRENGTH_6MA, PIN_TYPE_OD_PU );
PinConfigSet( 1, PIN_STRENGTH_6MA, PIN_TYPE_OD_PU );

I don't need to do this with the MSP432E4 since it's default settings have enough drive strength to interface to this same peripheral that I am using with the CC1352P1 and CC3220.  As for the SPI signals for the CC3220 and MSP432E4, I can do the following:

CC3220:

PinConfigSet( 4, PIN_STRENGTH_6MA, PIN_TYPE_STD_PU ); // SPI clock
PinConfigSet( 61, PIN_STRENGTH_6MA, PIN_TYPE_STD ); // SPI CS

MSP432E4:

GPIOPadConfigSet( 0x40058000, 0x04, GPIO_STRENGTH_8MA_SC, GPIO_PIN_TYPE_STD_WPU );  // SPI clock
GPIOPadConfigSet( 0x4005F000, 0x02, GPIO_STRENGTH_8MA_SC, GPIO_PIN_TYPE_STD );  // SPI CS

So why is there a call like this for the CC1352P1?  I think I understand what you are recommending I do to do this same thing, but this looks to be a lot more complicated vs just having a simple API call as I can do with the CC3220 and MSP432E4.  Why is that the case?

Perhaps more concerning is how I need to move to SDK v3.40.  So are you saying that I can't increase the SPI driver strength using SDK v3.20 - I must move to SDK v3.40?  If that is the case, then that is a problem since I am using older plugins that require me to use SDK v3.20.  Please confirm that this is the case that I need to move to SDK v3.40 in order to increase the drive strength on the SPI pins.

Thanks,
Tim

Hey Clement:

Thanks for your response and making it more clear. It would be nice to have an API call for the CC1352 as I am able to do with CC3220 and MSP432E4.  There is no SysCfg support for the MSP432E4 currently and it's not clear it this will be provided in the future.  In general, I would rather do this in an API call vs SysCfg since I don't want to necessarily apply the drive strength statically during the build, but dynamically depending on which peripheral I am interfacing to since some of the peripherals need more drive strength than others and I have multiple devices sharing the same SPI clock pin.

Thanks,
TIm

Hi Tim,

Just a chime in, there is such APIs available, that is what we refer to as "DriverLib". We do however discourage the use of these on top of the drivers unless you absolutely need to to not interfere with driver logic.

The CC13XX/CC26XX devices do not use the same concept of GPIO as the CC3200 and MSP432 on a software level. The base for almost all the CC13XX/CC26XX drivers is the PIN driver which grants ownership and control of pins at request. This also means that you would need to use the PIN API to update the config, just as you tried to do. The problem as far as I can tell is that you did not "extract" the PIN handle from the I2C object. If you start using DriverLib on top of this, the PIN drivers idea of the pin config and state might not be that of the actual DIO, which could cause issues in some cases (not saying it will, just that it could :) )

Hey M-W:

Thanks for chiming in.  It's unclear as to what type of calls you are referring to.  Can you provide an example or reference that provides more details as to how this would be implemented in code?

Thanks,
Tim

Hi Tim,

As for DriverLib, you would look at the IOC API:

http://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/driverlib_cc13xx_cc26xx/cc13x2_cc26x2/driverlib/group__ioc__api.html

To be more precise, look at the IOCIODrvStrengthSet() API.

Hey M-W:

Got it and understand - thanks for the details.

Tim