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]

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?

[jy]

- 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

[Einar Thorsrud]

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?