The TWI problems continue ...

[MuRa]

Hello all,

for the last few weeks I am trying to workout the i2c protocol with the sensor and the nrf52dk , so far none of the solution that I have considered work. More can be seen here: https://devzone.nordicsemi.com/f/nordic-q-a/84978/twi-reading-and-writing-basics/363652#363652

I am thinking can the speed of the processor be too fast for the sensor prototype, like the wires to the board may be too long, for example, for example, the same prototype works on the Arduino's Atmel omega just ok... 

Therefore, to test this out my question is, how to reduce the speed of the i2c to less than 100kHz and how to reduce the speed of the processor? Indeed, if you have other suggestions please do not hesitate.

Thank you in advance, looking forward to your suggestions, ideas, how to tackle this further.

Best.

[Edvin]

MuRa said:

I guess this was the aim of this code?

Yes. My point is that the transfer call will return NRF_SUCCESS on all addresses if you have a TWI event handler. It just means that the packet was "successfully queued". 

[MuRa]

Thanks Edvin, good to know what is the point of the event handler... can this be as well used on the "no_stop" parameter? See below for more.

Anyway, now it is known that the access to the sensor , namely its slave address is correct , so this is not the problem while reading the sensor. For example, I am still getting strange output, for more see my previous post https://devzone.nordicsemi.com/f/nordic-q-a/84978/twi-reading-and-writing-basics/363652#363652

There was a mention ( https://devzone.nordicsemi.com/f/nordic-q-a/84978/twi-reading-and-writing-basics/363652#363652 )  that "no_stop" could be a question for that problem, however, I did not checked that, because I am not sure what and how should be "no_stop" used, afterwards checked, if this is the issue at all. Looked for the explanation in the SDK, but could not find it. Can you help me in this case too, namely how to check, if my "no_stop" is the subject of concern for the strange output of the sensor ? Indeed, when the sensor is connected to the other dev platform, for which I have the manufacturers i2c API works seamlessly, the same sensor. 

Looking forward to your reply.

[Edvin]

I don't know what your sensor expects with regards to the stop contidition. Did you test both enabling and disabling it?

Search for "stop condition" and "repeated start" in the datasheet for your sensor.

It may also be, if you are using an event handler, and hence non-blocking TWI, that you are sending the messages too fast. Perhaps you should try to wait for the previous transaction to complete (and you get the callback) before you send the next message?

Use the NRF_DRV_TWI_EVT_DONE event to set a parameter, and wait for this parameter to be set before sending the next message.

Best regards,

Edvin

[MuRa]

Hello Edvin and thanks for your reply, see below:

Edvin said:

I don't know what your sensor expects with regards to the stop contidition.

According to the manufacturer : For the Read I2C protocol, it is important that the restart condition is being sent before the second slave address and please ensure that no Stop condition being sent before the restart condition because some I2C library sends stop condition before restart condition. 

Edvin said:

Did you test both enabling and disabling it?

Can you say more about that? For example, in the main() the sensor is reset, while in the end of this method the so called proximity is enabled, this is also works if the proximity is enabled in the while () loop, indeed with a delay of 10-40ms .. is this what you have in mind when you say enable/disable? The function of the sensor or the sensor itself?

Edvin said:

It may also be, if you are using an event handler, and hence non-blocking TWI, that you are sending the messages too fast. Perhaps you should try to wait for the previous transaction to complete (and you get the callback) before you send the next message?

OK, what is too fast, and where to control this? I guess you are referring to the nrf_delay_ms() ??? Namely to put the delay between the two send/receive functions you are referring at?

Edvin said:

Use the NRF_DRV_TWI_EVT_DONE event to set a parameter, and wait for this parameter to be set before sending the next message.

OK, where should this be implemented? I guess inside the event handler, but when, what and how?

Best.

[Edvin]

MuRa said:

Can you say more about that?

There are many drivers and layers you can use for the TWI, but perhaps the comment marked as an answer here:

https://devzone.nordicsemi.com/f/nordic-q-a/84978/twi-reading-and-writing-basics/363652#363652 (your reply), has an input parameter called no_stop. Try setting this to true.

MuRa said:

For example, in the main() the sensor is reset, while in the end of this method the so called proximity is enabled, this is also works if the proximity is enabled in the while () loop, indeed with a delay of 10-40ms .. is this what you have in mind when you say enable/disable? The function of the sensor or the sensor itself?

I don't understand this. What is proximity in this context?

MuRa said:

OK, what is too fast, and where to control this? I guess you are referring to the nrf_delay_ms() ??? Namely to put the delay between the two send/receive functions you are referring at?

Wait until you get the callback that the message is sent before sending the next message.

MuRa said:

OK, where should this be implemented? I guess inside the event handler, but when, what and how?

In your snippet from one of your earlier answers, you have the variable m_xfer_done which you set to true inside the callback, then you wait for this variable to become true before you send again.