SDK17 TWI (i2C) problem

[Epasta]

Hello,

sorry to border you again, but I have a problem that block me for many days. I read all nordic questions on TWI (I2C) but did not found a solution... :(

I have implemented TWI with zephyr i do not have any problem, it works perfectly. Here below my ZEPHYR code.
If i read 0xA5 register address before write it I read 0x20, and after writing it I read 0xFD. And this is ok.

#define FRAM_I2C_ADDR	0x6D
ret = i2c_reg_write_byte(i2c_dev_name, FRAM_I2C_ADDR, 0xA5, 0xFD);
if (ret) {
    printk("Error writing to sensor! error code (%d)\n", ret);
    return;
} else {
    printk("Scrittura  ok.\n");
    data[0] = 0x00;
    ret = i2c_reg_read_byte(i2c_dev_name, FRAM_I2C_ADDR, 0xA5, &data[0]);
    printk("Leggo il valore del registro A5, valore %d \n", data[0]);
}

But I can't have the same result with SDK17.
If I read 0xA5 register address before write it I read 0x20, and after writing it i read always 0x20. it seems that writing function does not work. Here below my code.

#define FRAM_I2C_ADDR	0x6D
#define SYS_REG         0xA5
#define SYS_REG_VALUE   0xFD
void sys_config(){
    ret_code_t err_code;
    uint8_t reg[2] = {SYS_REG, SYS_REG_VALUE};
    m_xfer_done = false;
    err_code = nrf_drv_twi_tx(&m_twi, FRAM_I2C_ADDR, reg, sizeof(reg), false);
    if (err_code) {
        NRF_LOG_INFO("Error (%d)\n", err_code);
        return;
    } else {
        NRF_LOG_INFO("Success \n");
        while(!m_xfer_done){}
        m_xfer_done = false;
        err_code = nrf_drv_twi_rx(&m_twi, FRAM_I2C_ADDR, &m_sample, sizeof(m_sample));
        if(err_code) {
            NRF_LOG_INFO("Error \n");
        } else {
            NRF_LOG_INFO("Success register A5 %d \n", m_sample);
        } 
    }
}

Can you see something wrong in my sys_config() func?
My function on SDK17 for wrting address on i2C device it's ok? what is wrong? Why i can not write 0xA5 register as in zephyr?
I have lost a lot of time on it... Any suggerstions are welcome.

Thanks again for you support.
Best regards

[Karl Ylvisaker]

Hello,

Are you seeing any errors on runtime when you run your nRF5 SDK code?
Could you show me exactly what you log says when you run this function?
Do you have access to a logic analyzer? It would be very helpful to see what is happening on the lines here.

For future reference I recommend that you make use of the TWIM driver directly if this is a new development. With the TWIM driver you should call nrfx_twim_xfer with a TXRX descriptor to first do a TX and then an RX.

But I can't have the same result with SDK17.

I have implemented TWI with zephyr i do not have any problem, it works perfectly.

If I may ask, why are you moving from a Zephyr project onto using the nRF5 SDK?
As detailed in this blogpost we recommend that all new development now happens on the NCS SDK instead.

Best regards,
Karl

[Epasta]

Hello, 

thanks for your time and the reply.
- No i do not have any errors during runtime.

"If I may ask, why are you moving from a Zephyr project onto using the nRF5 SDK?"
- i read that nrf5 sdk is more stable. Is this not true? I saw also that on powering on, NRFSDK is faster than NCS

Do you suggest to me to continue with NCS SDK? If yes I stop develop on NRF5 SDK and I will continue on NCS SDK

Thanks again for your time
Best regards

[Karl Ylvisaker]

Epasta said:

thanks for your time and the reply.

No problem at all, I am happy to help! :) 

Epasta said:

- i read that nrf5 sdk is more stable. Is this not true?

Epasta said:

Do you suggest to me to continue with NCS SDK?

I recommend that you read through the blogpost I referenced about this before you make your decision, but to summarize; the nRF5 is our most mature SDK, having existed for a decade already. The nRF5 SDK is currently going into maintenance mode, meaning that it will no longer receive any new features, only bugfixes and security patches. The nRF Connect SDK is our new SDK, which we are actively developing and adding new features to. All coming BLE features will be added to the NCS SDK. The NCS SDK is also RTOS based (Zephyr) which is a great advantage of it as well.
So, while the nRF5 SDK is the 'tried and true' SDK - and a good choice still - it will not feature anything that is not in it already, so new developments that wish to be able to make use of all the new BLE features and improvements should develop with the NCS SDK.

Personally, I would recommend that all new developments happens on the NCS SDK.

Epasta said:

I saw also that on powering on, NRFSDK is faster than NCS

Could you elaborate on this? To my knowledge the SoC will have approximately equal startup time when used with either SDK.

Best regards,
Karl

[Epasta]

Hello Karl,

ok, i will go back on NCS SDK, and i think that i will stay there.

What I saw is that:
NCS powering on is 0.5 seconds slower than NRFSDK power on. So doesn't matter it is just a consideration.

Thanks again
Best regards

[Karl Ylvisaker]

Epasta said:

ok, i will go back on NCS SDK, and i think that i will stay there.

I think this is a great choice - the nRF Connect SDK has production support for the nRF52 series already, so there should be no problem using it as it is currently.
As an added bonus to the nRF Connect SDK we just launched the Visual Studio Extension pack too, so you may use Visual Studio code for your development! :)

Epasta said:

NCS powering on is 0.5 seconds slower than NRFSDK power on. So doesn't matter it is just a consideration.

That is strange, 0.5 seconds is quite a lot when it comes to extra time powering up. I will make a note of this and have a look to see if I can replicate it on my end as well.
Thanks for the headsup!

Please do not hesitate to open another ticket if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl