sensor probing failed

[Anzal3c3]

HI i am using stm32l4XX microcontroller to read the data from the sensor. It outputs sensor probing failed what could it possibly mean. Is it because of anything wrong with the data being sent or being received?

{7E}{00}{7D}{31}{43}{00}{AB}{7E}{7E}{00}{7D}{31}{43}{00}{AB}{7E} this one is the mosi out that i get from the sensor when is send wakeup instruction

[Anzal3c3]

{98}{FF}{09}{20}{36}{02}{00}{00}{7E}{00}{00}{02} this is the response i am getting from the sensor when its connected to the mcu when i send start measurement command . when i send the command the fan is turning on but the response is different than in the data sheet

[Anzal3c3]

/*

• Copyright (c) 2018, Sensirion AG
• All rights reserved.
• Redistribution and use in source and binary forms, with or without
• modification, are permitted provided that the following conditions are met:
• • Redistributions of source code must retain the above copyright notice, this
• list of conditions and the following disclaimer.
• • Redistributions in binary form must reproduce the above copyright notice,
• this list of conditions and the following disclaimer in the documentation
• and/or other materials provided with the distribution.
• • Neither the name of Sensirion AG nor the names of its
• contributors may be used to endorse or promote products derived from
• this software without specific prior written permission.
• THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
• AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
• IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
• ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
• LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
• CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
• SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
• INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
• CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
• ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
• POSSIBILITY OF SUCH DAMAGE. */

include "../SPS30_DRIVER/sensirion_arch_config.h"

include "../SPS30_DRIVER/sensirion_uart.h"

include "stm32l4xx_hal.h"

include "stdio.h"

int i=0; /*

• INSTRUCTIONS
• ============
• Implement all functions where they are marked with TODO: implement
• Follow the function specification in the comments. */

/**

• sensirion_uart_select_port() - select the UART port index to use
• THE IMPLEMENTATION IS OPTIONAL ON SINGLE-PORT
• SETUPS (only one SPS30)
• Return: 0 on success, an error code otherwise */ extern UART_HandleTypeDef huart5; extern UART_HandleTypeDef huart2; extern TIM_HandleTypeDef htim2;

uint8_t datas[100];

int16_t sensirion_uart_select_port(uint8_t port) { return 0; }

/**

• sensirion_uart_open() - initialize UART
• Return: 0 on success, an error code otherwise */ int16_t sensirion_uart_open() { return 0; }

/**

• sensirion_uart_close() - release UART resources
• Return: 0 on success, an error code otherwise */ int16_t sensirion_uart_close() { // TODO: implement return HAL_UARTEx_EnableStopMode(&huart5); }

/**

• sensirion_uart_tx() - transmit data over UART
• @data_len: number of bytes to send
• @data: data to send

• Return: Number of bytes sent or a negative error code / int16_t sensirion_uart_tx(uint16_t data_len, const uint8_t data) { // TODO: implement

  HAL_UART_Transmit_DMA(&huart5,(uint8_t*) data, data_len);

  //HAL_UART_Transmit(&huart2,(uint8_t*) data, data_len, 100);

  return data_len; }

/**

• sensirion_uart_rx() - receive data over UART
• @data_len: max number of bytes to receive
• @data: Memory where received data is stored

• Return: Number of bytes received or a negative error code / int16_t sensirion_uart_rx(uint16_t max_data_len, uint8_t data) { // TODO: implement

  int32_t bytes_received = 0; //HAL_UART_Receive_IT(&huart5,(uint8_t*) data, max_data_len);

  HAL_StatusTypeDef status = HAL_UART_Receive_IT(&huart5,(uint8_t*) data, max_data_len);
  if (status == HAL_OK) {
      bytes_received = max_data_len - huart5.RxXferCount;
  }
  return bytes_received;

}

/**

• Sleep for a given number of microseconds. The function should delay the
• execution for at least the given time, but may also sleep longer.
• Despite the unit, a <10 millisecond precision is sufficient.

• @param useconds the sleep time in microseconds */ void sensirion_sleep_usec(uint32_t us) {

  // TODO: implement HAL_Delay(us); }

[psachs]

Hi @Anzal3c3

For STM we currently don't have a UART sample implementation or a working setup. I therefore try to explain how the protocol works so you better understand the results you get.

The UART interface implements a Sensirion protocol (SHDLC) on top of uart which introduces frames for a more reliable communication.

Please note that UART will not necessary read all the data at once. This depends on the implementation of the underlying library.

A very simplified explanation of the protocol: Each frame has at most 255 bytes of data and is encapsulated in the start/stop byte (0x7E)

to avoid conflicts, there are the following byte stuffings

0x7E => 0x7D, 0x5E
0x7D => 0x7D, 0x5D
0x11 => 0x7D, 0x31
0x13 => 0x7D, 0x33

A message (MOSI) has the following parts

Address (1 byte) | Command (1 byte) | Lengh (1 byte) | Data (Lenght bytes) | Checksum (1 byte)

The response (MISO)

Address (1 byte) | Command (1 byte) | State (1byte) | Lengh (1 byte) | Data (Lenght bytes) | Checksum (1 byte)

You should also be able to find this information in the SPS30 datasheet.

If the answer you receive from the module is not starting with 0x7E and stopping with 0x7E you most probably have not read all the data.

Your examples first example with the wake-up

Note Wake-up command is 0x11 (which is encoded to 0x7D 0x31

The sensor answers with (It looks like you duplicated the same message, or read it twice): {7E}{00}{7D}{31}{43}{00}{AB}{7E}

which is

frame start =>  0x7E
Address => 0x00
Wake_up => 0x7D 0x31 => 0x11
State => 0x43
Length => 0x00
Checksum => 0xAB
frame end => 0x7E

so for the wake-up command the response makes sense. Btw. the state 0x43 means "Command not allowed in current state" because the sensor is already awake. This error you can ignore.

Your examples first example start measurement

Since the fan turns on, it looks like the transmission of the start command was successful. The answer you get however doesn't look complete.

{98}{FF}{09}{20}{36}{02}{00}{00}{7E}{00}{00}{02}

The MOSI data sent to the sensor should look as follows

frame start => 0x7E
Address => 0x00
Start measurement => 0x00
length => 0x2  (2 sub-command values are sent: 0x01 and 0x03)
data0 => 0x1
data1 => 0x3
Checksum => 0xF9
frame end => 0x7E

The expected answer is an empty frame, that looks as follows

frame start =>  0x7E
Address => 0x00
Start measurement => 0x00
State => 0x00
Length => 0x00
Checksum => 0xFF
frame end => 0x7E

The data you read, looks like it contains the MOSI frame at the end. So something is wrong there. I suspect, the problem is that after each send and read you need to flush the UART buffer to make sure you get the recent data. Also make sure that you read all the data from the buffer within a certain timeout if you still receive incomplete messages.

Let me know if my answer was helpful

[Anzal3c3]

@psachs hey thanks for reaching out. it worked for me