STS30 temperature sensor I2C code

Hello,

Please make sure to check the error code returned by nrf_drv_twi_rx - if you do not check the error code you will not have any way of knowing if the function call unexpectedly failed, and so you will be stuck in the while loop forever waiting for the transfer to complete, without the transfer ever having started.

Please also make sure to have DEBUG defined in your preprocessor defines, like shown in the included image:

This will make your logger output a detailed error message whenever a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK.
Use this error message to find the function that returned the error code, and look at the function's API reference to see why it returned this particular error code.

Best regards,
Karl

I thought the address of this sensor was 0b0011xxxr where xxx is the state of the external pins A2/A1/A0. Try this (assuming all 3 address pins are tied low):

    uint8_t STS30_Address = 0x18; // address of the sensor

Kaveh.M said:

Yes I am working with a custom board, and an external JLink debugger.

Thank you for confirming.

Kaveh.M said:

I set NRF_LOG_BACKEND_RTT_ENABLED to 1 in sdk_config.h file. A new window called "Debug Terminal" is opened now. And after the debugger transition to line 100 in app_error_weak.c and stuck there this message appears.

<info> app: Successfully detected STS30 at address: 0x4A
<error> app: ERROR 17 [NRF_ERROR_BUSY] at C:\nRF5_SDK_17.0.2_d674dde\examples\My Projects\twi_SHT30_Read_1\main.c:121
PC at: 0x00005CC5
<error> app: End of error report

Great! So now we know that the APP_ERROR_CHECK on line 121 of main.c was triggered with the NRF_ERROR_BUSY error code. Now, you can check which function returned this error code, and check the API Reference of the function to see why it would return this error code, and what you must do to resolve it.
Please try this, and let me know if you run into any other issues or questions.

Best regards,
Karl

Well, it seems like this error is coming from line 121 nrf_drv_twi_tx() function and NRF_ERROR_BUSY means "the driver is not ready for a new transfer". But I dont understand why the driver should not be ready or is busy transferring data. 

I have tried and captured I2C signals using logic analyzer. As you can see in the images below, STS30 is detected, command is sent to STS30 and data is read from STS30 properly in the first round of the while loop. But in the second round during STS30_detect() function execution, nrf_drv_twi_rx() is sending the address and the sensor seems to hold the SCL and SDA lines and that is probably why I get NRF_ERROR_BUSY. But I dont know why the sensor is not responsive in the second round of while loop.

Hello Kaveh.M,

Kaveh.M said:

Well, it seems like this error is coming from line 121 nrf_drv_twi_tx() function and NRF_ERROR_BUSY means "the driver is not ready for a new transfer". But I dont understand why the driver should not be ready or is busy transferring data. 

There could be multiple reasons for this - either that the calls to nrf_drv_twi_tx is happening in a loop / back-to-back so that the peripheral does not get sufficient time to clock out the transfer before the next one is queued, or because the slave needs more time to process the received transfer before it can accept / acknowledge another one.

Judging by your most recent comment, the latter of my suggestion seems to be the case.
Have you checked the datasheet of the slave, to see if it requires a certain delay between transfers? Many sensors have this as part of their specification. 

Best regards,
Karl

I could not find any timing constraint that cause this. Since it works fine in the first while loop and not the second one, I guess I am putting the sensor in a bad state in the second transition. So I disable/enable the sensor power supply everytime before I initiate STS30_detect() and execute a measurement. And that resolved the issue. 

I could not find any timing constraint that cause this. Since it works fine in the first while loop and not the second one, I guess I am putting the sensor in a bad state in the second transition. So I disable/enable the sensor power supply everytime before I initiate STS30_detect() and execute a measurement. And that resolved the issue.