TWI Module problems

[AliMahmood123]

Hi there
I am facing a strange issue nowadays after working continuously for two weeks + with the TWI module. I started off the with twi_sensor example in non blocking but "polling" mode.

By polling mode I mean the xfer flag was continuously being read in while();  I replicated that and it worked. What I added to that is instead of reading a static global flag. I read the flag status via a function and then proceed to immediately go for a write after read.

So the flow is like this:

Write ---> Wait for while(  ret =  getStatus()  == true ); polling---> Immediately read
This gives me ambiguous results until I add an nrf_delay immediately after the read. The write is not done properly, infact its not done at all in most cases. I ensured that as I know that the read function is working absolutely correctly.

So Q1 is
Why should I need a delay when the event has been fired, what good will the nrf_delay is after the write? Please explain, the example project with a global flag works fine, same thing with a

small function call doesnt

I managed to fix it with multiple function calls but return calls
so my function calls were:
write_api(pass data) --->eeprom_write(pass_data)--->nrf_xfer

So after the transfer is done the function returns two times, by that time the transfer is always complete (without delay)

Anyways Q2 is:
2) Debug vs Release - The above scenario only works in Debug mode, why not in Release mode?

I need to fix this within a week,our product is in dev phase and since its working in debug mode we have moved forward, but we will eventually need to fix it

[hmolesworth]

I suspect you are looking in the wrong place. The TWI write is behaving (probably) exactly as you wish/expect, but you may be overlooking something else. Write to an EEPROM via TWI/I2C takes a long time, typically 5mSecs. The "write" command completes immediately, but the write command only starts the internal memory write and that does not complete until (say) 5mSecs later so another write will fail if started before that time is up.

Fix this by doing a status read of the EEPROM to check when the write has completed, or just wait for the worst-case write time.

Why does it work in debug? 'cos debug mode is slow and typically slow enough to allow the write to complete, although that may be flakey.

[AliMahmood123]

Hi there
Thanks for the prompt reply. I thought so too that the EEPROM needed time and the branched function call did the trick
I also add an nrf_delay_ms between the read write
The code is simple

status_i2c = i2c_get_status(&eeprom);
        if(status_i2c == i2c_idle)
        {
            status_i2c = write_api(&eeprom);
            while(status_i2c == pending)
            {
                status_i2c = i2c_get_status(&eeprom);
            };

            nrf_delay_ms(2000);

            memset(myArr_rx,0,200);
            status_i2c = read_api(&eeprom, &transfer_read);

            while(status_i2c == pending)
            {
                status_i2c = i2c_get_status(&eeprom);
            };
        }

        else
        {
            NRF_LOG_INFO("Get Status Failure");
        }

But despite of the delay, the code does not work in Release mode. I found the fix for eeprom write cycle problem, but why does a two second delay that completely halts the processor, is not enough for a transaction?

[AliMahmood123]

I have also tried to add a whopping 10 second delay write after my write call, but it doesnt seem to work on Release mode. On debug mode like I said any form of delay does work