This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF51422 TWI not functioning properly

Hello, i have a strange situation here with TWI module and i have no idea what is happening. I have read a lot of posts here on devzone and the code i am using is also found somewhere on this forum, however in none of the post i found the same behaviour which i am seeing. I have a temperature sensor which is driven via i2c, so for this i am trying to use TWI. Piece of code which i am using is atached in the picture below.image description

If i am letting the code to run, then i hit a break-point at line 283. After i let the code to run again, i hit a break-point at line 286. At line 285 i am sending data to sensor with ret_code = nrf_drv_twi_tx(&p_twi_instance, 0x40, &dummy_data, 1, false); In this case, this is what i am seeing with oscilloscope on SCL and SDA lines: image description

If i remove a break-point at line 283 and allowing the code to run, i hit a break-point at line 286 and this is what i am seeing with oscilloscope in this case: image description

Also, this time i see in TWI1 events, that EVENTS_ERROR is set. Also, in TWI1_ERRORSRC register i have ANACK bit set. After this i have tried to do my own version of twi communication with sensor by modifying TWI1 module registers directly. However, that gives exactly the same results. Putting the break-point between sending data, and then running the code again - communication is seen. If allowing the code to run without any breakpoints, device gives NACK and communication fails.I don't understand what is causing this behaviour. Any help is appreciated. By the way, i am using SoftDevice S110_V8.

@ EDIT: After adding delay after TWI module initialization, and sending data. I don't understand however what is causing small voltage drop just few ms before starting communication?: delay.png

Parents
  • Hi, I am not sure which version of the twi driver you are using, but I can see from the init function that it's before nRF5 SDK v11. In general it's a good idea to update to the latest when there are SDK updates.

    I don't actually see any specific error or question here, and the traces looks reasonable. The nrf_drv_twi_tx() is not blocking in you code, meaning the actual twi transfer will occur in the background, and the twi_handler() will return an NRF_DRV_TWI_EVT_DONE on complete twi transfer. If you want the nrf_drv_twi_tx() to be blocking and not return to main until complete, then you should call nrf_drv_twi_init() without the callback handler (use NULL as parameter instead of twi_handler).

    Since you are setting up the twi transfer with callback, and you set the breakpoint directly after nrf_drv_twi_tx(), it will be unpredictable whether the twi transfer is complete or not when the CPU is halted. You should instead set breakpoint on NRF_DRV_TWI_EVT_DONE in twi_handler() or use the driver in blocking mode.

    The reason the second trace show the twi pins to be low level before the twi transfer is likely because you have configured the twi pins as output somewhere earlier, this will not be seen on the first trace due to the breakpoint on line 283.

    Edit:

    The second trace show a NACK condition, most likely because the twi slave is not ready to receive data. Add a delay and try again. Check the datasheet for the twi slave for timing details.

  • The first trace looks good, the sensor ACK the transacation and the data is written on the twi bus. The second trace the sensor NACK the transaction for unknown reason (maybe it's not ready to receive data). The third trace show a small dip in supply voltage some time before the twi transacation, most likely some circuitry is drawing current, this is normal.

    My recommendation is to check that you are using an nRF51 of 3rd revision and update to the latest nRF5 SDK if you haven't already. If the sensor NACK, then add a small delay and retry. Make sure to set breakpoints after the complete transacation is finished (even if it fails), either by using blocking twi calls or use a flag from the event handler. This make it easier to see if the twi driver send the stop condition as expected after an NACK, and is ready for a new transfer.

Reply
  • The first trace looks good, the sensor ACK the transacation and the data is written on the twi bus. The second trace the sensor NACK the transaction for unknown reason (maybe it's not ready to receive data). The third trace show a small dip in supply voltage some time before the twi transacation, most likely some circuitry is drawing current, this is normal.

    My recommendation is to check that you are using an nRF51 of 3rd revision and update to the latest nRF5 SDK if you haven't already. If the sensor NACK, then add a small delay and retry. Make sure to set breakpoints after the complete transacation is finished (even if it fails), either by using blocking twi calls or use a flag from the event handler. This make it easier to see if the twi driver send the stop condition as expected after an NACK, and is ready for a new transfer.

Children
No Data
Related