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

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

Mike — Tue, 09 Jun 2015 07:39:46 GMT

Hi RK, thanks for the reply as always. At this point we don't have the resource to investigate this further. I will just use the library that is working for us at the moment. Cheers.

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

RK — Wed, 03 Jun 2015 00:50:42 GMT

I have no real idea because I don't use it - I write all my own library code. That said, 100s of products have been shipped using Nordic's TWI HW library and they appear to work and I'm guessing from the name of the thing you found, tw_hw_master.c, that it's a derivative of, or an earlier version of, the HW library.

In the end it's hard to see how a HW library could work intermittently, it's hardware, you write the register, the byte is clocked in and/or out, the clock is togged, in hardware. The TWI hardware either works or it doesn't, there's not much you can do to drive it which will make it work differently.

The only thing I can say about those traces (and I'm spoiled as I have a logic analyser which make life easier) is that the nrf TWI appears to do the right thing but there's no reply from the other chip. I think if you want to get further perhaps file a support case.

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

Mike — Tue, 02 Jun 2015 14:05:07 GMT

hi RK, apologies for the late reply again, been tied up with some other work and havent got the time to investigate this.

I took out the oscilloscope and started probing the I2C bus. What I have discovered is:

using the PACK SW library, no issues observed using the PACK HW library, occasional issue observed (no NACK received, the SDA is not held low) using a custom HW library, which I found from one of the other posts, no issues observed

I will include the screenshots I have took too

1 - PACK SW working

2 - PACK HW Working

3 - PACK HW error

4 - Custom HW working

Also, this is the custom HW TWI library that I have used. twi_hw_master.c

Judging from the screenshots, SW has slightly different timing for the SCL, which is expected.

When the PACK HW library is working, it looks identical to the custom HW library (compare 2 with 4).

However, when the PACK HW library is not working, I can also confirm that SDA is not held low during the NACK bit.

I did a quick comparison between the custom HW .c file and the PACK HW .c file, there are quite a few differences, which lead me to think, there might be an issue with the existing HW library in the PACK?

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

RK — Thu, 21 May 2015 05:46:07 GMT

I don't know - I haven't used the sw master, actually I haven't used the hw master either :) but I just looked at it, wow, it's an old bit banger. I would say that's going to have somewhat different timing than the real hardware interface, it seems from looking at the code quite .. generous about timings. I'd check the speed you're running the I2C at, perhaps try something slower, check all the parameters too, I assume those two things are supposed to be API compatible but check everything.

One last thought, make sure that EVENTS_ERROR isn't already set from something previous before you start the transfer. I have no idea whether starting a new transfer clears it if set, if not, you may be instantly failing because it was set previously. I don't see in the code anywhere it's cleared.

Failing that - it's logic analyser time to see what's actually being written in each case.

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

Mike — Wed, 20 May 2015 14:14:26 GMT

hi RK, thanks for the feedback as always. if the hw twi driver is experiencing the NAK issue, why would the sw twi driver work without any issue in this case? (after selecting the software option in the twi driver, i can talk to my i2c device without any issue)

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

RK — Wed, 20 May 2015 12:23:07 GMT

Ah ok - so I don't think that is the lockup then. AFAIR the lockup meant exactly that, nothing happened, the character was never sent, there was no error, it just locked up and you never heard from it again.

That's what timeout-- did, it polled for a certain amount of cycles beyond which something should have happened and when it didn't, it reset the chip. So if it locked up eventually it would fail and reset.

In your case however you're not dropping into that code because timeout has hit zero, but because TWI has reported an error, the second piece of that 3-part if() statement. In this case it's 0x02 which is ANACK, a NAK was received after sending out the address. So the address went out and the peripheral you were trying to talk to didn't hold the data line low during the next clock period.

Good news, seems unlikely to be the lockup, bad news, time to get the logic scope out.

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

Mike — Wed, 20 May 2015 11:41:35 GMT

hi all, my apologies for not getting back to you sooner

the trigger is NRF_TWI1->EVENTS_ERROR = 1. the NRF_TWI1->ERRORSRC value is 0x02.

I have already submitted a case through mypage, and uploaded the firmware in a .zip file

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

MartinBL — Wed, 06 May 2015 13:47:37 GMT

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

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

RK — Wed, 06 May 2015 07:22:42 GMT

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

The character send completing
The error event being triggered (ie becoming non-zero)
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'.

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

MartinBL — Wed, 06 May 2015 07:11:52 GMT

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.

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

RK — Wed, 06 May 2015 04:11:49 GMT

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

What is NRF_TWI1->ERRORSRC ?

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

Mike — Wed, 06 May 2015 04:01:36 GMT

@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.

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

RK — Mon, 04 May 2015 15:37:43 GMT

Mike - if the version of the .c file you're using is the same as the one posted as you say, then the issue you're having cannot be the PAN from the previous silicon revision, that twi driver works around that issue. So you certainly have a problem which may look like the hardware TWI lockup, but it can't be the same thing.

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

MartinBL — Mon, 04 May 2015 14:42:29 GMT

Ah, sorry for the misunderstanding. We haven't had any reports on TWI lockups on rev 3 silicon, so this is new to us and we suspect there might be something going on during dfu.

Do you have access to a logic analyzer to show us what is going on on the TWI lines?
Can you share your code with us? You can contact us on our MyPage support portal if you prefer some confidentiality.
Are you able to debug the code to see if your code hangs somewhere?
When you say "the TWI transaction would randomly occur, fairly frequently" do you mean that the lockup randomly occur or is the TWI really going haywire?

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

Mike — Mon, 04 May 2015 14:08:29 GMT

Hi all,

RK's comments pretty much covered everything for me (thanks!)

@Martin, by the way, the .c file you posted is the same as the one I used.

As mentioned previously, I am curious why the lock up still happens. According to PAN v3.0, this issue should be fixed in hardware in the v3 silicons.

Thanks, Mike

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

RK — Mon, 04 May 2015 13:19:32 GMT

I don't think that was his question, he didn't want a TWI driver which worked around PAN 56, he was saying that the latest revision 3 chipset was supposed to have fixed PAN 56 in hardware, thus not requiring a driver which worked around the issue because there should no-longer be an issue to work around.

Does revision 3 hardware still suffer from TWI lockup? The original poster is saying that he's seeing something very like the pre-revision 3 TWI hardware lockup on revision 3 hardware.

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

MartinBL — Mon, 04 May 2015 12:32:20 GMT

Hi. Which TWI driver are you using. I'm afraid that there are a couple of different versions out there. I have attached the TWI hardware driver included in SDK v8 which is supposed to have corrected for PAN 56.

twi_hw_master.c