TWI/S110 "issue" vs nRF51822 hardware revision

[jy]

Hi, 

1.

I feel really stupid as I cannot make any sense of any of the information found in Product Specification (v3.3), or the online Compatibility Table or past forum messages (most with dead links anyway) ... things like "QFAC Ax0" (x in [0..9]) does not match mine which says "QFACA1".

=> Anyway, could anyone tell whether "N51822 QFACA1 1627ET" is a first revision chip?

2.

reading through the forum, it seems that first revision chips had an issue when running both TWI and SD (S110) concurrently due to common usage of PPI[0]; there are multiple versions of the twi_hw_master.c file going around. I have tried many variants (mostly SHORTS and sd_ppi_channel_assign() based) but the bluetooth connection systematically disconnects when the firmware tries to update the i2c/twi attached RTC. Note that outside any active BT connection, the communication to the RTC works well. Note also that I use SDK6.1.0 + SD110_7.3.0 (and there is no way around that :/ )

=> Could someone attach here the version that will work? 

thanks in advance for your support.

[jy]

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?

[jy]

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);
}

[Einar Thorsrud]

Hi,

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

[jy]

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.

[Einar Thorsrud]

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?