CC3551E: Verification of I2C1 Configuration in CC3551E & CC3501E Datasheet & SDK Support

Hi,

C3500 should be OK. Where are you seeing in on syscfg? have you done the pre-steps of copying the cc35xx device support to CCS? what do you see when you check the General Properties of the project? I am seeing CC35X1 under the 'Variant and Core'.

As for syscfg, I went ahead and checked it and it seems that the DS is correct and the syscfg is not. So the syscfg needs to be fixed.

Shlomi

Hi Shlomi,

Thanks for replying. It is great that you confirmed the DS is correct. In the Technical Reference Manual, I2C1 SDA is not mentioned in GPIO3PCFG Register. 
Yes, I can see CC35X1 under the "Variant and Core".

Could you please share a SysCfg update with the fix? Or what could be the best alternative way to assign GPIO3 to be SDA1?

Many thanks.

Cheers,

Robert

Hi,

Let me ask internally as the syscfg is not directly under the Wi-Fi group.

Regards,

Shlomi

Hi Shlomi,

I noticed I2C1_sda is not mentioned in GPIO3 section in CC35xx's Technical Reference Manual (Page 1172). We also tried to force GPIO3 to work as SDA but no signal transmitting.

Could you please check if we need to change the I2C1_SDA pin to another IO? I am working on the revision of the board and it is quite urgent to confirm the pinmux. 

Thanks a lot.

Cheers,
Robert

Hi Robert,

First, your query on syscfg had been moved to the team responsible for it and an updated syscfg or a patch would be supplied, the date is not determined yet.

As for the fact that GPIO3 is not working, it will need to wait until Tuesday where the HW engineer is back (since he is most knowledgeable on this part).

Regards,

Shlomi

Hi Robert,

one more question, what is the syscfg version you are using. I need the exact version since we can provide a fixed metadata until an official version is released.

Regards,

shlomi

Hi Robert,

we verified internally that the datasheet is OK, meaning that i2c1 data may use GPIO3.

How did you test it? how did you force GPIO3? the TRM is not updated at the moment to reflect i2c1 so how did you mux it?

Shlomi

Hi Shlomi,

This is great news that I2C1_SDA can use GPIO3. I need to check with our firmware engineer about the method he used. 

The SysCfg we are using is sysconfig-1.20.0_3600 which is from simplelink_wifi_sdk_8_21_02_01_ea.

Thanks.

Robert

OK, thanks for the update.

once you have the procedure you took, please share.

Shlomi

Hi,

please find a package for syscfg (the specific version you are using) to fix the GUI part.

give it a try and let us know if it works.

Regards,

Shlomi

I2C fix for 1.20.0+3600.zip

Hi Shlomi,
I'm also working on this problem.

What I've found thus far is when GPIO3 is configured by the 'new' sysconfig that the IOMUX value is 0x97 and the pinConfig value is 0x802. When the pin is configured as part of the i2c initialisation, the pin goes low and stays there. If I try to send an I2C transaction, I get two low going pulses on GPIO2/SCL and it stops there. 

If I set the iomux to, say , 0x6 for GPIO3, the pin goes high, but i2c doesn't work.

Hi Russel,

So with the new syscfg it still does not work?

if so, I will need to direct it to one of our HW engineers to further look into it.

Shlomi

Shlomi, 

correct. The ‘new’ sysconfig does not appear to solve the problem. Can you tell me what the correct iomux value is?

what do you mean by the IOMUX value?

The syscfg GUI should just let you pick the GPIO from the drop down. where do you see/change the IOMUX value?

I should've used the term 'pinmux'. 

Here's what gets generated by sysconfig:

/*

 *  ======== I2CWFF3_hwAttrs ========

 */

const I2CWFF3_HWAttrs I2CWFF3_hwAttrs[CONFIG_I2C_COUNT] = {

    /* CONFIG_I2C1 */

    {

        .baseAddr    = I2C1_BASE,

        .powerMngrId = PowerWFF3_PERIPH_I2C1,

        .intNum      = INT_SP_I2C_1_INTREQ,

        .intPriority = (~0),

        .swiPriority = 0,

        .sclPin      = CONFIG_GPIO_I2C1_SCL,

        .sclPinMux   = 6,

        .sdaPin      = CONFIG_GPIO_I2C1_SDA,

        .sdaPinMux   = 151

    },

};

I see, let me try and see if I can test it myself.

Shlomi

Hi,

Are you using the LaunchPad?

Please note that for GPIO2 and GPIO3 there are hardware soldering to a button and operational amplifier respectively.

So without disconnecting those, you cannot really test.

Have you disconnected those?

Shlomi

No launchpad involved.The GPIO can be toggled with no issue. What should be the correct configuration vs what sysconfig is providing?

Hi,

I double checked it with the internal mapping we have and also looked at the code.

Not sure how you determined the mux as 0x97 since it should only be lower 5 bits (mask 0x1F).

I can confirm that from the internal database, I can see that the mux should be 0x1C (28).

What you chose refers to ant_sel_3.

Again, I cannot test it locally yet but if you can test, it would be great.

Regards,

Shlomi

Shlomi,

The mux value of 0x97 was not determined by me - it was what was generated from sysconfig.
 

As per the sysconfig generated code snippet from above:

    .sdaPinMux   = 151

That is the value used to configure the GPIO pin. What do you want me to test? I've tried the 'fixed' sysconfig and this is what it gave me. I've also manually changed via debug pinmux values from 6 to 31. No dice.

Can you create a project that you think should work and I can try that? Rule out any silliness on my part.

Hi,

I did sit down with the tools team and you are right that it generates 151.

What I was saying is that I double checked with the hardware team and seems there is a mistake in the mux itself (so the 151 is actually not correct).

You can try yourself to manually change the 151 but it is best if we can try it locally first and verify.

Again, it would take some time since I need some hardware manipulations on the board as currently these GPIOs are occupied and used by on-board components.

Shlomi

Shlomi,

It's good to know I'm not going crazy! I have tried many things down to the register level even manipulating the I2C peripheral manually, so given the documentation I have, I'm reasonably confident I'm giving you correct information.

As per my previous post, I have also tried a number of pinmux settings, including 28 and not had any success. Unfortunately, I have a custom pcb, so my choice of pins is fixed. If I had the dev board, I could verify my code works with pin configurations that are known to work and rule out anything from my side but , alas, I can only work with what I have. 

I have been informed in another post that I2S support is expected Q3 this year. Is there an estimation as to when production devices, documentation and SDK is going to be released? Is Energia/Arduino support planned?

Currently I'm facing many battles developing with this chip due to lack of documentation and early SDK support and this is wasting a lot of time and effort. 

Hi,

This is absolutely understandable but this is not released yet so it comes with a "price" (which we try to reduce by direct support as much as we can).

 Energia/Arduino is not planned as far as I know.

Basically, around August time frame we should have everything released officially.

I assume i2s would be available by then.

I will try to see if I can pull this i2c off this week and let you know.

Regards,

Shlomi

Hi Shlomi,

Have you been able to test the I2C as per Russel's question?

Hi Jason,

Sorry, not yet as I am out. I should be back only on the 26th.

Regards,

Shlomi