MSP430FR6989 LC + ESI Power Consumption Issues

Hi Eduardo,

I just want to confirm you are making reference to the following TI Design.

MSP430 Microcontroller Single Chip Inductive Proximity Sensing Reference Design

If this is correct. Would you mind providing more information regarding the hardware/setup you are using?

1.- Are you using a custom board based on the FR6989 Launchpad design or did you replace the LCD on the FR6989 Launchpad?

2.- When you are doing the power consumption test do you have the LED and LCD disabled? The firmware has a macro available in TIDM_INDUCTIVEPROX.h  (ENABLE_CURRENT_CONSUMPTION_MEASUREMENT) which allows you to reconfigure the application to perform power consumption measurements. Make sure that the macro is uncommented in the file.

3.- How are you powering the board? We recommend you follow the power consumption test setup in the TI design User's guide in section 6.2.

Regards,
Ivan

This is not the app note that i am following !

This is the correct one: http://www.ti.com/tool/TIDM-LC-WATERMTR

I did not change the launchpad lcd, i just modified the lcd library that came with the example firmware to work with the launchpad lcd. I made a board only for the LC circuit (based on the app note schematics/board files) then I just connected it to the launchpad and it worked just fine. The rotating disc that i am using is very similar with the one used in the design file. 

If you press the button (P1.2), the LCD is turned off. This is the mode for current measuring. I used a True RMS DMM and i got 15 uA. When the board is counting and LCD On I got around 80 uA. 

I attached the source codes that i am working with.

The design note says that the whole system, except LCD, works with 7 uA for a sample rate of 500 Hz. Maybe my DMM is giving me false readings?.

I cannot decrease the sample rate too much mainly because it will decrease significantly my flow measurement range.

If i achieve 7 uA, it would be acceptable for the moment.

launchpadESI_LC_e2e.zip

Hi Eduardo

Thank you for sharing your code. The difference in current consumption might be due to the fact that the LCD_init routine is initializing some segments which are not used by the LCD on the Launchpad.

On the FR6989 Launchpad you only need to initialize the following segments:4, 6-21, 27-31, 35-39.

Could you please try changing the following line in ldc.c

 LCDCPCTL0 = 0xFFFF;
 LCDCPCTL1 = 0xFC3F;
 LCDCPCTL2 = 0x0FFF;

to

 LCDCPCTL0 = 0xFFD0;
 LCDCPCTL1 = 0xF83F;
 LCDCPCTL2 = 0x00F8;

Regards,
Ivan

Still same readings. I also removed all lcd routines from the example code and nothing changed too.

I made some progress. I noticed that I left ESI COM unconnected. The current consumption now dropped to around 9.6 uA in current measurement mode (LCD OFF & ESI Off) and 22 uA when the application is running. Still trying to figure out what else is happening . Any suggestion ?

Hi Eduardo,

I took another look at your code and noticed that the recalibration of the ESI module using AFE2 is enable in ScanIF.h and it is configure to run every 2 sec which might be contributing to the average current consumption.

Have you tried disabling the recalibration routine while doing the current consumption test?

In real applications this recalibration needs to be run less often 1-2 times a day sometime even less depending on the application.

Regards,
Ivan

Yes, I tried that too, the current consumption didnt change.

I will make a board using another msp430 with ESI interface with the minimal necessary hardware for my application so i can be sure that is not a problem with the launchpad.

I think the msp430fr5887 would be the best one for this particular case due to the fact i wont use a LCD and 64 pins enough ( 32 pins would be better, but i didnt find one msp430 with ESI and this pin count). Am I correct?

Thanks !

Hi Eduardo,

You are correct, the minimum pin count for devices the with ESI module is 64.

The following devices are also 64 pin devices with ESI module and no LCD module

Regards,
Ivan

I noticed that the runtime calibration isnt perfoming correctly. The AFE2_drift is always high, so it is considered invalid since a small drift is expected, so the runtime calibration nevers occurs and the drift due to the temperature change is never compensated.

I believe this is the main reason for the temperature problem that i am dealing with.

Do you have any additional suggestion? I already tested with different sample rates, values of C (220, 470 and 940 pf) and separation factors, and I cant find a effective solution.