TWI Error 33281

I have a nRF52832 DK unit which I have developed against to get a HDC1080 reporting the temperature - everything works fine in the development setup.

I have recently had some devices manufactured using a nRF52810 and the device is giving an error 33281. I have read from previous posts that this is the slave nacking - which suggests that nothing can be found attached.

I stripped it back to basics and used the twi_scanner and it also reports no devices attached. I have tried with various `TWIS_DEFAULT_CONFIG_SCL_PULL`/`TWIS_DEFAULT_CONFIG_SDA_PULL`/`NRFX_TWIS_DEFAULT_CONFIG_SCL_PULL`/`NRFX_TWIS_DEFAULT_CONFIG_SDA_PULL` settings and nothing gets it working.

Relevant config:

  • TWI_INSTANCE_ID 0
  • TWI_ENABLED 1
  • TWI0_ENABLED 1
  • TWI0_USE_EASY_DMA 1

And the main file (which is basically the example mentioned above):

/**
 * Copyright (c) 2016 - 2021, Nordic Semiconductor ASA
 *
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, 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.
 *
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 *
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 *
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 *
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA 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.
 *
 */
/** @file
 * @defgroup tw_scanner main.c
 * @{
 * @ingroup nrf_twi_example
 * @brief TWI Sensor Example main file.
 *
 * This file contains the source code for a sample application using TWI.
 *
 */

#include <stdio.h>
#include "boards.h"
#include "app_util_platform.h"
#include "app_error.h"
#include "nrf_drv_twi.h"



#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"

/* TWI instance ID. */
#if TWI0_ENABLED
#define TWI_INSTANCE_ID     0
#elif TWI1_ENABLED
#define TWI_INSTANCE_ID     1
#endif

 /* Number of possible TWI addresses. */
 #define TWI_ADDRESSES      127

/* TWI instance. */
static const nrf_drv_twi_t m_twi = NRF_DRV_TWI_INSTANCE(TWI_INSTANCE_ID);


/**
 * @brief TWI initialization.
 */
void twi_init (void)
{
    ret_code_t err_code;

    const nrf_drv_twi_config_t twi_config = {
       .scl                = 27,
       .sda                = 26,
       .frequency          = NRF_DRV_TWI_FREQ_100K,
       .interrupt_priority = APP_IRQ_PRIORITY_HIGH,
       .clear_bus_init     = false
    };

    err_code = nrf_drv_twi_init(&m_twi, &twi_config, NULL, NULL);
    APP_ERROR_CHECK(err_code);

    nrf_drv_twi_enable(&m_twi);
}


/**
 * @brief Function for main application entry.
 */
int main(void)
{
    ret_code_t err_code;
    uint8_t address;
    uint8_t sample_data;
    bool detected_device = false;

    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();

    NRF_LOG_INFO("TWI scanner started.");
    NRF_LOG_FLUSH();
    twi_init();

    for (address = 1; address <= TWI_ADDRESSES; address++)
    {
        err_code = nrf_drv_twi_rx(&m_twi, address, &sample_data, sizeof(sample_data));
        if (err_code == NRF_SUCCESS)
        {
            detected_device = true;
            NRF_LOG_INFO("TWI device detected at address 0x%x.", address);
        }        else
        {
            NRF_LOG_INFO("error %d", err_code);
        }
        NRF_LOG_FLUSH();
    }

    if (!detected_device)
    {
        NRF_LOG_INFO("No device was found.");
        NRF_LOG_FLUSH();
    }

    while (true)
    {
        /* Empty loop. */
    }
}

/** @} */

I have attached an image of the schematics, in case there's anything wrong there.

Is there anything else I may be missing between the dev kit and a prototype configuration wise?

Details:

Using latest SES and latest available Nordic SDK (nRF5_SDK_17.1.0_ddde560).

  • Worth trying 2k2 or 4k7 pull-up resistors on SDA and SCL (R1 and R2), since 10k as fitted is rather optimistic and may not work; nRF52832 DK uses 4k7 on both. A scope would show a slow SCL rise time with 10k, maybe too slow for the sensor (newer sensors generally require faster rise times on CLK). In general use pins in H0D1 mode rather than S0D1, not sure what the driver does.

  • You're talking about hardware changes here? If that's whats needed then that's ok but I thought hardware was good 

  • Yes but if you'd rather get it working with software changes first :-)

    Try changing
           .scl                = 27,
           .sda                = 26,
    to
           .scl                = 28,
           .sda                = 25,

    I would recommend doing the resistor change as well, but maybe the 'scope trace will look good enough with 10k. 10k is not advisable, however.

  • that worked, thank you so much! i thought it was not possible to change pins? could you explain how this works if it's not too much effort for you?

    when you suggest hardware changes, I should change the resistor to be 2k2 or 4k7 and then i can continue to use the original pins?

  • Not quite, I was being a little facetious; probing with a 'scope would have shown you no signals at all, meaning the software pin definition didn't match the hardware pin connections. The hardware has defined port pins 25 (P0.25) as SDA and 28 (P0.28) as SCL; confusing, but "pins" 26 (P0.25) and 27 (P0.28) on the chip are referred to by the Port Pin designation P0.nn, not the hardware chip package definition. So the software change must be kept and can only be changed if the hardware is changed correspondingly.

    The pull-up value could probably be left as 10k, but if going to production - ie making more boards - I would recommend 4k7. 2k2 is even better, but 2k2 further marginally increases power consumption. On a recent project I had to use 900R (900 Ohms, 0.9K) to get one of the newer I2C devices working at 100kHz as the clock SCL rise-time parameter was so tight.

Related