LDC1000 sensor values

[ndavis]

Hello,

I purchased the LDC1000 click board to use with the Micromod MikroBus development board and the STM32F405. I was able to get flash everything fine. I purchased the terminal click board and a UART serial basic board which I’m able to connect to the UART terminal no problem but I don’t get any results printed. Looking at the board there’s no Rx/Tx pin as it says “NC”. But the code I pulled from the example link as these pins defined. Do I need to connect to a different pin on the terminal click board?

What do I need to do to be able to print the results from this sensor?

[frank.malik]

Hello ndavis,

the LDC1000 click board only uses the SPI interface. The software ( library and example from Mikroe ) reads the values over the SPI bus and prints the information through the logger function.

Depending on how the logger is initialised, the output is via an on-board USB interface ( if your board has something like this ) or through a UART click board. The definition must be set accordingly.

The terminal click board is not used to connect a terminal ( old description of a display/keyboard device, nowadays a PC is used ). The terminal click only brings the mikroBUS pins to the pin header to connect an oscilloscope or similar to it, to check the bus signals.

Please post your code, if this description doesn't help you further.

[frank.malik]

Hello ndavis,

I think I got your point. The micromod board doesn't contain any UART connection. Instead the USB device inside of the STM32 is connected to the USB-C connector. However, Mikroe doesn't support these on-chip USB devices, as far as I know.

So you wanted to use the terminal click to connect an external UART-to-USB converter and connect your PC to this one, correct?
I think you can do this. You just need to check if the UART I/Os defined by the logger initialization are the same that you have used for your terminal click.

PA2/UART2_TX
PA3/UART2_RX

Is your setup like this: the terminal click is plugged into the mikroBUS socket of the micromod board, the LDC 1000 click is plugged into the terminal click,
you are not using any UART click board from Mikroe, but any kind of external USB-to-UART converter.
Another option, if this still doesn't work, is that the RX/TX lines are swapped.

[ndavis]

Ok, yes I tried seeing if there was a driver missing or something with the on board USB-C port but came up with nothing. So currently, there isn't a way to use the onboard USB-C to pull the data into the NECTO Studio and display.

I followed this guide in purchasing the items and setting up the hardware: https://learn.sparkfun.com/tutorials/mi ... e-assembly

This is my step up:
MicroMod MikroBUS - https://www.sparkfun.com/products/18710
Micromod STM32 Processor - https://www.sparkfun.com/products/17713
Mikroe Terminal Click - https://www.sparkfun.com/products/18961
Mikroe LDC1000 Click - https://www.sparkfun.com/products/18825
Sparkfun Serial Basic Board - https://www.sparkfun.com/products/15096

Whenever I used the serial basic board, I hooked it up accordingly to the link at the top to the Terminal Click. The Code is below, I haven't made any changes to it from when I downloaded it from the Packages section within Necto Studio. I did attempt to define these USB_UART_RX USB_UART_TX variables in the log.h file once but wasn't sure what pins to define it as so I might of done it incorrectly. So I reverted back to it original file and decided to troubleshoot using the weather example in the link. When I flashed the example in the link (weather click) I was able to get it to print to the UART terminal. I looked through the code it uses and never found where it defined the UART pins, they appeared to be identical to me.



~~~~~ Code - Main.c ~~~~
/*!
* \file
* \brief Ldc1000 Click example
*
* # Description
* This example showcases how to initialize and configure the logger and click modules and
* read and display proximity and impendance data.
*
* The demo application is composed of two sections :
*
* ## Application Init
* This function initializes and configures the logger and click modules. Configuration data
* is written to the: rp maximum/minimum, sensor frequency, LDC/Clock/Power registers.
*
* ## Application Task
* This function reads and displays proximity and impendance data every 10th of a second.
*
* \author MikroE Team
*
*/
// ------------------------------------------------------------------- INCLUDES

#include "board.h"
#include "log.h"
#include "ldc1000.h"

// ------------------------------------------------------------------ VARIABLES

static ldc1000_t ldc1000;
static log_t logger;

static uint16_t old_proximity;

// ------------------------------------------------------ APPLICATION FUNCTIONS

void application_init ( )
{
log_cfg_t log_cfg;
ldc1000_cfg_t cfg;

old_proximity = 0;

/**
* Logger initialization.
* Default baud rate: 115200
* Default log level: LOG_LEVEL_DEBUG
* @note If USB_UART_RX and USB_UART_TX
* are defined as HAL_PIN_NC, you will
* need to define them manually for log to work.
* See @b LOG_MAP_USB_UART macro definition for detailed explanation.
*/
LOG_MAP_USB_UART( log_cfg );
log_init( &logger, &log_cfg );
log_info( &logger, "---- Application Init ----" );

// Click initialization.

ldc1000_cfg_setup( &cfg );
LDC1000_MAP_MIKROBUS( cfg, MIKROBUS_1 );
ldc1000_init( &ldc1000, &cfg );
Delay_ms( 100 );
ldc1000_default_cfg( &ldc1000 );
Delay_ms( 100 );
}

void application_task ( )
{
uint16_t proximity;
float inductance;

proximity = ldc1000_get_proximity_data( &ldc1000 );
inductance = ldc1000_get_inductance_data( &ldc1000 );

if ( ( ( proximity - old_proximity ) > LDC1000_SENSITIVITY ) &&
( ( old_proximity - proximity ) > LDC1000_SENSITIVITY ) )
{
log_printf( &logger, " * Proximity: %d \r\n", proximity );

log_printf( &logger, " * Impendance: %f uH\r\n", inductance );

old_proximity = proximity;

log_printf( &logger, "--------------------\r\n" );
Delay_ms( 100 );
}
}

void main ( )
{
application_init( );

for ( ; ; )
{
application_task( );
}
}

// ------------------------------------------------------------------------ END


~~~~ Code: log.h ~~~~
/****************************************************************************
**
** Copyright (C) 2022 MikroElektronika d.o.o.
** Contact: https://www.mikroe.com/contact
**
** This file is part of the mikroSDK package
**
** Commercial License Usage
**
** Licensees holding valid commercial NECTO compilers AI licenses may use this
** file in accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The MikroElektronika Company.
** For licensing terms and conditions see
** https://www.mikroe.com/legal/software-license-agreement.
** For further information use the contact form at
** https://www.mikroe.com/contact.
**
**
** GNU Lesser General Public License Usage
**
** Alternatively, this file may be used for
** non-commercial projects under the terms of the GNU Lesser
** General Public License version 3 as published by the Free Software
** Foundation: https://www.gnu.org/licenses/lgpl-3.0.html.
**
** The above copyright notice and this permission notice shall be
** included in all copies or substantial portions of the Software.
**
** THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
** OF MERCHANTABILITY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
** TO THE WARRANTIES FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
** IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
** DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
** OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
** OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
**
****************************************************************************/

/*!
* \file log.h
*/
#ifndef _API_LOG_LOG_H_
#define _API_LOG_LOG_H_

#ifdef __cplusplus
extern "C"{
#endif

#include "generic_pointer.h"
#include "drv_uart.h"
#include <stdarg.h>

/*! \addtogroup apigroup
* @{
*/

/*! \addtogroup loggroup Logger Library
* @{
*/

/*!
* \brief Log level values
*/
typedef enum
{
LOG_LEVEL_DEBUG = 0x00,
LOG_LEVEL_INFO = 0x01,
LOG_LEVEL_WARNING = 0x02,
LOG_LEVEL_ERROR = 0x03,
LOG_LEVEL_FATAL = 0x04,
} log_level_t;

/*!
* \brief LOG context structure.
*/
typedef struct
{
uart_t uart;
log_level_t log_level;
} log_t;

/*!
* \brief LOG init configuration structure.
*/
typedef struct
{
hal_pin_name_t rx_pin;
hal_pin_name_t tx_pin;
uint32_t baud;
log_level_t level;
} log_cfg_t;

/*!
* \brief LOG MAP to the USB UART configuration
* NOTE If USB_UART_RX and USB_UART_TX are not defined
* (defined as HAL_PIN_NC) define them manually.
* Pins are defined as Pxy where:
* - `x` represents port name ( A, B, C ... )
* - `y` represents pin ( 1,2,3...15...31 )
* Example:
* #define USB_UART_RX PA14
* #define USB_UART_TX PC0
*/
#define LOG_MAP_USB_UART(cfg) \
cfg.rx_pin = USB_UART_RX; \
cfg.tx_pin = USB_UART_TX; \
cfg.baud = 115200; \
cfg.level = LOG_LEVEL_DEBUG;

/*!
* \brief LOG MAP to the MikroBUS configuration
*/
#define LOG_MAP_MIKROBUS(cfg, mikrobus) \
cfg.rx_pin = MIKROBUS(mikrobus, MIKROBUS_RX); \
cfg.tx_pin = MIKROBUS(mikrobus, MIKROBUS_TX); \
cfg.baud = 115200; \
cfg.level = LOG_LEVEL_DEBUG;

/**
* @brief Initializes LOG module.
*
* Initializes LOG driver. This function needs to be
* called before other driver functions.
*
* @param[in] log LOG context object.
* @param[in] cfg LOG configuration structure.
*/
void log_init ( log_t *log, log_cfg_t *cfg );

/**
* @brief Printf function.
*
* This function uses to be a print message on the UART.
*
* @param[in] log LOG context object.
* @param[in] *f pointer to the string
* @param[in] ... Other parameters
*/
void log_printf ( log_t *log, const code char * __generic_ptr f,... );

/**
* @brief Discards all characters from the output and input buffer.
*
* @param[in] log LOG context object.
*/
void log_clear ( log_t *log );

/**
* @brief Reads at most \p size bytes of data from the device into \p buffer.
*
* @param[in] log LOG context object.
* @param[out] rx_data_buf Array to place read data in.
* @param[in] max_len Maximal length
*
* @return err_t Returns the number of bytes that were actually read,
* or -1 if an error occurred or no data read.
*/
int8_t log_read ( log_t *log, uint8_t *rx_data_buf, uint8_t max_len );

/**
* @brief INFO printf function.
*
* This function uses to be a print message on the UART.
* This function uses the prefix [INFO] and check for log level
*
* @param[in] log LOG context object.
* @param[in] *f pointer to the string
* @param[in] ... Other parameters
*/
void log_info ( log_t *log, const code char * __generic_ptr f,... );

/**
* @brief ERROR printf function.
*
* This function uses to be a print message on the UART.
* This function uses the prefix [ERROR] and check for log level
*
* @param[in] log LOG context object.
* @param[in] *f pointer to the string
* @param[in] ... Other parameters
*/
void log_error ( log_t *log, const code char * __generic_ptr f,... );

/**
* @brief FATAL printf function.
*
* This function uses to be a print message on the UART.
* This function uses the prefix [FATAL] and check for log level
*
* @param[in] log LOG context object.
* @param[in] *f pointer to the string
* @param[in] ... Other parameters
*/
void log_fatal ( log_t *log, const code char * __generic_ptr f,... );

/**
* @brief DEBUG printf function.
*
* This function uses to be a print message on the UART.
* This function uses the prefix [DEBUG] and check for log level
*
* @param[in] log LOG context object.
* @param[in] *f pointer to the string
* @param[in] ... Other parameters
*/
void log_debug ( log_t *log, const code char * __generic_ptr f,... );

/**
* @brief WARNING printf function.
*
* This function uses to be a print message on the UART.
* This function uses the prefix [WARNING] and check for log level
*
* @param[in] log LOG context object.
* @param[in] *f pointer to the string
* @param[in] ... Other parameters
*/
void log_warning ( log_t *log, const code char * __generic_ptr f,... );

/**
* @brief Printf function with a variable prefix.
*
* This function uses to be a print message on the UART.
* This function uses a variable prefix.
*
* @param[in] log LOG context object.
* @param[in] prefix Prefix.
* @param[in] *f pointer to the string
* @param[in] ... Other parameters
*/
void log_log ( log_t *log, char * prefix, const code char * __generic_ptr f, ... );

/*! @} */ // loggroup
/*! @} */ // apigroup

#ifdef __cplusplus
}
#endif
#endif // _API_LOG_LOG_H_
// ------------------------------------------------------------------------- END

[ndavis]

Hello,

I put in the following code that is bolded into the log.h file from your previous post:

/*!
* \brief LOG MAP to the USB UART configuration
* NOTE If USB_UART_RX and USB_UART_TX are not defined
* (defined as HAL_PIN_NC) define them manually.
* Pins are defined as Pxy where:
* - `x` represents port name ( A, B, C ... )
* - `y` represents pin ( 1,2,3...15...31 )
* Example:
* #define USB_UART_RX PA14
* #define USB_UART_TX PC0
*/
#define USB_UART_RX PA3
#define USB_UART_TX PA2
#define LOG_MAP_USB_UART(cfg) \
cfg.rx_pin = USB_UART_RX; \
cfg.tx_pin = USB_UART_TX; \
cfg.baud = 115200; \
cfg.level = LOG_LEVEL_DEBUG;

It now does print to the UART terminal if I'm holding the board. The values being printed are bouncing from two extremes which I assume is the min and max values. If I place the board down it stops printing to the UART. It appears my hand is what is causing the signal to print not the LDC1000 as it only prints a value if my hands are around the RX/TX pins on the Terminal Click Board.


~~~~ UART TERMINAL ~~~

* Proximity: -1

* Impendance: 265877456.000000 uH

--------------------

* Proximity: 32639

* Impendance: 65949068.000000 uH

[filip]

Hi,

Can you please run the code through a debugger and see if the LDC1000 values are correct, before printing to UART ?

Regards,
Filip.

[frank.malik]

Hello,

I think the description from SParkfun is very helpful, but I can image that there is still some issues.

1. RX / TX
Typically, at one position you need to cross the RX / TX lines, to have the RXI of the CH340 ( on the serial basic board ) connected to the UART_TX/PA2 of the STM32. I don't see that this is the case.

Code: Select all

Serial Basic    Terminal Click      micromod    STM32 mod
+----------+    +------------+    +---------+   +--------------------+
|      RXI +----+ RX      RX +----+ RX  RX1 +---+ RX1   PA3/UART2_RX +
|          |    |            |    |         |   |                    |
|      TXO +----+ TX      TX +----+ TX  TX1 +---+ TX1   PA2/UART2_TX +
+----------+    +------------+    +---------+   +--------------------+

Easiest way might be to exchange the blue and the yellow jumper wire.

2. power supply.
I have my doubts if it is a good idea to connect the red wire from the serial basic to the 5V-pin of the terminal click.
This will go to the VIN signal on the micromod, which goes through a LDO to generate 3.3V on the micromod board. But the generated 3.3V from the serial basic might be too low
to provide the correct input voltage for the LDO.

To be on the safe side, I suggest removing this red wire, connect a second USB to the micromod board to have the power supplied from there. Alternatively, you may change the power
jumper on the serial basic from 3.3V to 5V. Keep the black cable for ground.

Of course, Filips's idea is also valid!

[ndavis]

Using the debug feature I was able to ensure what was being printed to the UART for the impedance value but the proximity is incorrect. I can get the value to jump between the two values I previously described by touching the SDO pin on the LDC1000, not the RX/TX like previously stated. When I am not touching the pin the UART outputs

--------------------

* Proximity: -1

* Inductance: 265877456.000000 uH

--------------------

And the values stored are Proximity = 65535 and Inductance = 2.658775E+008

If I touch the SDO pin, these values begin to jump between this and Proximity = 0 and Inductance = 2.938736E-023 with the UART outputting

--------------------

* Proximity: 0

* Impendance:0.000000 uH

--------------------

Putting a conductive material near the coil sensor does not change this value so it appears it is not reading anything. It just constantly outputs a Proximity = -1 and Inductance = 2.6e8 to the UART. Could the coil be defective?

Also switching the wires resulted in the signal not being read.

[frank.malik]

Hello,

if I understand it correctly, you have the UART communication now, as you can see the print out on the terminal window.
But the values are only two maximums.

It sounds to me like a all zero or all one issue. An this is related to bad contacts or bad soldering in most of the cases.

The proximity value directly reflects the content of the corresponding register of the LDC1000. For the inductance,
some additional calculations are involved. So, you can't see immediately the effect of an all zero or all one read.

Please check all the SPI connections, particular the one for the SDO signal.

[frank.malik]

Hello,

just a side comment. Proximity is a uint16_t value, means there is no negative proximity.

The value is not -1, but simply 65535 ( 0xffff ), as the maximum possible value.

[ndavis]

Yes I believe I have UART communication now.

The purpose of the click boards is to eliminate the need of soldering so if the connections are bad then this would be a manufacturing defect.

Looking at the boards, I do not see any issues with the solder. The pins are a secure connection between the boards and there is no movement between them. The only thing I could point out is the Terminal Board cannot fit fully flush on the MicoMod MikroBus connection. The board itself interferes with the back face but it does feel like a good connection.

There is a line on the coil sensor, potentially a scratch. I was going to attempt in creating another coil and splitting the onboard coil off to see if it will read it.

Any other potential fixes? If not, I'm going ask for this sensor to be replaced.

[frank.malik]

Hello ndavis,

thanks for the pictures. I agree, the soldering and connection looks fine.
Nevertheless, the system isn't working. I can't image that this is because of the scratch.

Did you try to measure the signal connection from source to destination?
The german word is "Durchgangsprüfer", the english translation I've found is "continuity tester".
Does this make sense? Typically each multimeter has this function.

[ndavis]

I've checked continuity at the INA and INB ports at the end of the sensor and it reads a resistance so the coiled sensor is not open.

I powered on the LDC1000 board and measured the pins at the solder joint on top to ground, the SDI and CS pins measure a resistance but the SDO pin does not. To me this means that this pin is not getting the signal from the LDC1000 chip and this board is defected, would you both agree?

[frank.malik]

Hmm,

not necessarily. The SDO pin on the IC is on the same side as the SDI and SCLK.

It still might be a bad soldering of the SDO pin on the mikroBUS connector.
The SDO signal has a very clear trace on the back side. Actually I like to suggest the following:

1. If possible, just solder the pins of the connector of the mikroBUS once more.
2. take some sand paper or sharp cutter and carefully remove the resin over the track of the SDO signal
and measure again.
3. you may try to measure the signal from the IC to the connector. The pin pitch is very small, but maybe
you have a small probe to do this.

Just to make sure: always make resistance measurements with an un-powered board.

[ndavis]

Thank you for your replies and help but this is supposed to be plug and play device that work straight out of the box. This board isn’t working for me so if it’s not a coding issue and the setup of the components are determined to be correct then I was sent a faulty board. Instead of trying to root cause this board I’m going to request a new board be sent to me. I’ll update when I get a new board and test