Most Significative Bit in TWIM RX transfer is always 1

RE: Most Significative Bit in TWIM RX transfer is always 1

Jørgen Holmefjord — Thu, 03 Sep 2020 13:59:28 GMT

As far as I know, this is not fixed on nRF52833. See the following note in the product specifications:

"This TWI master supports clock stretching performed by the slaves. Note that the SCK pulse following a stretched clock cycle may be shorter than specified by the I2C specification."

This note is not included in the nRF52832 PS, hence the need for the errata.

Best regards,
Jørgen

RE: Most Significative Bit in TWIM RX transfer is always 1

EddyB — Thu, 03 Sep 2020 13:42:34 GMT

Hello,

We have exactly the same problem and when scoping it is very clear to us that the Errata 149, being the incorrect first clock after the clock stretching, causes the problem. Since there is apparently no solution with the nRF52832, we are considering moving to the nRF52833.
Can you please confirm that this issue has been resolved in the nRF52833?

Thank you!

RE: Most Significative Bit in TWIM RX transfer is always 1

Jørgen Holmefjord — Thu, 27 Aug 2020 12:20:24 GMT

[quote user="Pedro Martins"]What is shown is that the short starts the RX transfer immediately after the TX. This might be a problem if the master ignores clock stretching. Is that the case?[/quote]

As far as I know, the master will not ignore clock stretching from the slave. All clock stretching shown in the diagrams are performed by the master itself.

RE: Most Significative Bit in TWIM RX transfer is always 1

martinspedro — Thu, 16 Jul 2020 13:43:53 GMT

Thank you for the quick response Jørgen Holmefjord, but I don't understand what you mean by:

[quote userid="14926" url="~/f/nordic-q-a/63519/most-significative-bit-in-twim-rx-transfer-is-always-1/260333"]will actually generate a repeated start condition and not just avoid the STOP condition[/quote]

Since the TWI interface is compatible with the I2C protocol and to the best of my knowledge, a repeated start is when the master initiates a new transaction on the bus without finishing the previous transaction, i.e., without sending a stop condition. Therefore, not sending a stop condition and sending a repeated start refer to the same behavior. Please advise if there is something I am missing on my understanding.

Regarding the shortcut between the LASTTX->STARTRX, I looked at the TWIM diagrams. What is shown is that the short starts the RX transfer immediately after the TX. This might be a problem if the master ignores clock stretching. Is that the case?

However, on the diagram below to the one you provided, clock stretching is shown when using a TXRX transfer.

To summarize, my question is: Does using a TXRX transfer causes the master to not accept/ignore clock stretching by the slave?

RE: Most Significative Bit in TWIM RX transfer is always 1

Jørgen Holmefjord — Thu, 16 Jul 2020 10:27:30 GMT

I checked the documentation again, and it looks like the LASTTX->STARTRX short, which are used in the TXRX case in nrfx_twim, will actually generate a repeated start condition and not just avoid the STOP condition. See the diagram in Master repeated start sequence.

RE: Most Significative Bit in TWIM RX transfer is always 1

martinspedro — Thu, 16 Jul 2020 10:05:44 GMT

Thank you for the clarification, Jørgen Holmefjord.

From the TWIM documentation, I was expecting the behavior you described in the usage of the flags and transfer types.

However, note that sending a TX transfer without a stop condition and immediately after sending a RX transfer results in the data being correctly received from the slave, while sending a TXRX doesn't get me any data in the secondary buffer.

So, the fact that a STOP condition is not being generated does not seem to affect the behavior of the slave, otherwise, to my understanding, it wouldn't work on a TX with no stop condition + RX communication.

Are there any other differences between a TX+RX and a TXRX transfer?

RE: Most Significative Bit in TWIM RX transfer is always 1

Jørgen Holmefjord — Thu, 16 Jul 2020 09:30:39 GMT

The difference between using NRFX_TWIM_XFER_DESC_TXRX and separate NRFX_TWIM_XFER_DESC_TX/RX is that the first option will by default not generate a STOP condition between the TX and RX operations, while the second option will generate a STOP condition. It can be that the slave device you are using is expecting a STOP condition in this case, meaning that the NRFX_TWIM_XFER_DESC_TXRX option will not work.

A transfer with NRFX_TWIM_XFER_DESC_TX can take a flag (NRFX_TWIM_FLAG_TX_NO_STOP) to also not generate a STOP condition, but there is no similar flag for NRFX_TWIM_XFER_DESC_TXRX to force a STOP condition between the transfers.

RE: Most Significative Bit in TWIM RX transfer is always 1

martinspedro — Wed, 15 Jul 2020 18:17:18 GMT

Hi Jørgen Holmefjord,

[quote userid="14926" url="~/f/nordic-q-a/63519/most-significative-bit-in-twim-rx-transfer-is-always-1/259860"] Some fixes were introduced in nrfx v1.8.2 and should be included in nRF5 SDK v17.0.0 (which uses nrfx v1.8.4). Can you try to update to the latest SDK, to see if this solves some of your issues?[/quote]

Thank you for the suggestion. I successfully migrated from the NRF5 SDK version 16.0.0 to 17.0.0, to update the nfrx drivers.

The behavior described in my message above (the nrfx_twim_xfer stays stuck on a TXRX transfer), is solved, since the transfer either successfully or unsuccessfully finishes.

However, when doing a TXRX transfer, the RX buffer is empty, i.e., no data was read from the slave. This behavior occurs either if I set up the TWIM module to operate in a blocking or non-blocking mode. An example of a TXRX transfer is below:

// partially Init Array (Checksum field not initialized)
cmd_frame2[0] = MCP39F521_HEADER_BYTE;
cmd_frame2[1] = REG_READ_CMD_N_BYTES;
cmd_frame2[2] = MCP39F521_SET_ADR_PTR_INSTR;
cmd_frame2[3] = (reg_address & LEFTMOST_BYTE_BIT_MASK) >> BYTE_SHIFT;
cmd_frame2[4] = reg_address & RIGHTMOST_BYTE_BIT_MASK;
cmd_frame2[5] = MCP39F521_REG_READ_INSTR;
cmd_frame2[6] = n_bytes;

uint8_t bytes = n_bytes + MCP39F521_RESPONSE_BASE_N_BYTES;
cmd_frame2[REG_READ_CMD_N_BYTES - 1] = __compute_byte_addition_checksum(cmd_frame2);      // Compute Command Checksum

nrfx_twim_xfer_desc_t txrx_xfer = NRFX_TWIM_XFER_DESC_TXRX(MCP39F521_BASE_ADDRESS, cmd_frame2, REG_READ_CMD_N_BYTES, rx_data, bytes);

err_code = nrfx_twim_xfer(g_mcp39f521_twim_instance, &txrx_xfer, 0);
if (err_code != NRF_SUCCESS) {
  NRF_LOG_DEBUG("TX Error Code: %d", err_code);
}

Nonetheless, if I split the TXRX transfer into a TX and a RX transfer, either using the TWIM module in blocking or non-blocking configurations, the RX buffer successfully contains the device response.

// partially Init Array (Checksum field not initialized)
cmd_frame2[0] = MCP39F521_HEADER_BYTE;
cmd_frame2[1] = REG_READ_CMD_N_BYTES;
cmd_frame2[2] = MCP39F521_SET_ADR_PTR_INSTR;
cmd_frame2[3] = (reg_address & LEFTMOST_BYTE_BIT_MASK) >> BYTE_SHIFT;
cmd_frame2[4] = reg_address & RIGHTMOST_BYTE_BIT_MASK;
cmd_frame2[5] = MCP39F521_REG_READ_INSTR;
cmd_frame2[6] = n_bytes;

uint8_t bytes = n_bytes + MCP39F521_RESPONSE_BASE_N_BYTES;
cmd_frame2[REG_READ_CMD_N_BYTES - 1] = __compute_byte_addition_checksum(cmd_frame2);      // Compute Command Checksum

nrfx_twim_xfer_desc_t tx_xfer = NRFX_TWIM_XFER_DESC_TX(MCP39F521_BASE_ADDRESS, cmd_frame2, REG_READ_CMD_N_BYTES);
nrfx_twim_xfer_desc_t rx_xfer = NRFX_TWIM_XFER_DESC_RX(MCP39F521_BASE_ADDRESS, rx_data, bytes);

err_code = nrfx_twim_xfer(g_mcp39f521_twim_instance, &tx_xfer, 0);
if (err_code != NRF_SUCCESS) {
  NRF_LOG_DEBUG("TX Error Code: %d", err_code);
}


err_code = nrfx_twim_xfer(g_mcp39f521_twim_instance, &rx_xfer, 0 );
if (err_code != NRF_SUCCESS) {
  NRF_LOG_DEBUG("TX Error Code: %d", err_code);
}

As the TXRX transfer sends a Repeated Start instead of a Start + Stop bit, I have also tested sending a TX transfer with a repeated start, using the NRFX_TWIM_FLAG_TX_NO_STOP, and then performing the RX transfer. For that, I changed the line

err_code = nrfx_twim_xfer(g_mcp39f521_twim_instance, &tx_xfer, 0);

err_code = nrfx_twim_xfer(g_mcp39f521_twim_instance, &tx_xfer, NRFX_TWIM_FLAG_TX_NO_STOP);

And successfully received the expected data response on the RX buffer.

Please consider that when I am enabling the non-blocking mode, I add a while loop after each nrfx_twim_xfer call. This loop waits for a flag variable that is toggled on the twim callback routine when the NRFX_TWIM_EVT_DONE occurs. This implementation is to simplify testing and is similar to the twim_sensor example.

Can you provide info about this recent issue?

Also, why does a TX transfer with repeated start + a RX transfer succeeds and retrieves the correct data and a TXRX transfer does not?

Please notice that the underlying issue, the "Most Significative Bit in TWIM RX transfer is always 1", still occurs.

Thank you for your time and help

RE: Most Significative Bit in TWIM RX transfer is always 1

Jørgen Holmefjord — Tue, 14 Jul 2020 09:32:37 GMT

I think that could happen with older driver versions if the slave is misbehaving. Some fixes were introduced in nrfx v1.8.2 and should be included in nRF5 SDK v17.0.0 (which uses nrfx v1.8.4). Can you try to update to the latest SDK, to see if this solves some of your issues?

RE: Most Significative Bit in TWIM RX transfer is always 1

martinspedro — Thu, 09 Jul 2020 16:44:01 GMT

I recognize that not having the scope available makes more difficult to figure this one out.

[quote userid="14926" url="~/f/nordic-q-a/63519/most-significative-bit-in-twim-rx-transfer-is-always-1/259247"]As far as I know, handling of clock stretching performed by the TWI slave is handled purely in HW. There are no timeouts in the driver, so it should always wait for either a STOPPED or ERROR event to be generated (or SUSPENDED event in case of TX without STOP condition)[/quote]

Regarding the driver timeouts, if the "managing" of the clock stretch is fully performed by the HW and if I fully understood the TWIM driver documentation, then:

I should use the nrfx_twim_xfer to send a transfer;
In my case, since I want to performed a write followed by a read, I should use the NRFX_TWIM_XFER_DESC_TXRX macro to encapsulate the data to be sent
The data buffers p_tx and r_tx on the transfer descriptor should reside .data memory section of RAM, since the TWIM driver uses EasyDMA.

If this is true, consider that I do not use an event handler and want a blocking transfer. My TWIM config would be the following:

void twim_init (void)
{
    ret_code_t err_code;

    const nrfx_twim_config_t twim_config = {
       .scl                 = ARDUINO_SCL_PIN,
       .sda                 = ARDUINO_SDA_PIN,
       .frequency           = NRF_TWIM_FREQ_100K,
       .interrupt_priority  = NRFX_TWIM_DEFAULT_CONFIG_IRQ_PRIORITY,
       .hold_bus_uninit     = NRFX_TWIM_DEFAULT_CONFIG_HOLD_BUS_UNINIT
    };

    err_code = nrfx_twim_init(&m_twi_master, &twim_config, NULL, NULL);
    APP_ERROR_CHECK(err_code);

    nrfx_twim_enable(&m_twi_master);
}

and I am executing the transfer by doing the following (cmd_frame2 is formatted to be a valid MCP39F521. More info on the MCP39F521 datasheet)

  // Init cmd_frame2, a global variable array
  cmd_frame2[0] = MCP39F521_HEADER_BYTE;
  cmd_frame2[1] = REG_READ_CMD_N_BYTES;
  cmd_frame2[2] = MCP39F521_SET_ADR_PTR_INSTR;
  cmd_frame2[3] = (reg_address & LEFTMOST_BYTE_BIT_MASK) >> BYTE_SHIFT;
  cmd_frame2[4] = reg_address & RIGHTMOST_BYTE_BIT_MASK;
  cmd_frame2[5] = MCP39F521_REG_READ_INSTR;
  cmd_frame2[6] = n_bytes;

  // Number of bytes required on the response
  uint8_t bytes = n_bytes + MCP39F521_RESPONSE_BASE_N_BYTES;
  
  // Compute Command Checksum
  cmd_frame2[REG_READ_CMD_N_BYTES - 1] = __compute_byte_addition_checksum(cmd_frame2);      

  nrfx_twim_xfer_desc_t txrx_xfer = NRFX_TWIM_XFER_DESC_TXRX(MCP39F521_BASE_ADDRESS, cmd_frame2, REG_READ_CMD_N_BYTES, rx_data, bytes);

  err_code = nrfx_twim_xfer(g_mcp39f521_twim_instance, &txrx_xfer, 0  );

Then, I should expect nrfx_twim_xfer to either finish the transfer successfully or return an error code, correct? However the call to nrfx_twim_xfer never returns.

Debugging, I am stuck on the while loop on line 523, on nrfx_twim.c, which is the following:

        while (!nrf_twim_event_check(p_twim, evt_to_wait))
        {
            if (nrf_twim_event_check(p_twim, NRF_TWIM_EVENT_ERROR))
            {
                NRFX_LOG_DEBUG("TWIM: Event: %s.", EVT_TO_STR_TWIM(NRF_TWIM_EVENT_ERROR));
                nrf_twim_event_clear(p_twim, NRF_TWIM_EVENT_ERROR);
                nrf_twim_task_trigger(p_twim, NRF_TWIM_TASK_RESUME);
                nrf_twim_task_trigger(p_twim, NRF_TWIM_TASK_STOP);
                evt_to_wait = NRF_TWIM_EVENT_STOPPED;
            }
        }

Is my reasoning correct? If so, what am I missing on the driver and TWIM module behavior?

RE: Most Significative Bit in TWIM RX transfer is always 1

Jørgen Holmefjord — Thu, 09 Jul 2020 14:30:59 GMT

[quote user="Pedro Martins"]Regarding clock stretching, can you please inform how well are the twim drivers "prepared to deal with with"?[/quote]

As far as I know, handling of clock stretching performed by the TWI slave is handled purely in HW. There are no timeouts in the driver, so it should always wait for either a STOPPED or ERROR event to be generated (or SUSPENDED event in case of TX without STOP condition). It would really help if you could get some logic traces of the bus to see what is actually going on.

RE: Most Significative Bit in TWIM RX transfer is always 1

martinspedro — Thu, 09 Jul 2020 11:11:26 GMT

Thank you for the suggestions hmolesworth.

Regarding the internal pull-up values, the Arduino Uno uses 20 kΩ and the NRF52 DK 13 kΩ. Since I am using the MCP39F521 Development Kit, it has 2.1 kΩ pull-ups on the I2C lines. This yields the total pull-up resistors for the Arduino setup to be 1.9 kΩ and 1.8 kΩ for the NRF52 DK.

I have also tried using only the MCP39F521 Development Kit, pull ups, i.e., disabling the NRF52 DK internal pull-ups, but the result is the same (as would be expected, since the total pull-up values are very similar)

[quote userid="65515" url="~/f/nordic-q-a/63519/most-significative-bit-in-twim-rx-transfer-is-always-1/259055"]I would also try H0D1 settings for both SDA and SCL pins[/quote]

The stronger low driver makes sense. I changed the GPIO drive mode to the High-Drive '0', but the result stays the same.

RE: Most Significative Bit in TWIM RX transfer is always 1

martinspedro — Thu, 09 Jul 2020 10:30:30 GMT

[quote userid="14926" url="~/f/nordic-q-a/63519/most-significative-bit-in-twim-rx-transfer-is-always-1/259017"]Your reasoning sounds plausible, but it would really help if you could get logic/scope traces of the bus to determine if this could be what is happening.[/quote]

Thank you for confirming Jørgen. I am trying to get my hands on a scope/logic analyzer. If I can get one during the next week, I update my answer with scopes.

[quote userid="14926" url="~/f/nordic-q-a/63519/most-significative-bit-in-twim-rx-transfer-is-always-1/259017"]t is strange if you see this every time if it is related to clock stretching unless the slave performs clock stretching on every transfer. [/quote]

From my understanding of the MCP39F521 datasheet, this is indeed true. The device performs clock stretching on every transfer. Regarding clock stretching, can you please inform how well are the twim drivers "prepared to deal with with"?

I noticed several failed reads from the NRF52 DK and it seems that the MCU fails to wait for a response of the MCP39F521. This behavior happens on blocking and non-blocking mode and results on NRF_ERROR_INTERNAL or NRF_DEVICE_NACK.

Also, despite the device supporting up to 400 kHz, the MCU only receives "garbage data" if the line is configured to 250 or 400 kHz.

[quote userid="14926" url="~/f/nordic-q-a/63519/most-significative-bit-in-twim-rx-transfer-is-always-1/259017"]Have you tried other slaves to see if they experience the same behavior?[/quote]

Not yet, but I will during the following days.

RE: Most Significative Bit in TWIM RX transfer is always 1

hmolesworth — Wed, 08 Jul 2020 23:03:50 GMT

Long shot, but try comparing the total pull-up resistance between the DK and the Arduino (parallel combo of board and sensor board); if they are the same then this isn't an issue.

I would also try H0D1 settings for both SDA and SCL pins. This is the default:

#define TWIM_PIN_INIT(_pin) nrf_gpio_cfg((_pin),                     \
                                         NRF_GPIO_PIN_DIR_INPUT,     \
                                         NRF_GPIO_PIN_INPUT_CONNECT, \
                                         NRF_GPIO_PIN_PULLUP,        \
                                         NRF_GPIO_PIN_S0D1,          \
                                         NRF_GPIO_PIN_NOSENSE)

This would be better

#define TWIM_PIN_INIT(_pin) nrf_gpio_cfg((_pin),                     \
                                         NRF_GPIO_PIN_DIR_INPUT,     \
                                         NRF_GPIO_PIN_INPUT_CONNECT, \
                                         NRF_GPIO_PIN_PULLUP,        \
                                         NRF_GPIO_PIN_H0D1,          \
                                         NRF_GPIO_PIN_NOSENSE)

The H0D1 can also be set after the i2c has been initialised using the io pin setup. The reason for trying this change is that weak clock drive can affect timing.

RE: Most Significative Bit in TWIM RX transfer is always 1

Jørgen Holmefjord — Wed, 08 Jul 2020 14:05:12 GMT

Hi,

Your reasoning sounds plausible, but it would really help if you could get logic/scope traces of the bus to determine if this could be what is happening. It is strange if you see this every time if it is related to clock stretching unless the slave performs clock stretching on every transfer.

Have you tried other slaves to see if they experience the same behavior?

Best regards,
Jørgen