MSP430FR2633: Interpreting sensor/cycle packets.

Hello Santhosh,

Thank you for your detailed reply. It is very informative into what you're observing and what your system looks like.

I suspect that you've programmed the MSP430FR2633 with the demo code. Thus, the communication that you're observing is the protocol used between the device and the CapTIvate Design Center GUI on a PC. While all these packets do contain valuable information, it's like drinking from a fire hose unnecessarily. The Design Center GUI requires this much data, but in your application, your host processor only need information like "this button turned on", "motion was detected", etc.

Thus, I'd recommend taking a look at the Software Library portion of the CapTIvate Technology Guide. For example, there's a starter application discussed called 'main.c'. Basically, this code would run on the MSP430FR2633 and would turn on LED2 when motion is detected by a sensor. For something like your application, you'd have to add code that would send a message over I2C to the host processor based on some type of input (motion, button press, etc.). Simple call-back functions are associated with each sensor.

void my_button_callback(tSensor* pSensor)
{
    if((pSensor->bSensorTouch == true) && (pSensor->bSensorPrevTouch == false))
    {
        // BUTTON PRESSED
        // DO SOMETHING ...
    }
    else if((pSensor->bSensorTouch == false) && (pSensor->bSensorPrevTouch == true))
    {
        // BUTTON RELEASED
        // DO SOMETHING ...
    }
}

Does this make sense?

If you need to implement something more advanced and are required to use the CapTIvate protocol, we can continue our discussion and dig deeper. Use cases for the protocol (copied from the "Software Library" -> "Communications Module" -> "Protocol Layer" section in the CapTIvate Technology Guide) include the following:

1. Capacitive Touch Development and Tuning Capacitive touch development and tuning involves looking at real-time data from a touch panel and adjusting software parameters to achieve the desired response and feel from the sensors on that panel. For example: tuning a capacitive button involves looking at the raw data coming back from the microcontroller about that button, and adjusting thresholds, de-bounce, and filters accordingly to create a robust user interface. Having the ability to adjust all of these software parameters in real-time while looking at sensor data, without re-compiling code, is extremely powerful and reduces development time. The Captivate protocol was designed with the Captivate Design Center specifically to meet this need.
2. Interface to Host Processor Most capacitive touch user interfaces involve a dedicated microcontroller driving the touch panel, which communicates up to a host processor of some kind. The flexibility of the Captivate protocol allows for it to be re-used as an interface to a host processor; it can stream touch status, proximity status, and slider/wheel position up to a host.
3. In-Field / In-System Debug Interface and Tuning Since the Captivate protocol supports reading and writing of capacitive touch tuning parameters, as well as the streaming of real-time data, it could potentially be utilized as a diagnostic tool in the field when coupled with the Captivate Design Center PC tool.

Regards,

James

MSP Customer Applications

Hello Santhosh,

Option 1) At a high level, you don't really need to use the same protocol that's used by the CapTIvate Design Center. You can implement a simple protocol based on the I2C interface between the host and the MSP430FR2633 (slave). Based on the number of sensors and required measurements/data/results, you can come up with a set number of commands. Then, when the host processor sends the MSP430FR2633 (slave) that command, the slave will then send the appropriate number of bytes based on the received command. You can utilize the call-back functions to obtain the sensor data, but you'd have to implement the I2C protocol on the MSP430FR2633.

Option 2) An alternative option that may be more challenging up front but then easier to use would be to utilize the I2C driver used with the CapTIvate Design Center. This way, you can take advantage of using the parameter packets that are described in the Design Guide. Let me try to walk you through this.

These steps assume that you already have a CapTIvate Design Center project for your design, and that the sensors in your design have been tuned. Basically, you'll want to set up your CapTIvate project for REGISTER I2C, which will allow you to read packets from your host processor. Since you're using the MSP430FR2633 and the CAPTIVATE-BSWP panel, we'll use that as the slave.

Setting up the target (slave) MCU

Step 1

To enable REGISTER I2C communication, open the CapTIvate Design Center Controller Customizer (double-click the MSP430 icon on the canvas). Then, select "REGISTERI2C" as the communication interface.

Step 2

You'll need to update your source code now to include this change by selecting "Generate Source Code" in the Controller Customizer window. Next, browse to your CCS project root directory.

Step 3

Basically, this change has modified one of the header files, so re-build your CCS project containing the update.

Step 4

Re-program the CapTIvate target MCU, the MSP430FR2633, with the updated project. Finally, terminate any debug sessions. That's it. The CapTIvate Software Library will take care of everything else.

Making I2C Connections

You've already connected the host processor to the target MCU and have the proper I2C pull-ups.

Starting REGISTERI2C Communication

For this example, let's assume that the MSP43FR2311 acts as the host processor. It can be programmed with MSP Driver Library software and the I2C Master driver used in CapTIvate examples for controlling the DRV26xx haptic actuators. A basic loop may be constructed as shown below to read data from the CapTIvate target device, the MSP430FR2633.

The I2C master driver calls shown here should be easy to translate to whichever host driver is being used in an end application. The I2CTOOLS utility on an embedded Linux host may be used in a similar fashion to perform writes to and reads from the I2C bus.

In this basic example, the sensor packet for sensor 0x00 was read. The first bit of the 6th (final) byte of the received data is used to turn on and of P1.0 on the MSP-EXP430FR2311 LaunchPad, which controls an LED. That bit in the received data corresponds to the global touch flag for the sensor with ID 0x00. This means that any touch on sensor 0 will cause the LED to illuminate. Sensor ID 0x00 corresponds to the button group sensor when using the CAPTIVATE-BSWP demo.

void loop(void)
{
     static uint8_t tx[16];
     static uint8_t rx[16];
     if (capture==true)
     {
          capture = false;

          tx[0] = 0x00;
          tx[1] = 0x00;
          I2CMaster_writeBuffer(0x0A, &tx[0], 2);
          I2CMaster_readBuffer(0x0A, &rx[0], 6);

          if (rx[5] & BIT0)
          {
               P1OUT |= BIT0;
          }
          else
          {
               P1OUT &= ~BIT0;
          }
     }
}

We're currently working on some collateral that will describe how to do this and other things, but unfortunately they haven't been released yet. Hopefully this helps, but please let me know if you aren't able to get the packet data by following these guidelines.

Regards,

James

MSP Customer Applications