TWI Module lock-up still present in nrf51822 v3 [PAN #56]

[Mike]

Hi,

I am currently experiencing TWI module lock-up issues with the hardware TWI library, which is supposedly fixed according to PAN v3.0, issue #56. (The issue was previously identified in PAN v2.3)

My setup is as follows, custom board, SD110v8, NRF51822 QFAAH0 (16kB flash, v3 silicon). My code is modified from the dfu_ble_dual_bank example in the Keil packs. The TWI transaction is triggered every 2s by the app_timer.

If I change the TWI library to software TWI, then the problem disappears.

An interesting note is, before the dfu bootloader starts (prior to the function call of : bootloader_dfu_start ), the module lock up doesnt seem to happen. Once the bootloader fully starts, (after calling bootloader_dfu_start function), the TWI transaction would randomly occur, fairly frequently.

Could someone from Nordic provide some insight to this problem? As my observations seem to contradict the PAN v3.0

Warm regards, Mike

[Mike]

@Martin and @RK, I will try to provide some information before resulting to upload the code, as I have to check with my colleagues about confidentiality.

I would say out of all the function calls to twi_master_write function, the error rate can be as high as 50%, or as low as 10%, fairly irregular in when it appears too. The function is called once every 2s (in the battery_meas_timeout_handler function).

I debugged the code, and identified that the code enters this particular segment when an error occurs:

    if (timeout == 0 || NRF_TWI1->EVENTS_ERROR != 0)
    {
        // Recover the peripheral as indicated by PAN 56: "TWI: TWI module lock-up." found at
        // Product Anomaly Notification document found at 
        // www.nordicsemi.com/.../
        NRF_TWI1->EVENTS_ERROR = 0;
        NRF_TWI1->ENABLE       = TWI_ENABLE_ENABLE_Disabled << TWI_ENABLE_ENABLE_Pos; 
        NRF_TWI1->POWER        = 0;
        nrf_delay_us(5);
        NRF_TWI1->POWER        = 1;
        NRF_TWI1->ENABLE       = TWI_ENABLE_ENABLE_Enabled << TWI_ENABLE_ENABLE_Pos;

        (void)twi_master_init();

        return false;
    }

Another interest point is, if the battery_meas_timer is the only one running (before the bootloader starts to advertise, this problem doesnt seem to happen, however once the other app_timer tasks starts, such as ble_advertising (and I think there is one for bootloader timeout), this problem starts happening.

Please let me know if this is sufficient information for you, otherwise I will try to get permission to upload some code for you. Cheers.

[RK]

which is the condition causing the code to enter the segment? timeout==0 or EVENTS_ERROR is non-zero?

What is NRF_TWI1->ERRORSRC ?

[MartinBL]

There is a while loop right above the code Mike posted:

while (NRF_TWI1->EVENTS_TXDSENT == 0 && NRF_TWI1->EVENTS_ERROR == 0 && (--timeout))
 {
       // Do nothing.
 }

@Mike: I am still invastigating this. But let me make myself clear: in the myPage portal you will get complete confidentiality, not some as I wrote above. Customers use myPage to upload their code and designs all the time.

[RK]

Hence my question - that while loop can still be exited by either

1. The character send completing
2. The error event being triggered (ie becoming non-zero)
3. The timeout reaching zero

I asked which of 2. or 3. actually caused the loop to exit. If it was an ERROR being indicated as opposed to the timer counting down to zero, then it's just a TWI error being reported and not the 'lockup'.

[MartinBL]

Hi Mike. Are you able to answer RK's question? And also what modifications did you do to the original example?