Can I user NRF TWI Manager to write varying lengths from a buffer?

[exsurgo_ankit]

Hello,

I am attempting to use the NRF twi manager based on the "twi master using nrf twi manager" example. I noticed that the example only reads and wrties a single byte and hence the transfer sizes can be defined as constants. However, I am trying to use an I2C uart module, since NRF52832 only has one UART, to output some debug information.

Hence the writes are of variable length and I am struggling to get the code to compile as it requires the transfer[x].length to be a constant. So my question is if I can use the manager to schedule these writes.

I have attempted to use the standard twi master which results in watchdog resets as the "while (m_xfer_done == false)" results in a blocking call even when using an event handler. I understand that I could implement a queuing mechanism however, I am trying to avoid that effort if the twi manager does this already.

Ankit

[Jared]

Hi there,

I'm not 100% sure I get the problem correct. Is the problem that it seems that the twi manger only transmits one byte per transfer or that the transfer size has to be known at compile time?

I have attempted to use the standard twi master which results in watchdog resets as the "while (m_xfer_done == false)" results in a blocking call even when using an event handler. I understand that I could implement a queuing mechanism however, I am trying to avoid that effort if the twi manager does this already.

Also, do you mean that even though you're running the twi module in non-blocking mode it doesn't allow you to feed the watchdog which results in a watchdog timeout? How are you feeding the watchdog?

regards

Jared 

[exsurgo_ankit]

Hello Jared,

One of the problems is indeed that the transfer size should be known at compile time. I want them to be variable.

Regarding watchdog resets, I am feeding the watchdog in a timer. This is our third development project using nRF52. So we are using a stable base code that has been working in the field for about 2 years now and does not lead to watchdog resets. However, the current project uses TWI while the previous ones didn't. I added various log messages throughout to isolate the issue which seem to be the wait for TWI transfer to complete. I would prefer to queue the bytes and let the system clear them when possible. Is there something already available in NRF libraries that would achieve this for TWI?

Regards

[mrono]

exsurgo_ankit said:

I would prefer to queue the bytes and let the system clear them when possible.

The TWI manager already does this. It puts the messages in a queue and sends them once the bus is free. The example code is a bit simplistic as it just waits for completion using that while loop you quoted.

One case the library does not handle well is the case when the bus is stuck. Ie something is holding the bus low and the transfers never finish.

[exsurgo_ankit]

So is there are workaround for this stuck bus issue? 

Also can the transfer sizes be variable for the TWI manager? Is there an example?

[mrono]

exsurgo_ankit said:

Also can the transfer sizes be variable for the TWI manager? Is there an example?

I don't think I've ever actually tried varying the transfer size, but it should work. The transfer structs don't need to be const. And you can define them without the helper macros the example uses.

exsurgo_ankit said:

So is there are workaround for this stuck bus issue? 

I added a timeout and a uninit/reinit -cycle if the timeout is hit. This is mainly an issue if you use the blocking versions (the twi_manger_perform). I worked with a slave device that had an errata concerning ack timing. That device caused some watchdog timeouts until I figured out what was happening.