TWI/S110 "issue" vs nRF51822 hardware revision

RE: TWI/S110 "issue" vs nRF51822 hardware revision

Einar Thorsrud — Thu, 24 May 2018 08:24:16 GMT

The fact that you see this also if you do the TWI transaction from app context seems strange. The TWI handling should not get in the way of the SoftDevice in that case.

The only thing I can think of is if you use a high priority for the TWI interrupt and a lot of time is spent in TWI interrupt/event handlers, but the twi_hw_master.c file that is included in SDK 6.1.0 is not interrupt driven. Are you using a different driver that is interrupt driven? If so, what is the priority of your TWI interrupt?

RE: TWI/S110 "issue" vs nRF51822 hardware revision

jy — Wed, 23 May 2018 09:53:56 GMT

- when receiving a BLE packet, ble_nus take over and pass to my incoming handler: it receives a command to set clock (6 bytes: 2 header + 4 for clock info): there I foward that value to the rtc(/i2c/twi) to set that time; once this is done; the incoming handler will give a positive/negative response.

- when using the loop-variant (sending 8 i2c/twi packet) I get a reason= 0x08 (connection_timeout) on disconnect;

- when using the move-blob-at-once, things work properly

RE: TWI/S110 "issue" vs nRF51822 hardware revision

Einar Thorsrud — Wed, 23 May 2018 09:17:10 GMT

Indeed it is. Apparently I did not read much of the code listing… I do not see any reason why this should cause a BLE disconnect. Can you say more about what happens at that time? Any event from the SoftDevice? What is the disconnect reason when you get the BLE_GAP_EVT_DISCONNECTED event?

RE: TWI/S110 "issue" vs nRF51822 hardware revision

jy — Tue, 22 May 2018 14:26:50 GMT

Hi Einar. i2c_data_write implementation is in previous reply (see code snippet above). In terms of context, the behavior is identical when running from SD event handler or in app context.

RE: TWI/S110 "issue" vs nRF51822 hardware revision

Einar Thorsrud — Tue, 22 May 2018 13:04:21 GMT

Hi,

Is this code running in main context or interrupt context? If interrupt, which priority? How have you implemented i2c_data_write()?

RE: TWI/S110 "issue" vs nRF51822 hardware revision

jy — Fri, 18 May 2018 17:31:10 GMT

more insights: it seems to come from when sending large chunks (here 8 bytes) over TWI while having an ongoing BT connection;

the chunks are send to an i2c RTC as follows:

// blob is 8 bytes wide

// DOES NOT WORK if there is an ongoing BT connection
i2c_data_write(RV4162_I2C_ADDRESS, RV4162_REG_DATE_SSEC, blob, sizeof(blob));

// WORKS:
uint8_t idx;
for (idx=0; idx<sizeof(blob); idx++)
{
    i2c_data_write(RV4162_I2C_ADDRESS, RV4162_REG_DATE_SSEC + idx, &blob[idx], 1);
}

// with:
bool i2c_data_write(uint8_t address, uint8_t reg, uint8_t *data, uint8_t len)
{
    ASSERT(m_i2c_init);
    ASSERT(len >= 1);
    uint8_t stream[1 + len];
    stream[0] = reg;
    memcpy(&stream[1], data, len);
    return twi_master_transfer(address, stream, 1 + len, TWI_ISSUE_STOP);
}

RE: TWI/S110 "issue" vs nRF51822 hardware revision

jy — Fri, 18 May 2018 16:20:12 GMT

ok; got confirmation 51822 QFAC chips are rev.3; so the PPI vs TWI concurrency should not be any issue .... yet I get a BLE_GAP_EVT_DISCONNECTED whenever I use TWI. Any clues on why that is?