MSP430FR2676: Software questions

Koichiro Tashiro

Part Number: MSP430FR2676
Other Parts Discussed in Thread: CAPTIVATE-BSWP

Hi,

My customer is evaluating CapTIvate software based on FR2676_CAPTIVATE-BSWP demo.
Here are some question from the customer.

Q1) At line#172 in CAPT_BSP.c file, there are below codes.
CS_clearAllOscFlagsWithTimeout(1000);

    //
    // Tune the DCO parameters
    //
    CS_initFLL((MCLK_FREQ/1000), FLL_RATIO);
    CS_clearAllOscFlagsWithTimeout(1000);

What is the reason you select '1000' as timeout value?
The customer changed it to '1' instead of '1000'. Is this a problem?

Q2) The customer measured while(1) background loop period in main.c.
(GPIO is toggled at the start and the end of the loop.)
Then they noticed the while loop took longer time when the counter value is 8191.
What is the reason the loop gets longer with 8191 count?

Q3) The customer changed main() and added CAPT_writeGeneralPurposeData(&BTN00_E00.pRawCount[0], 15); in while loop.

void main(void)
{
                          WDTCTL = WDTPW | WDTHOLD;
             BSP_configureMCU();
             __bis_SR_register(GIE);
 
                          CAPT_appStart();
 
                          while(1)
             {
                          CAPT_appHandler();
                          CAPT_writeGeneralPurposeData(&BTN00_E00.pRawCount[0], 15);
 
                          __no_operation();
 
                          CAPT_appSleep();
                          
             } // End background loop
}

The customer expects CAPT_writeGeneralPurposeData() outputs &BTN00_E00.pRawCount which is stored in CAPT_appHander().
But the count CAPT_writeGeneralPurposeData() outputs is different than CAPT_writeElementData().
Are they different?

Q4)
CAPT_writeGeneralPurposeData outputs cvs data like below.

TimeStamp(ms)  v0         v1         v2         v3         v4         v5         v6             v7         v8         v9
32         1124      1087     1105     1083      1099     1113     1101      1105             1091      1115
32         1127      1088     1106     1080      1103     1116     1101      1102             1096      1116
32         1124      1089     1105     1093      1098     1114     1100      1106             1095      1113
32         1135      1088     1108     1086      1109     1120     1097      1102             1103      1114
32         1130      1085     1099     1084      1107     1117     1089      1102             1103      1115
47         1131      1084     1103     1079      1107     1111     1095      1102             1102      1110
47         1129      1093     1105     1083      1101     1119     1100      1104             1095      1120
64         1130      1080     1098     1093      1113     1115     1100      1106             1100      1111
79         1128      1088     1098     1090      1106     1113     1096      1105             1097      1108
79         1131      1089     1102     1088      1109     1110     1099      1105             1092      1110
95         1131      1082     1096     1089      1111     1117     1099      1103             1094      1109

What does TimeStamp(ms) exactly mean?
- The time when the target values are updated?
- The time when the target values are accessed?
- The time when the target values are output?
- or else?

Thanks and regards,
Koichiro Tashiro

3 months ago

0 Dennis Lehman 3 months ago

TI__Guru 61941 points

Hi Koichiro,

Q1 - Regarding the '1000', this is used as a delay in the clock configuration to allow some time for the XT1 to start up. This function is part of the MSP430 Driverlib. Customer can download if interested to see. I copied function here for convenience. Nothing magic about 1000. I suspect the Driverlib developer probably picked a value large enough to allow a 32KHz crystal on XT1 sufficient time to start up. If customer is using XT1 with 32kHz crystal, they might want to consider leaving it as 1000. The issue might be their 32kHz crystal is not ready when CPU exits this function.

The code the customer is referring to appears to be an old version used in the CAPT_BSP.c file.

The newer version looks like this below. What version of Captivate Library are they using? This information is in the CAPT_UserConfig.h file and looks something like this:
//! \version 1.83.00.05

	//
	// Attempt to start the low frequency crystal oscillator
	//
	CS_setExternalClockSource(XT1_OSC_FREQ);
	if (CS_turnOnXT1LFWithTimeout(CS_XT1_DRIVE_0, XT1_OSC_TIMEOUT) == STATUS_FAIL)
	{
		//
		// If a crystal is not present or is failing, switch the LF
		// clock definition to the internal 32kHz reference oscillator.
		//
		ui8LFOsc = CS_REFOCLK_SELECT;
	}

Q2 - This indicates the captivate peripheral has performed 8191 (maximum allowed) charge-transfer cycles. It takes a long time to measure 8191 counts so that is why customer sees long time. This usually indicates something is wrong with the calibration or sensor. Since it appears they are using the BSWP, the calibration should be ok.

What target conversion count is the customer using? Do they have .ui16ConversionCount = 250?

Q3 - The two functions are different. Both are designed to send data to the GUI to display. CAPT_writeElementData transmits all of the data for each element in a sensor to the GUI. CAPT_writeGeneralPurposeData allows custom data to be sent to the GUI.

Is the customer trying to send data to the GUI or output on PC using terminal application?

Q4- The time stamp is when the GUI received the data. To be honest, I don't know any customer that uses the information, so I don't believe it is very useful.

0 Koichiro Tashiro 3 months ago in reply to Dennis Lehman

TI__Mastermind 21510 points

Hi Dennis,

Thanks for your quick reply!
Q1) Understood.

Q2) The customer uses their custom sensors, so that is why it takes longer time.
They want to terminate the measurement if the time gets too long. Do you have any idea?

Q3) They want &BTN00_E00.pRawCount value.
Values returned from CAPT_getCyclePacket(); in CAPT_writeElementData(); are "element touch/prox state", "current count", and "current LTA".
Is "current count" different from the value stored in &BTN00_E00.pRawCount?

Q4) The customer wants the timestamp when the target values are updated.
Is there any method to output that timestamp?

Thanks and regards,
Koichiro Tashiro

0 Dennis Lehman 3 months ago in reply to Koichiro Tashiro

TI__Guru 61941 points

Hi Koichiro,

Koichiro Tashiro said:
Q2) The customer uses their custom sensors, so that is why it takes longer time.
They want to terminate the measurement if the time gets too long. Do you have any idea?

Yes, have the customer set the .ui16ErrorThreshold in the sensor struct located in CAPT_UserConfig.c file. The default is 8191. In practice, I would set this ~2000 or even less. If they are setting the .ui16ConversionCount to something around 500 or less, then they can reduce ui16ErrorThreshold to 1000.

Koichiro Tashiro said:
Q3) They want &BTN00_E00.pRawCount value.
Values returned from CAPT_getCyclePacket(); in CAPT_writeElementData(); are "element touch/prox state", "current count", and "current LTA".
Is "current count" different from the value stored in &BTN00_E00.pRawCount?

Yes, the current count is the rawCount that has been filtered with beta = 1, and current LTA is the rawCount filtered with beta = 7. Unless they need the rawCount, I would recommend they use the currentCount, as the filtering removes some noise.

Koichiro Tashiro said:
Q4) The customer wants the timestamp when the target values are updated.
Is there any method to output that timestamp?

In this case I would suggest using the MSP430 to keep track of time, not the GUI. The GUI's timestamp has latency (because of Java and OS) and not accurate as to when the actual measurement was made. The customer can use the fact that the captivate measurements occur at regular intervals, 20ms or 33ms or whatever they have set in thie g_uiApp.ui16ActiveModeScanPeriod and they could use this for time stamping.

I'm curious why customer is using time-stamp? I don't know of any other customer who uses this for HMI applications. Can you say what the customer is working on?

0 Koichiro Tashiro 3 months ago in reply to Dennis Lehman

TI__Mastermind 21510 points

Hi Dennis,

Sorry for my late reply.
Q2) The customer confirmed it worked.
Q3) They are still checking it.
Q4) They are trying to output timestamp via SPI by mimicking CAPT_writeGeneralPurposeData, but it does not work well.
Could you tell me how to output timestamp by SPI?

Thanks and regards,
Koichiro Tashiro

0 Dennis Lehman 3 months ago in reply to Koichiro Tashiro

TI__Guru 61941 points

Hello Koichiro -

I do apologize the delay. CAPT_writeGeneralPurposeData sends user defined data (declared something like uint16_t data[8]) to the GUI for the purpose of displaying these values in the UserDataLog window. This data can only be sent via UART or I2C through the debugger over USB.

There is no way to send data to the PC using SPI.

Have the customer select UART or I2C in the GUI and set the corresponding settings in CAPT_UserConfig.h

Example:

if using UART

#define CAPT_INTERFACE (__CAPT_UART_INTERFACE__)

if using I2C

#define CAPT_INTERFACE (__CAPT_BULKI2C_INTERFACE__)

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430FR2676: Software questions