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]

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

[RK]

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.

[Mike]

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)

[RK]

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.

[Mike]

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?