SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

RE: SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

Keton — Wed, 06 Jun 2018 09:44:02 GMT

I have tried above solution and I'm still getting it to hang with my repro code from the thread.

I've also observed random hangs in scenario where there's a lot of long TWI TX operations (complete overwrite of Adesto RM24C512C eeprom).

EDIT: I've dug some deeper in my repro and It seems that in certain circumstances TWIM irq handler stops being called despite pending transfers so no events are propagated to the app_twi and the application code.

Also in my case value of AMMOUNT register is larger than MAXCNT which is weird.

RE: SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

Radoslaw Koppel — Wed, 30 May 2018 14:33:29 GMT

I cannot recreate the problem, but guessing by the registers state you have provided we can tell that the twim_irq_handler (line 493 in nrfx_twim.c) hited the "else" conditional in line 562. The way this condition is added here seems not to be 100% safe. For quick test could you replace it by:

if (nrf_twim_event_check(p_twim, NRF_TWIM_EVENT_SUSPENDED))

And check if the problem persist?

To clarify, there should be

    if (nrf_twim_event_check(p_twim, NRF_TWIM_EVENT_SUSPENDED))
    {
        nrf_twim_event_clear(p_twim, NRF_TWIM_EVENT_SUSPENDED);
        NRFX_LOG_DEBUG("TWIM: Event: %s.", EVT_TO_STR_TWIM(NRF_TWIM_EVENT_SUSPENDED));
        if (p_cb->xfer_desc.type == NRFX_TWIM_XFER_TX)

Instead of

    else
    {
        nrf_twim_event_clear(p_twim, NRF_TWIM_EVENT_SUSPENDED);
        NRFX_LOG_DEBUG("TWIM: Event: %s.", EVT_TO_STR_TWIM(NRF_TWIM_EVENT_SUSPENDED));
        if (p_cb->xfer_desc.type == NRFX_TWIM_XFER_TX)

Sorry for providing not tested solution, but as you did not provide any code to check the problem and we cannot recreate it this was the only one I can think right now. It would really speed thing up if you could test it in your application.

RE: SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

F Iannce — Fri, 11 May 2018 04:12:57 GMT

Thanks for the code--I'll definitely take a look a closer look at it in the near future to see if it fixes the issue. I wish that I had the time to look into this more, but I have to get some other features working before our software team starts to complain about not having hardware to develop on and/or our delaying production schedule.

For now, I added a check in my EVT handler for the stuck condition and am performing an I2C reset, and then resending the last command. This is a clunky "solution", but it is working.

RE: SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

Nguyen Hoan Hoang — Thu, 10 May 2018 19:33:36 GMT

Not sure what caused it but you may want to have a look at this alternative i2c driver for the nRF52. It is probably simpler to understand.

RE: SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

F Iannce — Thu, 10 May 2018 19:16:00 GMT

I put a breakpoint in my TWIM handler function. When the SCL line is getting stuck low, I am getting an NRFX_TWIM_EVT_DONE event, but the AMOUNT != MAXCNT. I reduced the amount of data I am transferring so that MAXCNT is now only 0xAF.

I will be writing some code to reset the I2C when this error occurs (as a workaround), but I really would like a better understanding of the root cause. Why would I be getting an NRFX_TWIM_EVT_DONE event when I have received all of the data I requested in nrfx_twim_xfer()? It works perfectly fine sometimes for 2-300 calls, but then suddenly one call returns done without completing the request...

RE: SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

F Iannce — Thu, 10 May 2018 18:10:15 GMT

I thought for a second that this did the trick, but it appears that it was just a slightly longer delay before the TWIM driver crashed. I limited my read to 200 bytes, and it is still getting stuck. I'm going to see if I can find out any more clues. Thanks.

RE: SCL Stuck Low with NRF52810 SDK 15.0 on Custom Board

Nguyen Hoan Hoang — Thu, 10 May 2018 14:40:06 GMT

I think the MAXCNT is limited to 0xFF only. Although the datasheet showed a 32bits value. The AMOUNT is limited to 8 bits. The behaviour seems to be related. try limit to 0xFF max per transfer to see what happens.