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

PPI on TWI instance 1 not working

I have adapted the "nrf52-mpu-easydma-using-timers-and-drivers" project from Github that I saw referenced in another post and have successfully modified it to work with my A/D converter on TWI instance 0.  However, I have implemented a virtual "ditto" of this design on TWI instance 1 and the TWI transfers never happen.  I can tell from the debug terminal that all 4 of the PPI channels appear to be set up properly (channels 0 - 3, 2 channels for each TWI instance) and have tested to confirm that the timer instance that should generate the TWI transfers is indeed triggering at the desired interval (tested by temporarily enabling the timer handler and toggling a GPIO pin).  I can share the code on a private ticket if needed, but I first want to confirm that this should be capable of working on two TWI instances.  Since they aren't on the same bus, I would have thought that this should be ok.  I appreciate any feedback/assistance.

UpdateI forgot to mention I'm using SDK 15.2 (was being used by one of our partners, so we're staying aligned) and SES 3.40, just in case that is relevant.  Also, I know the TWI instance 1 is set up properly because the init routine performs a proper tx/rx to configure the I2C accelerometer on that bus.

  • Hi,

    There should not be any issues with doing this for two TWI peripherals, as long as you have the available peripherals/resources that are needed to set this up. I have converted this case into a private one to allow you to upload the firmware. 

    Best regards,
    Jørgen

  • Thank you for your help.  Please let me know if you have any questions.  I can give you the quick overview: TWI0 is used for comms to an A/D converter (via the easyDMA/PPI project code), D/A converter, and a digital rheostat.  The DAC acts as a current source (write a value, it sets a drive current to one of several LEDs).  The DAC writes are scheduled from an interrupt and don't require easyDMA.  TWI1 is used for an accelerometer, which has a different data width (6 bytes vs 2 bytes for the ADC).  The digital rheostat is just written to once during initialization, which works fine.  The tx/rx to the accelerometer during init also works fine.  Other significant project details include the SoftDevice 140 v6.1.0 and BLE comms that are working fine There are a lot of details I could go into - please let me know if you have any questions.  Apologies for the sloppiness of code at this stage in evaluation.  Thanks.

  • I'm finding some related issues to using easyDMA / PPI with multiple devices on the same TWI bus (different problem with the same project).  From this thread I was thinking that I could use PPI with two slaves on one bus and just know that the RAM buffer would have alternating data, but the transfer sequence update (to update the slave address) blows away the RAM buffer, so I never get more than one sample of data in the buffer.  Is there a way to implement this that doesn't involve reloading the transfer sequence?  I can put this on a different ticket if you prefer, but I was suspecting that there may be enough in common to keep these issues together.

  • RE: the initial problem - my current thinking is that there is an issue with the init routine on my accelerometer because I've realized it doesn't complete all of the TWI transfers and the SDA line gets stuck low at some point.  I've seen this happen when I use intermingled TWI drivers (nrf_drv_twi_tx instead of nrf_drv_twi_xfer). So, I suspect this is not a PPI-related problem.  I will try to fix this and update later.  However, my issue with multiple slaves on the same TWI bus remains to be an issue.

  • Yes, that was it.  I now have the 2nd TWI peripheral, TWI1, operating with PPI as I would expect. A device driver I received for the accelerometer had some bugs that I fixed, as described in my previous comment.  Should I mark this as complete and generate a new ticket for the two slaves/one bus issue?  Thanks. 

Related