RTOS/CC1350: Problem with the TI-RTOS I2C example

Hi Tomasz,

Thanks for your reply, in answer to your questions:

• The example I am using is i2ctmp007 the link to it is here.
• I'm running Code Composer 8.1.0 with the compiler version TI v18.1.3.LTS.
• I'm not sure what RTOS version is running, in the project properties page (general tab > products ) the only box that is ticked is the Simplelink CC13x0 SDK version 2.20.0.38, there is a TI-RTOS aswell Version 2.21.1.08 and enabling that as well didn't seem to help. If I'm looking in the wrong place please let me know.
• The line in question that I posted above is line 911 in I2CCC26XX.c, which on my system is located at: <system>\ti\simplelink_cc13x0_sdk_2_20_00_38\source\ti\drivers\i2c\,

Presumably that's a different example or does simple link cover all the differences? If so does that mean that the i2c on the cc1350 is broken in the lower level drivers?

So I've checked and as far as I can tell there appears to only be a single silicon revision for the cc1350, which is 2.1, However the LP has had a few versions and I'm using v1.3, I doubt this has any relevance though.

There appear to be several versions of the SDK that have been released

• 2.20.00.38 (29 Jun 2018)
• 2.10.00.36 (12 Apr 2018)
• 1.60.00.21 (20 Dec 2017)
• 1.50.00.08 (28 Sep 2017)
• 1.40.00.10 (28 Jun 2017)
• 1.30.00.06 (08 Mar 2017)
• 1.00.00.13 (22 Nov 2016)

I've tried both the most recent (2.20.00.38) and the one which you said was the one the example had been compiled for (1.60.00.21) neither of which seemed to help.

George,

I have it working with the newest SDK ver. 2.20.00.38.

The example documentation says:
1. Run the example. Board_GPIO_LED0 turns ON to indicate driver initialization is complete.
2. The example will request temperature samples from the TMP007 and print them on the console. A total of 20 temperature samples are read/printed before the example exits. Console output should resemble:

and later
'getTempTask' - performs the following actions:

There is no getTTempTask!
Its job is served by mainThread.
mainThread does:
/* Open the HOST display for output */
display = Display_open(Display_Type_UART, NULL);
It does not use System_printf to write to the console as suggested at point 2.) above.
This 'console' name is really misleading!.
It opens a separate terminal to write to the host which is my laptop.

XDS110 debugger probe used on CC13110LP (and 1350, I hope) uses two virtual COMs on the USB connection to the host.

1. Connect only one LP via USB to your PC.
2. Check in Windows Devices Manager -> Ports, there will be two ports listed - XDS110 Class Application/User UART (COM##) and XDS110 Class Auxilliary Data Port (COM##).
3. Use View -> Terminal or open Putty or other terminal and use the COM port number for the XDS110 Class Application/User UART.
4. Setup your terminal. In my case: COM3, baud rate 11500, data bits 8, stop bits 1, parity NONE, flow control NONE.
5. You should now be able to type in a character in PUTTY and have it echoed back.

Please mark your post as RESOLVED.

Siri,

agree with you, I do not know non working examples on sub 1 GHz LPs.
You have said: but all examples are tested before they are released
and I have switched my thinking to all examples.

You: If the sensor was not connected, the driver would be initialized just fine, but you would not be able to communicate over I2C since the sensor was not there.
My fault.
In case of no sensor, LED0 would be turned on, however the message: "I2C Bus fault\n" would be sent to the console, which is not the console but the user application terminal.

By the way, I have found a bug within the i2ctmp007.c example.
Starting from line 112:

            /*
             * If the MSB is set '1', then we have a 2's complement
             * negative value which needs to be sign extended
             */

            if (rxBuffer[0] & 0x80) {
                temperature |= 0xF000;
            }

           /*
            * For simplicity, divide the temperature value by 32 to get rid of
            * the decimal precision; see TI's TMP007 datasheet
            */
            temperature /= 32;

The temperature is declared as uint16_t.
In case of negative values the temperature /= 32; statement makes rubbish.

The temperature should be declared as int16_t.
Within
Display_printf(display, 0, 0, "Sample %u: %d (C)\n", i, (int) temperature);
the temperature should be casted to int like above.

I can't try this right now but I will give it a go later today, but I'm not convinced that this will fix the issue as I thought the code was getting stuck waiting for the I2C transfer to complete and it wasn't returning from there. Would this solution mean that under the bonnet the UART is capable of blocking the I2C?

Hi, ok so it works but I don't really understand what it was that was breaking it.

Previously when I tried it it seemed to be hanging in the I2C section of the code if you stepped through it (though in fairness this could be a red herring). But more importantly, the logic analyser wasn't seeing any comms. and when I put a breakpoint on line 128 (Display_printf(display, 0, 0, "I2C Bus fault\n");) it would never trigger.

Now I'm seeing comms using the logic analyser which looks to be correct device address and a register with NACKs due to the slave being absent, and the code is running to completion.

But I had several attempts and redownloading the software (including tirtos_builds_CC1350_LAUNCHPAD_release_ccs). I don't understand what has now changed.

The good news the is the problem seems to have gone so I can try talking to the MPU6050, I'd just like to know why. 

I miss the days of simpler Micros :P

George