Stream data over TWI with start signal only in the beginning of the frame, and one stop at the end of the frame

[Bakry]

Hello,

I am working on a sensor which requires data transfer over with data length over 255 bytes. I am using nRF52832 uC and and from what I see from nordic infocenter by using the following portion of code:

ret_code_t nrf_drv_twi_tx(nrf_drv_twi_t const * p_instance,
                          uint8_t               address,
                          uint8_t const *       p_data,
                          uint8_t               length,
                          bool                  no_stop);

I can send up to 255 bytes and it is possible to set no_stop to true to not send a stop signal. However as you know, the simple write burst operation has a message similar to this message, , but that case isn't true, when Data Frame xxx is bigger than 255, since after each data frame, no start signal is resent.

[Bakry]

Thanks for your reply, I have eventually used:  

nrfx_err_t nrfx_twi_tx(nrfx_twi_t const * p_instance,
                       uint8_t            address,
                       uint8_t    const * p_data,
                       size_t             length,
                       bool               no_stop)
{
    nrfx_twi_xfer_desc_t xfer = NRFX_TWI_XFER_DESC_TX(address, (uint8_t*)p_data, length);
    return nrfx_twi_xfer(p_instance, &xfer, no_stop ? NRFX_TWI_FLAG_TX_NO_STOP : 0);
}

nrfx_err_t nrfx_twi_rx(nrfx_twi_t const * p_instance,
                       uint8_t            address,
                       uint8_t *          p_data,
                       size_t             length)
{
    nrfx_twi_xfer_desc_t xfer = NRFX_TWI_XFER_DESC_RX(address, p_data, length);
    return nrfx_twi_xfer(p_instance, &xfer, 0);
}

I will try to verify if it works this week. In the meantime, may I know what is the difference between TWIM library and nrfx_twi? 

I am using 17.02 SDK. Also, if size_t length can cover bytes over 255, why don't I use it instead?

[Karl Ylvisaker]

Bakry said:

I am using 17.02 SDK. Also, if size_t length can cover bytes over 255, why don't I use it instead?

Actually, I must rectify a mistake in my previous comment, my apologies.
It appears that the nRF52832 is still limited to a 255 byte TWI transfer limit, despite using TWIM with easyDMA.
This is due to the size of the peripheral's TXD.MAXCNT register.
I discussed this with a colleague, who informed me that even though if you were to use the ArrayList easyDMA feature for the TXD.MAXCNT register, it would still happen in two transfers.
My thought here was the same as you - that if you suspended with a NO_STOP at the end of the first buffer, you could continue into the next - but here you should instead get a repeated start.
My apologies for any confusion this might have caused.
Is this what you were referring to in your initial post?

Bakry said:

Thanks for your reply

No problem at all, I am happy to help!

Bakry said:

I will try to verify if it works this week.

Great, I look forward to hearing any updates.

Bakry said:

may I know what is the difference between TWIM library and nrfx_twi? 

The main difference between the two is that the TWIM driver uses easyDMA by default, while the nrfx_twi driver does not(but still can be configured to do so). This is not the only difference, but it is the most significant one. Please also see the reply by my colleague Einar in this ticket for some more details.

Best regards,
Karl

[Bakry]

Thanks for letting me know. In that case, how to avoid the repeated start?

[Bakry]

I was also thinking, is there anyway to reset the MAXCNT register after sending a desired amount of bytes less than 255 bytes, so it can progress the rest of the data. If it is not possible, is it possible to FIFO the data among this register ?

[Karl Ylvisaker]

Bakry said:

I was also thinking, is there anyway to reset the MAXCNT register after sending a desired amount of bytes less than 255 bytes, so it can progress the rest of the data.

By this, do you mean to change the MAXCNT register mid-transfer?
I do not think that change would take effect until the transfer is complete, because the data is already retrieved by the peripheral.

You could read more about the repeated start in the TWI peripheral documentation. This is what happens behind the scenes of the TXTX DESC - it is two transfers happening with a repeated start.
I do not think there is a way to avoid the repeated start when you are using a START TASK to trigger a second transfer or read.

Which exact sensor are you working with, and how does it handle a repeated start transfer?

Best regards,
Karl

[Karl Ylvisaker]

After some more digging, it seems to me that you might be able to avoid the repeated start if you use the SUSPENDED flag when grouping the transfers together, with the nrfx_twi_xfer function from the TWI driver.

The documentation here reads:

NRFX_TWI_FLAG_SUSPEND - Transfer will be suspended. This allows for combining multiple transfers into one transaction. Only transactions with the same direction can be combined. To finish the transaction, call the function without this flag.
Try this, and let me know if it resolves your issue.
This would of course mean that you wont use easyDMA, but perhaps that is an ok tradeoff here?

Best regards,
Karl

[Bakry]

I confirm that it is working!

[Karl Ylvisaker]

I am happy to hear that you were able to achieve the extended frame using the TWI driver!

Thank you for updating me on the progress.

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

Good luck with your development!

Best regards,
Karl