MSP430FR2676: How to terminate the function CAPT_calibrateSensorWithEMC()

Hi DDdoor,

Does the customer have any sensors connected to the MSP430? If they are attempting to run the calibration without any sensors, the calibration process will not be able to achieve the target sensitivities.  If this is the case then the calibration is meaningless and they could skip the calibration, but that will cause trouble if they attempt to take measurements.  Can you provide any more details?

Hello Dennis Lehman,

Thank you for your support.

When calibration is performed without a sensor connected, the calibration process takes a long time.
Although the intended use is with the sensor connected, they also consider the possibility of sensor disconnection.

As a countermeasure for the long calibration time, they are considering using a periodic timer interrupt, and within this interrupt handling the communication process with the host.

However, on the MSP430FR2676 there is no ICC block, so interrupt priority settings are not available.
Additionally, since the UART receive buffer is only one stage deep, they are facing issues where they need to carefully consider the host communication processing time and the timing of UART receive interrupts from the host.
This is causing some interference with reliable communication.

Do you have any suggestions for how to address this issue?

Best regards,
DDdoor

Hi DDdoor,

Ok - now I understand.  The reason the calibration is taking so long is the algorithm is attempting to determine a suitable setting in the IP that will provide the sensitivity (target conversion count) based on what the customer had selected when a sensor is connected.

For example, let's say the customer has a 10pF sensor and sets the target conversion count = 250.  During the calibration, the algorithm goes through a loop where it configures the Captivate IP with an starting sensitivity value, takes a measurement, then compares the result to 250. If the measurement count is not = 250, the algorithm either increases or decreases the sensitivity 'K', as needed, and repeats the measurement.  At some point with the proper selection of 'K'  measurement count will = 250 and the algorithm will exit the loop, store the calibration setting 'K' in the sensor's data structure and it is done.  Keep in mind the 250 does not represent the number of times the loop was executed.  The 250 is the number of charge-transfers required with a sensitivity of 'K' to fill the large sampling capacitor.

In finer detail, what is happening during each measurement is the sensor is charged up to 1.5v and this small charge (Q = CV) is transferred inside Captivate where 'K' is applied to the charge before transferring to the larger sampling capacitor.  This charge-transfer process is repeated over and over until the large sampling capacitor reaches a specific voltage threshold.  The measurement count = the number of charge-transfers it takes to reach the threshold, given the present value of 'K'. (see Captivate Tech Guide for details)

So now what happens when the sensor is disconnected and the algorithm attempts to calibrate, the capacitance is not 10pF, most likely something much smaller, say 1 or 2pF.  Because the capacitance is so much smaller, the algorithm will struggle to find a setting of 'K' that can achieve 250 counts and remain in the loop for a long time.  Eventually the calibration error bit is set and can be detected by the ISR.

DDdoor said:

Is there any way to terminate the CAPT_calibrateSensorWithEMC() function under these circumstances?

This is great question.  To be honest, I don't know so I will need to take a look.

Also, the .bMaxCountError should only be set during a 'normal' measurement, not during calibration.  This happens if while the system is running with a connected calibrated sensor becomes disconnected, so capacitance is suddenly very small, the next measurement will not be ~250 but rather become very large value and take long time.  It can be as large as 8191 and appears as though measurement is "stuck". To limit this from happening the customer might try is setting the sensor's .ui16ErrorThreshold = 2x or 4x the target conversion count setting.  So if their conversion count is 250, set max_count to 500 or maybe 1000. This will automatically stop the measurement early and not wait until 8191 and set the bMaxCountError bit.

===============================

So back to the original issue of not having a sensor installed.

Is this scenario only while customer is doing their SW/HW development and will not be the case with eventual product?  If so, it is possible to temporarily modify CAPT_UserConfig to skip a particular sensor, or certain buttons when real sensor not available.  This way calibration not affected and only real sensors get calibrations.

Hello Dennis Lehman ,

The customer's operational scenario includes both cases where the sensor is not connected initially and where it becomes disconnected during operation.

Best regards,
DDdoor

Hi DDdoor,

Ok, this is helpful to know.

So I assume then if the sensor is disconnected, either at startup (where calibration is performed) or later during usage (either by accident or as part of the normal use of the product) the SW is designed to detect the state of the sensor and 1) continue to be operate with sensor disconnected, or 2) prevent the product from operating until sensor is connected?  Can you share why type of product this is or maybe a use case?

Hello Dennis Lehman,

Regarding your question, the customer's software is designed to continue to operate with the sensor disconnected.

Best regards,
DDdoor

Hi DDdoor,

Ok.  I responded to your private message.

So this tells me if one or more sensors become disconnected during normal operation, the system is designed to continue to operate despite the sensor no longer functioning.  I can see now when this happens Captivate will sense the missing sensor, probably get a MAX_COUNT error which will then put it into the calibration mode, and this is where the customer is having the issues.

The Captivate code (framework) is not designed to handle this scenario by default and will require modifications to the code to support handling this error.  I assume this is what the customer is working on, correct? I will need to think about best method to handle this.

So really all the customer needs is a way to detect if/when the sensor is disconnected and prevent the SW from getting stuck in calibration loop, correct?