NRF_ERROR_NO_MEM in nrf_twi_sensor_write

[aonsquared]

I'm getting an error NRF_ERROR_NO_MEM when trying to initialize the LPS22HB, and the RTT log shows:

<info> twi_sensor: Write register: 0x0B

<info> twi_sensor: Sensor addr: 0x5C Write length 2

<warning> twi_sensor: Memory not allocated. Sensor addr: 0x5C

<error> app: ERROR 4 [NRF_ERROR_NO_MEM] at :0

PC at: 0x00000000

<error> app: End of error report

The line being triggered is in nrf_twi_sensor.c, line 151, which is nrf_twi_sensor_write().

I've initialized the sensor like this:

NRF_TWI_MNGR_DEF(m_nrf_twi_mngr, MAX_PENDING_TRANSACTIONS, TWI_INSTANCE_ID);
NRF_TWI_SENSOR_DEF(m_twi_sensor, &m_nrf_twi_mngr, 128);
LPS22HB_INSTANCE_DEF(m_lps22b, &m_twi_sensor, TWI_ADDRESS);

int main(void)
{
    //...other code removed
    lps22hb_init(&m_lps22b);
    lps22hb_data_read(&m_lps22b,&barometer_callback,&baro_data,1);
    //...other code removed   
}

If I don't handle the error with APP_ERROR_CHECK() the rest of the program runs normally, except for not being able to read anything off the LPS22 sensor. Using nrf SDK version 17.0.2.

[aonsquared]

So as an update, I increased LPS22HB_MIN_QUEUE_SIZE from 4 to 32 in lps22hb.h and the error has changed to 0x09 (NRF_ERROR_INVALID_LENGTH)...

[Edvin]

Hello,

Did you try to look inside nrf_twi_sensor_write() and debug to figue out why it returns 0x04/0x09? 

When it returned 0x04, was it because nrf_twi_sensor_write_cmd_t * p_cmd was NULL? 

When it returned 0x09, is it because length > NRF_TWI_SENSOR_SEND_BUF_SIZE? What is NRF_TWI_SENSOR_SEND_BUF_SIZE in your case?

(All of these names are from inside nrf_twi_sensor_write())

Best regards,

Edvin

[aonsquared]

Hi, apologies for the delay as I only got back to my test setup - p_cmd is indeed returned as NULL when nrf_balloc_alloc() is called.

If I set LPS22HB_MIN_QUEUE_SIZE to 32 then it hits the if statement in lps22hb_init():

ret_code_t lps22hb_init(lps22hb_instance_t * p_instance)
{
    ASSERT(p_instance != NULL);
    p_instance->interrupt_cfg = 0;
    p_instance->ctrl_reg[0]   = 0;
    p_instance->ctrl_reg[1]   = LPS22HB_CTRL_REG2_DEFAULT;
    p_instance->ctrl_reg[2]   = 0;
    p_instance->fifo_ctrl     = 0;
    ret_code_t err_code;
    if (p_instance->p_sensor_data->p_twi_mngr->p_queue->size < LPS22HB_MIN_QUEUE_SIZE)
    {
        return NRF_ERROR_INVALID_LENGTH;
    }

    err_code = lps22hb_cfg_commit(p_instance);
    return err_code;
}

p_instance->p_sensor_data->p_twi_mngr->p_queue->size evaluates to 5 which is less than 32.

So no, it's not because length is more than the buffer size...

[Edvin]

So where does 5 come from? Is it your MAX_PENDING_TRANSACTIONS, or did you change:

NRF_TWI_SENSOR_DEF(m_twi_sensor, &m_nrf_twi_mngr, 128);

to

NRF_TWI_SENSOR_DEF(m_twi_sensor, &m_nrf_twi_mngr, 5);

?

I don't have anything that I can compile that uses this library. 

aonsquared said:

So no, it's not because length is more than the buffer size...

no, it is because your p_queue is less than the minimum queue size. 

Would it be possible to zip and send your project? just a strip down project that replicates the issue.

Best regards,

Edvin

[aonsquared]

It's our MAX_PENDING_TRANSACTIONS.

Yes, it's possible to zip and send our project, where should I send it to?

[Edvin]

Just upload it here(drag'n'drop).

[aonsquared]

We sent it via private message instead, as we haven't trimmed it down.

[Edvin]

So I tested the project. I struggle to reproduce the issue on an nRF52832 DK without any additional HW connected. Are you able to reproduce it on an unmodified DK without any external SPI devices?

Have you tried debugging to see the call trace when the issue occurs? Was it the nrf_twi_sensor_write() that caused the issue? What function called that function, and from what interrupt does this occur? Is it the timer interrupt? Does it trigger if the SPI device is not connected?

Best regards,

Edvin

[aonsquared]

Hi Edvin,

We're using the u-blox EVK-BMD-330 which is using the nRF52810 and only has 24k of RAM. There's no SPI device - our custom board only has the LPS22HB and same LEDs and buttons as the DK.

Does this mean that the block allocator doesn't have enough space? Can we reduce msg_buff_size for example in NRF_TWI_SENSOR_DEF?

[Edvin]

So you are actually using an nRF52810. In that case, you should at least remove the two instances (!!) (CFLAGS and ASMFLAGS) in your makefile called DDEVELOP_IN_NRF52832)

I don't know if that solves it, but did you try to increase the MAX_PENDING_TRANSACTIONS from 5 to at least 32 in your main.c file?

Edvin said:

So where does 5 come from? Is it your MAX_PENDING_TRANSACTIONS, or did you change:

This was at least an issue, since the TWI is set up with this buffer size, and the init function required the buffer size to be larger than or equal to LPS22HB_MIN_QUEUE_SIZE, which you set to 32.

[aonsquared]

We've set the LPS22HB_MIN_QUEUE_SIZE back to 4. The main issue we're having is the nrf_balloc_alloc() call returning NULL, so we'll try removing the CFLAGS and ASMFLAGS for nrf52832.

When you try to replicate the issue does the call to nrf_twi_sensor_write() finish without returning error 0x04?

[Edvin]

presumably:

Unless you sent me a project that doesn't use the twi. I assume it is called somehow from within lps22hb_data_read()?

aonsquared said:

We've set the LPS22HB_MIN_QUEUE_SIZE back to 4.

If the issue originally was that the queue size was too small, I suggest that you try to set them both to 32, or even just 10, to see if the behavior changes.

Best regards,

Edvin