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

SoftDevice Safe TWI Implementation Broke with SDK 8.0.0

So I've been using a user submitted SD safe TWI implementation that I found here. This has worked well so far, but upon updating to SDK 8.0.0 parts have broken. Now when I perform reads it continues to read past the correct number of bytes for long period of time. I'm diving into the details of the TWI implementation now, but I'm not well versed in PPI at all so I was hoping someone here might have some thoughts on the issue.

Finally, will Nordic PLEASE officially support SoftDevice safe TWI? It's clearly possible and a problem faced by many developers. It seems like each user submitted solution has it's own nuances, and this is the second time I'm having major problems with it.

The implementation I'm using is this: twi_hw_master_sd.c

Parents
  • In what way is the standard twi_hw_master.c not softdevice safe, what happens when you just use that code as-is with a softdevice?

    As far as I can see from diff-ing that code it just replaces all the NRF_PPI->CH[0] calls with sd_ppi_* ones which do exactly the same thing, I've not found a place it differs yet. It is true that when the SD is enabled one is encouraged to use the sd_* calls to ensure you're accessing available resources, but in this case you are, PPI channel 0 is reserved for the application, so the two should be identical (one without the SD overhead).

    The only other comment I can make about that code is it calls the sd_ functions but doesn't check their return values, again they ought to return success, but checking them would be good, even just in debug mode.

Reply
  • In what way is the standard twi_hw_master.c not softdevice safe, what happens when you just use that code as-is with a softdevice?

    As far as I can see from diff-ing that code it just replaces all the NRF_PPI->CH[0] calls with sd_ppi_* ones which do exactly the same thing, I've not found a place it differs yet. It is true that when the SD is enabled one is encouraged to use the sd_* calls to ensure you're accessing available resources, but in this case you are, PPI channel 0 is reserved for the application, so the two should be identical (one without the SD overhead).

    The only other comment I can make about that code is it calls the sd_ functions but doesn't check their return values, again they ought to return success, but checking them would be good, even just in debug mode.

Children
No Data
Related