• State Verified Answer
  • Replies 3 replies
  • Subscribers 71 subscribers
  • Views 3222 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 101252
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

I think I have found a bug in TWI_hw_master for nRF51822

Philip Freidin

The attached test program and logic analyzer displays shows that the function twi_master_transfer() returns to the calling program before the transfer is complete, if TWI_hw_master.c is used. Specifically, it returns before the STOP code has been transmitted. If the calling program makes another call to this function, the STOP code is never sent. The problem does not occur with the software version of the TWI interface: TWI_sw_master.c

In the attached images, the green dots are START codes, and the red dots are STOP codes.

Reviewing TWI_SW_no_extra_delay.jpg , the pulse on Diag 4 shows that the return from twi_master_transfer() occurs after the STOP has been sent. This is line 40 of the test program.

Reviewing TWI_HW_no_extra_delay.jpg (the only change is replacing the TWI_sw_master.c with TWI_hw_master.c) the same pulse on Diag 4 shows that twi_master_transfer() has returned before the STOP has been sent. The following call to twi_master_transfer() on line 52 is reached before the STOP occurs, and its start then looks like a RepeatedStart , which is incorrect.

Adding an additional delay of 35 us (could be less, but I didn't try and figure out the minimum) after line 40 , is shown in TWI_HW_with_extra_delay.jpg . This shows a stretched pulse on Diag 4 , and the STOP now occurs correctly.

It looks like the code at line 158 in TWI_hw_master.c is where the problem is. (see below, it is at line 81 per Hung Bui's response)

Could someone please confirm this bug, or correct me if I have not understood something. Thanks.

TWI_SW_no_extra_delay.jpg

TWI_HW_no_extra_delay.jpg

TWI_HW_with_extra_delay.jpg

TWI_hw_test.c

Parents
  • 0

    Hi Philip,

    Thanks for reporting this. I can confirm that it is a bug with our twi_hw_master driver. We didn't clear the STOP event after issue a write with stop bit. This explain the strange behaviour that the read function return before the STOP bit was issued (because NRF_TWI1->EVENTS_STOPPED already set) .

    So if you add NRF_TWI1->EVENTS_STOPPED = 0; after the loop while(NRF_TWI1->EVENTS_STOPPED == 0) { // Do nothing. }

    at line 81 in the twi_hw_master.c, the hardware TWI should work properly.

    I will report this internally and it should be fixed in the next release of the SDK.

    Best Regards,

    Hung

Reply
  • 0

    Hi Philip,

    Thanks for reporting this. I can confirm that it is a bug with our twi_hw_master driver. We didn't clear the STOP event after issue a write with stop bit. This explain the strange behaviour that the read function return before the STOP bit was issued (because NRF_TWI1->EVENTS_STOPPED already set) .

    So if you add NRF_TWI1->EVENTS_STOPPED = 0; after the loop while(NRF_TWI1->EVENTS_STOPPED == 0) { // Do nothing. }

    at line 81 in the twi_hw_master.c, the hardware TWI should work properly.

    I will report this internally and it should be fixed in the next release of the SDK.

    Best Regards,

    Hung

Children
Related
Terms of service