TWI write to IC registers fails when triggered by an incoming a BLE command [NRF Internal Error 3]

RE: TWI write to IC registers fails when triggered by an incoming a BLE command [NRF Internal Error 3]

cor10 — Sat, 05 Mar 2022 23:23:01 GMT

In the code I posted, specifically for the register write function, execution makes it all the way until the first APP_ERROR_CHECK() function catches the NRF INTERNAL ERROR 3. It does call memcpy right before interfacing with the TWI library, but there havent been any failures from memcpy to my knowledge. As Jared (from the other comment) mentioned, it is looking like a hardware and timing issue with the TWI driver, and thankfully it looks like I figured it out. I needed to gracefully handle the expected TWI NACK from forcing the communications window with my sensor...it appears the NACK followed by an immediate write or read would cause issues with the timing? Not really sure, but it seems to have helped. And I added a few delays in between operations to give a little more slack in regards to timing.

However, checking for a non-zero length of incoming data is a good check to have in place, so thanks.

RE: TWI write to IC registers fails when triggered by an incoming a BLE command [NRF Internal Error 3]

hmolesworth — Sat, 05 Mar 2022 19:11:48 GMT

You are correct, I re-read the code more closely and see that I'd missed that.

The TWI always had an issue (MISRA and CERT violation) with using an unchecked length to create an array which is subsequently used by an unchecked block copy/move. if length is (say) 0 bad things happen .. edit ignore that I see there is a +2 on reading again. Is pdata range-checked? memcpy of a zero-length value is also bad .. and the error shown seems to be in memcpy ..

RE: TWI write to IC registers fails when triggered by an incoming a BLE command [NRF Internal Error 3]

cor10 — Sat, 05 Mar 2022 01:19:58 GMT

Hi Jared,

I spoke with the EE who designed the board and YES there are external pullups in place (2.2kΩ). And, yes the error is coming from the TWI driver, specifically from this function:

uint32_t twiRegWrite16(uint8_t slaveAddr, uint16_t regAddr, uint8_t const * pdata, uint16_t length)
{
    uint32_t ret;
    uint8_t tx_buff[length + 2];
    uint8_t upperAddr = (regAddr >> 8) & 0x00FF;
    uint8_t lowerAddr = regAddr & 0x00FF;
    tx_buff[0] = upperAddr;
    tx_buff[1] = lowerAddr;

    memcpy(tx_buff + 2, pdata, length);
    nrf_drv_twi_xfer_desc_t xfer = NRF_DRV_TWI_XFER_DESC_TX(slaveAddr, tx_buff, length + 2);

    ret = nrf_drv_twi_xfer(&m_twi, &xfer, 0);

    if (NRF_SUCCESS != ret)
    {
        return ret;
    }

    // Wait for response for 5 ms
    for(uint32_t k = 0; k <= 5000; k++)
    {
        if(m_xfer_status != 0)
        {
            nrf_delay_ms(1);
            break;
        }
        nrf_delay_us(1);
    }

    if(m_xfer_status == TWI_XFER_STATUS_SUCCESS)
    {
        return NRF_SUCCESS;
    }
    else
    {
        return NRF_ERROR_INTERNAL;
    }
}

First, I tried disabling the internal pullups first, but that didnt seem to work right, because the error occurred again when just relying on the external Pullups.

Next, we removed the external pullups, which you can see in the schematic that I am attaching for reference. However, now we can no longer communicate with ANY of our sensor ICs (I double checked that the internal PullUps are enabled in nrf_drv_twi.c in the SCL/SDA_PIN_INIT_CONF defines). Any ideas as to why this would happen when just using the internal PullUps?

Also, I am curious as to why don't I ever see the NRF INTERNAL ERROR 3 thrown during the initialization stage of the application. When I initialize all the sensors, I perform many register write operations in a row, and never once has it thrown an error. The only other register writes that occur with this project are from the Desktop app that I am working on here, and they are buggy for some reason. The only other running code in this application is the 50ms repeated timer in, which performs many register reads and never fails....I suppose those repeated register reads could be conflicting with these asynchronous register writes (but oddly not with asynch register reads, which always works). And we dont see this failure during configuration because the timer hasnt been started yet...

Thank you.

RE: TWI write to IC registers fails when triggered by an incoming a BLE command [NRF Internal Error 3]

cor10 — Sat, 05 Mar 2022 01:14:23 GMT

Correct me if I am wrong here, but I am specifically using the app Scheduler to deal with this issue of multiple threads. My understanding of the Scheduler could be incorrect, but from the main() function in my project, the application is in an infinite loop that solely waits for events and calls app_sched_execute() to run any tasks that have been queued via app_sched_event_put().

By only scheduling (not running) the register write task in the ble_nus_handler(), I thought that I was effectively handing off the execution of each regWrite task to the main() loop. The only other reads/writes made to the sensors are also done via the same app_sched_event_put() function, so my hope was that the Scheduler would be smart enough to sequentially process these tasks without conflict or fear of asynchronous interrupts.

Is this logic incorrect?

RE: TWI write to IC registers fails when triggered by an incoming a BLE command [NRF Internal Error 3]

hmolesworth — Fri, 04 Mar 2022 16:12:54 GMT

This may be due to not considering multiple threads, which is an issue I have seen on other projects. regWriteHandlerHelper() is (probably) not re-entrant, so an error is generated when it is used by two threads simultaneously. Why would that happen? Consider a read or write in progress to the sensor from some function invoked from main or other part of the code when a BLE packet is received asynchronously which invokes nus_data_handler(). The problem is that this BLE request is within an interrupt context, and so initiates a sensor transfer interrupting the transfer already in progress with no handling to detect this.

A simple test to see if this is the issue is instead of nus_data_handler() invoking regWriteHandlerHelper() directly instead set a volatile bool and invoke regWriteHandlerHelper() from main().

If you have already considered this please ignore, but looking at the code presented in the original post it looks like this is the issue.

RE: TWI write to IC registers fails when triggered by an incoming a BLE command [NRF Internal Error 3]

Jared — Fri, 04 Mar 2022 14:02:07 GMT

Hi,

What function throws the NRF_ERROR_INTERNAL? If it's the TWI driver then it's a hardware error. This can happen for example if the timing requirements are not respected. Do you have external pullups connected to the SDA or SCL?

regards

Jared