This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMP117: TMP117

Part Number: TMP117
Other Parts Discussed in Thread: TMP116, SYSCONFIG, ENERGYTRACE, CC2652R

Hi,

I'm trying to use the Launchpad CC2642R1 / CC2652R1 (HW Rev. B) interfaced to a Sensor device TMP117

The TMP117 works correctly using the CCS project:  i2ctmp116_CC26X2R1_LAUNCHXL_tirtos_ccs 

Also the Bluetooth stack works on the same launchpad using another reference project: simple_peripheral_CC26X2R1_LAUNCHXL_tirtos_ccs

But I have difficult to import  the Temperature sensor functions and the source header files from the first projects to the simple_peripheral... because they are built on two different SDKs:

1) simplelink_cc13x2_26x2_sdk_3_30_00_03 (the first project)

2) simplelink_cc13x2_26x2_sdk_5_20_00_52 (the simple_link project)

Is there any project, based on the same SDK that combines the Temperature sensor TMP116 or TMP117 source drivers with the BLE stack ? ....that can be used on the Launchpad CC2652R1 ?

alternatively which project can I best use as a reference design that combine the BLE transmission of the Temperature Sensors readings such as the TMP117?

Thanks in advance

Alessandro Finezzo

  • Dear Alessandro - 

    Welcome to E2E and thanks for the post-  Here I am moving your post to the CC26xx E2E Forum. 

  • Thanks Josh

    for now I'm still working with the first prj, evaluating the temperature sensor only, displaying the measurement on the terminal instead of as a variable transmitted through the BLE. And I can confirm it's really accurate and stable as expected with an update rate of 1 sec 

  • A question:

    How to reach all the posts in the Forum CC26xx E2E ?

    Following the forum link Wireless ...> Bluetoot... ? 

    (here I'm unable to see this, as a specific Forum)

    Many thanks

  • Alessandro - 

    I moved this to the [CONNECT]2.4GHz Forum, as this radio is operating on that frequency.

  • Hi Alessandro,

    I gather that you are referencing the SimpleLink Sensor and Actuator Plugin, however my recommendation is that you evaluate the i2ctmp TI driver example instead.  This firmware is initialized to read from a TMP116 sensor and uses the desired SimpleLink SDK version.  I also suggest that you develop your solution with the latest SimpleLink CC13XX/CC26XX SDK which is a continuation of the old CC13X2/CC26X2 nomenclature.  There is also a multi-sensor project which uses BLE to transfer temperature data (among other information) from a LPSTK-CC1352R1 which may be worth further investigating for your needs.

    Regards,
    Ryan

  • Thanks Ryan,

    I will follow your suggestions really appreciated. I can't complete all the steps in a short time but I hope to give you the feedbacks in a short time

    Sorry for my delay in this answer but I had some issues with the installation of the latest Monterey on my MacOS, after some updates in my CCS.

    The MAC was often crashing launching the Energy Trace tool with the latest LaunchPAD for BLE (but never before, when I was using the others for MSP430 and NFC chips). I updated the MacOS because the IDE was behaving unstable after the SDK installations & examples to work with BLE applications.

    So now I'm back to Catilina reinstalling all the SW and application projects! did you heard of trouble with the latest Monterey in combination with CCS & BLE ?

    Many thanks for all Ryan 

  • The only MacOS Monterey issue I am aware of is included is this external bug ticket.  There is a workaround included but this issue may not be relevant to the behavior you are reporting.  You can post a new ticket with further details if you experience more BLE SDK or CCS issues.

    Regards,
    Ryan

  • Thanks Ryan,

    here my feedback: following the suggestion to use the latest SDKs and to use the driver named I2Ctmp instead of tmp116 we were able to merge the example codes of the projects:

    i2ctmp_CC26....tirtos_ccs < and > simple_peripheral_CC26....tirtos_ccs

    So now the new project is built without errors and working correctly; reading the temperature from the sensors and sending them on BLE.

    And now we're dealing with the consumption optimizations, because we need to make it working on a CR2032 (or with a lower capacity as we can) surviving for many months & reading the temperatures with 1h of sampling rate.

    For this purpose we supposed to use the Digital IO pins to source the power supply VDD pin of the sensors, as it is made in the TMP116 BoosterPack. I'm so investigating about the given limitations coming from the RdsON max of the upper Mosfet in the output buffer combined with the minimum voltge required by the supply pin on the sensor, that is guaranteeing to work till the end of the battery life. I misured an excess in the drop voltage, such as 300mV, during the I2C cycles, mainly caused by the mosfet channel resistance of the DIO.

    I'll let you know about the results

    Have a nice day

    Alessandro

  • As you are most likely already aware, please define POWER_SAVING in the simple peripheral project so that the SimpleLink CC2652R1 device can enter standby mode while idling.  This is further covered in SWRA478.  You may consider creating a new E2E post if you have any follow-up questions about the TMP117 supply voltage.

    Regards,
    Ryan

  • Hi Ryan,

    good news from here, it was also useful the AppNote SWRA478. We were already setting the POWER_SAVING but the residual current consumption when the CPU is in standby may occurs because some dependancies of the USED PINs: this dependance is also managed by the sysconfig and it have to be properly done (when the peripherals are closed and obviously not used during the stand-by). Specifically for the TMP signals or every other used or connected pins have to be defined also as GPIO in the sysconfig section and then properly settled at the right level and pull-up/down mode, to avoid strange or intermediate polarizations due to possible leakage currents (they generally affects to any floating pin). An intermediate voltage on pins may cause an increase of the current consumption for a CMOS input buffer that it is always connected, internally to any pin. It is also captured by the EnergyTrace and displayed as a noise signal between 0 to 400uA. To avoid that we preferred to configure all unused pins as output to default level, then for the used PINs, we had to put some of them to low level and others to high level or defining them as open-drain, with pull-up. Till the obtaining of the expected result.

    attached  the I2C signals before and after a correct polarisation 

    Now we are ready to build a Proof of Concept of our application but the real issue is now CC2652R availability, or something equivalent.

    We bought a numbers of the chip's Launchpads, because we hope to be able to extract the chip safe and mount it in our prototype first series.

    We cant't delay now with our customer over a month but I'm really concerned for the next steps, we need to plan.

    Have you an idea ? 

    Thanks for all and have a nice day

  • I've asked Marketing to further comment on lead times, however this typically requires feedback from the TI Sales.

    Regards,
    Ryan