PPI on TWI instance 1 not working

RE: PPI on TWI instance 1 not working

Jørgen Holmefjord — Wed, 26 Feb 2020 12:00:25 GMT

Thanks for the explanation. If you are doing the address/buffer update in software/interrupt handler I can understand that you made it work, I just thought that you had a solution to do this with PPI only, which I could not understand how would be possible.

RE: PPI on TWI instance 1 not working

Jared — Wed, 26 Feb 2020 11:22:16 GMT

It's not an elegant solution, but I'll describe it the best I can. I didn't actually change the slave address using PPI, as I understand it. I am using the timer handler (not the one for the counter, but for the other timer in the PPI implementation - it's unused in the sample project) to process two compare events. On one event, the proper DAC data value for this pass through is stored in a variable and a task scheduler function call is made. This particular task scheduler function uses nrf_twim_address_set()/nrf_twim_tx_buffer_set() to set the DAC slave address and update the TX buffer with the write data. I don't make the actual xfer here - just wait for the existing PPI functions to perform the TXRX for the DAC. On the next pass through, the other compare event includes a call to the task scheduler that uses the same two nrf functions to restore the slave address and TX data back to the appropriate values for the ADC. So, I had to increase the timer to double the frequency since it now has to perform both the DAC and ADC xfers while maintaining my target sampling rate. I have simple logic to make sure only one of the compare events (which are very similar in # of ticks) results in updates to the slave address / tx data for each pass through. I realize the timer handler can have up to 250us of delay since I'm also using a SoftDevice, so I had to take that into account to ensure that the address updates don't happen too late (timer is at over 1ms, so I have plenty of time). I'm happy to answer any other questions, as I've received tremendous support through the dev zone and will clarify/contribute if I can.

RE: PPI on TWI instance 1 not working

Jørgen Holmefjord — Tue, 25 Feb 2020 20:33:50 GMT

Can you explain how you managed to change the slave address using PPI? Or how do you differentiate which device you read from?

RE: PPI on TWI instance 1 not working

Jared — Tue, 25 Feb 2020 17:07:23 GMT

Thank you, Jorgen. I implemented the TWIM commands as you suggested and have found a way to achieve my sampling frequency target while writing TWI read values from both peripheral devices from the same TWI bus into the RAM buffer using PPI. I suppose we've now proven that your original suggestion from the previously linked thread is indeed achievable. Thanks again.

RE: PPI on TWI instance 1 not working

Jørgen Holmefjord — Tue, 25 Feb 2020 12:22:49 GMT

You should use nrf_twim_address_set()/nrf_twim_tx_buffer_set(). nrf_twi is for the legacy TWI peripheral, which does not support EasyDMA, i.e., you will have to update the register for every byte you transmit/receive.

RE: PPI on TWI instance 1 not working

Jared — Tue, 25 Feb 2020 10:50:43 GMT

Thanks for the response. It's ok for one device on the bus to not use ppi, as timing isn't critical and it doesn't require a read (only write). Is it possible to update the slave address and tx data value without restarting the RAM buffer?

I was looking at the TWI HAL functions. nrf_twi_address_set() looks like it might work for updating the slave address, but the nrf_twi_txd_set() function only sets up one byte to transfer, and I need two bytes.

RE: PPI on TWI instance 1 not working

Jørgen Holmefjord — Tue, 25 Feb 2020 10:03:30 GMT

I'm sorry but I do not think that I considered the address when I posted my answer in the thread you linked. There is no way to update the slave address register using PPI. If you want to interface devices with different addresses and trigger transfers using PPI, you will have to use two separate TWIM instances.

RE: PPI on TWI instance 1 not working

Jared — Tue, 25 Feb 2020 04:12:59 GMT

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.

RE: PPI on TWI instance 1 not working

Jared — Tue, 25 Feb 2020 03:38:30 GMT

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.

RE: PPI on TWI instance 1 not working

Jared — Tue, 25 Feb 2020 01:54:20 GMT

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: PPI on TWI instance 1 not working

Jared — Mon, 24 Feb 2020 20:48:22 GMT

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.

RE: PPI on TWI instance 1 not working

Jørgen Holmefjord — Mon, 24 Feb 2020 16:36:17 GMT

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